I think it's safe to say that at this point, having SOME sort of automated testing for your application is considered a best practice. Unfortunately, creating a testable application is like having 6-pack abdominal muscles: everyone wants them but few are willing to put in the hard work to make it happen. This talk will approach the idea of Test-Driven Development / Behaviour-Driven Development from a different angle, instead taking a look at strategies for structuring your application is such a way that continuous integration and delivery of your application is not only possible but easily achievable. We will start by looking at anti-features of an application: ways of building things that make them very difficult to test. From there we will progress onto things like Demeter's Law, dependency injection and how to create the complementary infrastructure to test your application. Finally we will focus on building your confidence level with respect to flawless deploys from "all hands on deck, we're deploying" to "that's the 12th change we pushed into production today".
Test Driven Development can be hard. Oh, sure, it's easy to write the standard bank account tests that you see in all of the demos. But what about real life? What about that service that hasn't been developed yet? What if the code you are trying to test doesn't follow Uncle Bob's SOLID principles? I will show you how free mocking tools will brighten your day!
11th–13th January 2012