I’m writing a post series about writing an interpreter using TDD (Test-Driven Development). My intention is to show the use of TDD in our production code. Since my TDD adoption, I produce better code (I hope😉, and in less time (no more long debugging sessions😉. There are other benefits: if you have an application with TDD, you get good code coverage, and you write down the code use cases and expected results of the application. All that gives confidence to improve the application, maybe by other team. In my opinion, delivering an application with TDD is a plus for the end customer and for the healthy evolution of a successful software. You can get the same using simply test, but TDD adds the right iterative process to build production code.
But the interpreter example is like a “long code kata”. You can say: “Hey, it’s not the kind of code I write every day, for fun and money”. Yes, you are right. Then, it’s time to start a post series about writing an application.
I choose the technologies to use:
– .NET 3.5 (maybe, I’ll switch to 4.0)
– ASP.NET MVC 2 (again, I could use 3, at some point)
– Visual Studio 2008 (the other candidate is VS 2010), using its test features, as in my previous posts.
There are two path to follow, in this iterative example:
– Simple domain: start to write presentation code and test, then an application layer, then the persistence stuff
– More complex domain: write the domain code and test, then add presentation, then the persistence.
The first one is a kind of “top-down” approach. It’s the opposite of I was using in my interpreter series (note the absence of mocks, stubs in my “bottom-up” approach, writing the expressions, commands, then part of the lexer, part of the parser, etc…). With this new way of doing TDD, I want to show the incremental build of functionality, even without having a database, persistence model, or other technical stuff. ASP.NET MVC and TDD able us to write the initial use cases in a simple way, in a simple domain, embracing an agile and incremental development. Another benefit is that we can deliver something “that works”, to get early feedback from customer.
After exploring such way of doing development with TDD, I will switch to a slightly more complex domain. In such case, I will prefer to start writing the domain with tests, only to focus in the core of the application, adding some presentation stuff, but without spend much time in complex interface stuff.
The format of a post series is important: there are many examples of application code with TDD (many open source projects), but most of them are the “final” stage of a long path. Writing a simple example incrementally is a better way to grasp the TDD-style of doing software development.
Well, enough for today. This is an intro post, to present the idea, and starting the engines! Comments and suggestions, welcome.