Can I target TDD or BDD in my project?
I decided to try TDD and BDD on my already running project, helped by the answers to questions like: Should I start using TDD in a project that doesn't already use it
I am struggling to start with this. My project (openource hosted at http://gitorious.org/rubots ) is like a game and uses Ruby to port and connect to the server control and physics simulation environment. The script is executed, the GUI appears, and when the user clicks the start button, 2 external C ++ programs are launched, one of which is physics simulation, they are driven by a library with Ruby bindings. The simulation and the control program cannot be abandoned, they must be started again. Start them up and get them up and running like 5 seconds. In this context, any test needs of the entire initial phase are moved before anything else, and the mock depends on external config files that must also be provided.
Is it really worth starting writing test cases? How? Each test with: before or similar, which launches the game, launches applications, etc.? Then each test will take at least 5 seconds (and much more if I have to execute a command and wait for the simulated objects to respond).
I am missing something. Should I skip not only BDD and TDD but also test blocks for this type of application?
source to share
In RubyConf 2007, William Bereza of Atomic Object talked about Enhancing Embedded Development with Ruby , in which he describes how they apply the principles that Atomic Object stands for (Agile, BDD, Automated Tests, ...) to an embedded project involving autonomous robotic vehicles. A couple of months ago, he gave the same talk at O'Reilly OSCON 2007 .
The Atomic Objects site has many resources:
- Agile Embedded Software Development ,
- Papers ,
- Presentations and
- Free software including
There is also a great story about Ward Cunningham and TDDing's embedded system, which Robert C. Martin ("Uncle Bob") told about in his RailsConf 2009 label (history goes from about 3:50 pm to 5:20 pm). The story goes something like this:
Bob comes to Ward, who brings him to the basement, where he looks at the little circles on the screen as the coolest thing in the universe, and he is as excited as a little kid unrolling his first bicycle for Christmas. What he did was try to figure out how a fully TDD device was embedded (in this case a video converter) without even touching the device at all. What he did was as follows: he started writing a Unit test in JUnit using a mock. Then skipped this test, etc. as usual. He then replaced all the methods with the 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 did extremely simple things like "write int
to register" or "read abool
from the register flag ", for which the assembly code was so simple that it was" clearly correct ".
And of course, when he put together his generated code and flashed the device, it worked for the first time, without him ever trying code on the device, and also without writing any significant build code.
So there are two approaches: in the case of Atomic Object, they wrote the software in C and the tests in Ruby, and generated the tests from Ruby code. In Ward's case, he wrote tests and code in Java and generated code from Java code.
source to share
This requires stubs. Basically you create a Test Double that stands for objects that access expensive services (like in your case) or do other things. This allows you to isolate the object during testing and run faster tests.
It's not just to speed things up. Let's say you are writing middleware code for making transactions through Paypal. You probably don't want to use Paypal while running tests, which can be expensive (literally).
Mocha is good for this kind of thing. Or just create an object that acts like your web service object like (since this is Ruby if it walks around like a duck ...).
source to share