Skip to main content

Humanitarian Toolbox Codeathon - 20th January 2018

Firstly, I'm a bit late to the party with my blog article, both Steve (the event organiser) and Dave / Dan (a couple of the attendees) have written great articles that can be found here:

So back to my story regarding the event. I first heard about the codeathon from Steve via the .NET South East Meetup, which he also organises. Steve's a prolific contributor to the HTBox Allready project and I'd been wanting to have a go since hearing him do a quick talk at a Brighton ALT.NET show and tell session. Having not contributed to any open source projects, I must admit that it all seemed a little overwhelming. Even looking through the open issue list on GitHub, it seemed hard to find a starting point.

So one evening after signing up to the codeathon, armed with the install documentation, I started my Humanitarian Toolbox journey. I found these instructions really well written / easy to follow, I was up and running surprisingly quickly. I did run into one issue building / running the F# UI tests and probably have a documentation pull request to submit, updating the instructions with the solution I found.

As always with any new codebase, the next couple of evenings were spent running through the architecture understanding how everything is laid out / works together. It's a very clean .NET core 2.0 codebase that makes good use of a lot design patterns including MediatR, which I need to look into some more.

On the day, after the introductions, we all got stuck into picking up our first issues. Over the course of the day I completed two existing issues and in the process created and worked on two new issues of my own:

  • #2228: I picked a nice easy issue to get me started, this one was to update the input model validator to reject uploaded images if they were bigger than a predefined size for new / updated events.
  • #2263: Whilst working on #2228 I had to update over 100 unit tests to handle the extra object I was injecting into the controller's constructor. I created this issue to allow me to update the tests to utilise the builder pattern.
  • #2219: For a quick win, this issue was almost identical to #2228 but for creating / editing campaigns.
  • #2283: Updating the campaign admin controller constructor resulted in a similar level of broken unit tests, I created this issue to implement the builder pattern for this controller and help make it easier to inject new components in the future.

During the course of the day I submitted two pull requests. With all of us working on the codeathon we were swamping poor Steve with merge requests and AppVeyor with build requests. Steve did manage to get one of my pull requests merged into the code base, with the second waiting in the queue. Details of the pull requests can be found here:

Overall, I really enjoyed the day and I'm looking forward to contributing to the project some more in the coming weeks. To understand the code base some more I'll probably carry on tidying up the controller unit tests, finishing off introducing the builder pattern to the remaining tests and then looking to refactor some more duplicated code / improve the test coverage.

Finishing up what has turned out to be my longest blog post in a while, thanks also to Madgex for providing both the venue and food throughout the day (and their continued support of .NET South East meet-up). Also, thank you to Richard Campbell for coming down to Brighton and keeping us entertained during the day with his great stories and then providing his fantastic talk in the evening about the history of .NET. I'll definitely be keeping an eye out for the promised book, it might even be my first Kick Starter.

Comments

Popular posts from this blog

Mocking HttpCookieCollection in HttpRequestBase

When unit testing ASP.NET MVC2 projects the issue of injecting HttpContext is quickly encountered.  There seem to be many different ways / recommendations for mocking HttpContextBase to improve the testability of controllers and their actions.  My investigations into that will probably be a separate blog post in the near future but for now I want to cover something that had me stuck for longer than it probably should have.  That is how to mock non abstract/interfaced classes within HttpRequestBase and HttpResponseBase – namely the HttpCookieCollection class.   The code sample below illustrates how it can be used within a mocked instance of HttpRequestBase.  Cookies can be added / modified within the unit test code prior to being passed into the code being tested.   After it’s been called, using a combination of MOQ’s Verify and NUnit’s Assert it is possible to check how many times the collection is accessed (but you have to include the set up calls) and that the relevant cookies have …

Injecting HttpContextBase into an MVC Controller

It is a shame that when the ASP.NET MVC framework was released they did not think to build IoC support into the infrastructure. All the major components of the MVC engine appear to magically inherit instances of HttpContext and it’s related objects – which can cause no end of problems if you are trying to utilise Unit Testing and IoC. Reading around various articles on the subject just to get around this one problem requires the implementation of several different concepts and you are still left with a work around. The code below, along with the other links referenced in this article is my stab at resolving the issue. There’s probably nothing new here, but it does attempt to relate all the information needed to do this for Castle Windsor. The overview is that all controllers will need to inherit from a base controller, which takes an instance of HttpContext into it’s constructor. It then overrides the property HttpContext in the main controller class, supplying it’s own version…

Unit Testing Workflow Code Activities - Part 1

When I first started looking into Windows Workflow one of the first things that I liked about it was how it separated responsibilities. The workflow was responsible for handling the procedural logic with all it's conditional statements, etc. Whilst individual code activities could be written to handle the business logic processing; created in small easily re-usable components. To try and realise my original perception this series of blog posts will cover the unit testing of bespoke code activities; broken down into: Part One: Unit testing a code activity with a (generic) cast return type (this post)Part Two: Unit testing a code activity that assigns it's (multiple) output to "OutArguments" (Not yet written)So to make a start consider the following really basic code activity; it expects an InArgument<string> of "Input" and returns a string containing the processed output; in this case a reverse copy of the value held in "Input".namespace Ex…