DDD East Anglia in Review
And so it was that, inspired by the grand prix at Silverstone, we found ourselves pelting towards Cambridge at somewhat naughty speeds for the debut DDD East Anglia. A glorious day it was with good weather, good talks and good meets with friends and new faces alike. The rooms were perhaps a little stuffy but that small gripe aside, Phil Pursglove [http://twitter.com/philpursglove] and crew deserve a massive vote of thanks for organising it all, the staff at the Cole Hauser forum (not named after the actor [http://en.wikipedia.org/wiki/Cole_Hauser]) for the food and drink, and the speakers for the sharing of their knowledge.
Pragmatic Dependency Injection - Ian Russell (@ijrussell [http://twitter.com/ijrussell]) Ian’s talk focussed on demonstrating the four main patterns in refactoring your apps to use dependency injection:
- Constructor Injection : allows you to set your dependencies in a single composition root using the Decorator pattern to add functionality to our classes. However this “poor man’s DI” can get quite complicated quite quickly (as Ian demonstrated). A DI container helps to alleviate that problem. 2. Property Injection 3. Ambient Context pattern : allows you to get around non-deterministic functions and classes like DateTime.Now, Guid.NewGuid() etc 4. Abstract Factory pattern : allows you to inject the right class at runtime perhaps based on user input.
He then wrapped up by refactoring his demo code to use a DI container – in this case, he used Ninject which makes use of generics and eschews XML. He showed how to set up the container and then how to use the “Register, Resolve, Release” pattern to use the container within our code. Finally, he noted that you have to get your code in a good state before you should start using a DI container else it will start ‘fighting the container’.
The code for this talk can be found at https://github.com/ijrussell/DDDEastAnglia.
Ready Set Go!! – Mark Rendle (@markrendle [http://twitter.com/markrendle]) More a demonstration to show exactly how much you can achieve in one hour (after three hours sleep and a tyre blowout on the M11 the night before) if you really know your stuff, the ever affable Mark Rendle provided wry commentary while writing his own to-do web application using Simple.Web, Simple.Data, TypeScript, and AngularJs. Points also go to Mark for originality, spending at least five minutes trying to get an exception thrown when the app seemed to be working fine. Inspiring stuff.
Proving how much power this particular toolset has, Mark pointed out that his start-up Zudio [https://zud.io/] uses exactly the same setup to implement its alternative Azure administration UI.
Better Unit Testing – Isaac Abraham (@isaac_abraham [http://twitter.com/isaac_abraham]) Isaac’s talk focussed not on what unit testing is, or the basics of it, but rather how teams should approach it to make it work better and give a better return on investment, noting that it is very hard to do well and that each team will have a different definition of what a good unit test is. Additionally, the main question is how to reduce the time it takes to write them before they improve your code and reduce your cost of development.
- On the plus side : Bugs caught earlier, bugs fixed quicker, risk free testing against external components * On the minus side : Teams can lose confidence in tests, not knowing what they test, being too costly to maintain, too long to run, and written in different ways.
Unit tests must be trustworthy. Developers must have confidence the code works by passing tests rather than pressing F5. Unit tests must be treated as first class citizens in the code base, easy to maintain and well documented.
Developers must identify units precisely and ensure there is full test coverage of a unit in order to realise the benefits of TDD. This is not the same as 100% code coverage. If units are only partly covered by tests, hidden bugs may appear in the code and confidence lost in the test suite. Furthermore, it is harder to add unit tests retrospectively to brownfield code, and it can be the case that the false sense of security allows additional bugs to enter the codebase purely because you’ve forgotten to completely cover your units.
Isaac also offered the following suggestions for writing unit tests.
- Have a set of patterns and practices for all your team to follow. Use fxCop for instance to enforce those rules. * Test one thing per test. There are only four things a unit test should test: * Output : The return value of a functionMutation : Whether a public property changes its valueAssertions : Whether a class calls another class correctly Message Parsing : Whether a class responds to another class correctly. * Remember that a unit test is not an integration test. Don’t query a database, span several units, rely on web services etc in a unit test. Use mocking frameworks instead. * Put as little in setup and teardown functions as little as possible. You end up coupling your tests with your setup and eventually you cant figure out which part of setup applies to which tests in the suite. Avoid creating mocks and test data there. * Use code features (builders, stubs, optional params, named params and others) to keep your tests as simple and as readable as possible. * Keep an eye out for boilerplate code. Decouple it from your code under test.
In conclusion, the aim of every development team with respect to TDD should be to believe, trust and listen to their tests.
An Intro To Octopus Deployment – Joel Hammond-Turner (@rammesses [http://twitter.com/rammesses]) Octopus is a Continuous Deployment server built around Powershell and nuGet that creates a robust and reliable way to commit and rollback deployments of your software into various different environments : CI server, development machines, integration testing, UAT, Live, etc. In this talk, Joel gave an overview of how Octopus achieves this and then a live demonstration. He also made the following notes
- Octopus integrates well with CI systems (tfs / teamcity / etc). * Its sweet spot is deploying web applications to IIS * Octopus has a RESTful API which you can script against so you can write your own scripts to do the deployments for you. * Octopus deploys to Azure as well as a single or cluster of servers. * Octopus is like Ronseal – it does exactly what it says in the tin.