TDD, BDD or NoDD
Can Factory have successfully used all these development testing approaches, and really they all have their place. Often the hard part is deciding which fits best.
So many software developers become wedded to Test Driven Development (TDD), or Behaviour Driven Development (BDD), that they forget about the end product itself. Some technologies (IOS and Android jump to mind), are just hard to test automatically and often we have found it quicker just to stick to good old fashioned design and manual testing – lets call that NoDD. Maybe if we were running larger teams we would regret this.
When developing server side code (provided we don’t need to wrap ourselves in mocks and fixtures), we prefer to write automated unit tests, and if it seems appropriate, we try to write them before code (or any significant amount of code), has been written. As the creator of Ruby on Rails wrote in a recent blog, obsessing around the mechanics of TDD kind of misses the point, which is to improve the quality of the software and most importantly give developers the “courage to change” – to have trust in those who have gone before them to have written good enough tests to catch the mistakes and misunderstanding of those to come.
So lots of unit tests will certainly help, but the problem is our customers don’t buy units. They buy solutions (just selling software is so passe, according to our marketing team). Ford sell cars, not engines, gearboxes and wheels. The units don’t solve problems, to do that they collaborate with other units and systems. And to prove these are working correctly needs higher level tests. Tests that describe behaviours, preferably written in such a way that a customer or user could understand the purpose of the test. Not a test that confirms unit X is generating the correct JSON string. So where we can, we try to write these behavioural style tests as well. They rarely drive our development, so its a stretch to say we do BDD, but they are still very useful.
Writing behavioural style tests can be challenging. And at times it’s hard to describe the difference between behavioural testing and functional testing. Possibly because once the “As an X, When I do Y, Then Z happens” pattern is stripped out, the final tests aren’t so different. It becomes more about the mindset.
We don’t use any particular tool. Good architecture and design will make it easier to replace or manage the slow and unreliable parts of the application when running these tests. Automated testing via a browser is just painful, so if we can reduce the final page rendering to the simplest possible code by using logicless template engines such as Mustache, we can often bypass the browser, yet still have good tests. We have not as yet felt the need to look at a BDD tool – a quote from Dan North, who coined the term BDD, sums it up – “the use of BDD requires no particular tools or programming languages, and is primarily a conceptual approach; to make it a purely technical practice or one that hinges on specific tooling would be to miss the point altogether – https://guide.agilealliance.org/guide/bdd.html#sthash.KldqWCMG.dpuf”
