Often a situation faced by coders, especially when following test-driven development, is the writing of very similar test cases, changing only in, for example, the expected and actual values, along with some set up parameters. We often end up writing dozens, nay hundreds of near identical test cases, and end up with a test class that looks that it has suffered from a terminal case of copy-paste. This blog post shows a little-known technique for making this sort of test class a little more readable using the nUnit TestCase attribute.
On 17th January the engineering team at here at thetrainline.com hosted a meetup of the London Continuous Delivery group at our offices in central London. About 50 group members were joined by 15 or so staff from thetrainline in a discussion led by Andy Hawkins from Opscode, originators of infrastructure automation tool Chef. We saw a demo of Chef working with ThoughtWorks GO to build EC2 instances, and there were interesting discussions on auto-scaling and organisational change.
Update: podcast now available…
Recently, we were fortunate to be joined by Steve Freeman (@sf105), co-author of Growing Object-Oriented Software, Guided by Tests, and one of the early practitioners of Test-Driven Development (TDD). Steve facilitated a discussion at our weekly dev session (aka Burrito Club) on how tests can and should be used to help shape the growth and evolution of software, particularly the use of Ports and Adapters to make testability a first-class concern.