Can I aim for TDD or BDD in my started project?

Question

I have decided to give a try to TDD and BDD on my already started project, encouraged by answers to questions like this: http://stackoverflow.com/questions/294909/should-i-start-using-tdd-on-a-project-that-doesnt-use-it-already

I am struggling to really start with it. My project (opensource, hosted in http://gitorious.org/rubots) is game-like and uses Ruby to wrap and connect to a control server and a physical simulation environment. The script is executed, then a GUI appears and when the user click on start 2 external c++ programs are launched, one of them being a physical simulation, they are controlled by a library with Ruby bindings. There is no way of reseting the simulation and the control program, they should be started again. Start them and have them in a working state takes like 5 seconds. On this context any test needs of whole starting phase before anything moves and the simulation depend on external configuration files that should be provided also.

It is really worth it start writing test cases? How? Every test with a :before or similar that starts the game, launch the applications, etc? Then every test will at least take 5 seconds (and considerably more if I have to commit a command and wait for the entities of the simulation to answer).

I am missing something. Should I skip not only BDD and TDD but also test units for this kind of application?

Answer 1

This is what stubs are for. Basically you create a Test Double that stands in for objects that access expensive services (like in your case) or do other things. This allows you to isolate the object while testing and have faster running tests.

It's not only for speeding things up. Say you're writing some middleware code to do transactions through Paypal. You probably don't want to actually use the Paypal service while running tests, which can be expensive (literally).

Mocha is good for this sort of thing. Or just create an object that acts like your web service object acts like (since this is Ruby if it walks like a duck...).

Answer 2

At RubyConf 2007, William Bereza of Atomic Object gave a talk about Enhancing Embedded Development with Ruby, in which he describes how they applied the principles that Atomic Object stands for (Agile, BDD, Automated Tests, …) to an embedded project involving autonomous robotic vehicles. A couple of months earlier, he had given the same talk at O'Reilly OSCON 2007.

There's a wealth of resources on the Atomic Objects website:

• Agile Embedded Software Development,
• Papers,
• Presentations and
• Free Software including
  • SysTiR (System Testing in Ruby) and
  • Unity - Compact Test Framework for (Embedded) C

There is also a great story about Ward Cunningham and TDDing an embedded system, that Robert C. Martin ("Uncle Bob") told during his keynote at RailsConf 2009 (The story goes roughly from 15:50 to 17:20). The story goes something like this:

Bob comes to visit Ward, who took him down to the basement, where he is staring on little circles on a screen like its the coolest thing in the universe and he is excited like a little kid unwrapping her first bicycle on Christmas. What he had done, was trying to figure out how to completely TDD an embedded device (in this case a video converter) without ever touching the device at all. What he had done, was the following: he had started writing a Unit test in JUnit, using a mock. Then made that test pass, and so on, just like you would normally do. Then he replaced all the methods with ones that generated the appropriate assembly code for the device. Since all the logic was written (and tested) in Java, the "leaf" methods themselves were extremely simple methods that only did extremely simple things like "write an int into a register" or "read a bool from a flag register" for which the assembly code was so simple that it was "obviously correct".

And, sure enough, when he assembled his generated code and flashed the device, it worked the very first time, without him having ever tried the code on the device, and also without him having written any substantial assembly code.

So, that's two approaches: in Atomic Object's case they wrote the software in C and the tests in Ruby, and generated tests from the Ruby code. In Ward's case, he wrote the tests and the code in Java, and generated the code from the Java code.