JAOO 2007, Day 4

Today I participated in Robert C. Martin‘s Class for Test Driven Development. Required was at least a notebook this was easy to satisfy, my Sony Vaio TZ has it’s first long running task to do. Robert C. Martin is one of the most active people who advocate TDD and he is a great presenter. The content of the course is relatively simple: he provides some FITnesse test cases and the first JUnit test cases including some unimplemented base classes for a simple text adventure game (the thing the older one of us remember playing on the first IBM PCs). The first challenge of most people was to get it up and running on Eclipse because he only provided project files for IntelliJ. After this, he explains some of the basic practices of TDD and he and the audience begane to program. Everyone was very disciplined, so writing a JUnit test, implement the functionality and run also the FITnesse tests was no problem at all. So everyone implemented the stories bit for bit, re-factored the code after the tests successfully run. After 4 hours of the tutorial duration everyone has a basic game running, navigating correctly in a arbitrary maze and the code definitely looks better than normally. FITnesse is sometimes a bit cumbersome, but it works very well and is based on a really simple interface language. The main disadvantage is that someone has to write the business case use cases and this should definitely not be the developer. So for using FITnesse, you have to convince some tester, manager or QA guy to write down what he wants as acceptance test.
Some other tips:

  • If you have private functions you want to test, move them to a class there they can be public. Mostly they are in the wrong place
  • Clean up and re-factor your code every time a new test runs successfully
  • Use comments in code sparingly because it smells of bad programming if the code is not clear to follow
  • Keep functions and tests as small as possible
  • Try to find useful names for functions and tests
  • If you work with modern IDEs, learn their shortcuts for using the advanced refactoring capabilities.
  • Design your project first, but be aware that tests change the code and the structure of the intended design because they actively use the functionality!
  • Sometimes break the rules if you must, but be aware of them and make it no habit



No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: