Tuesday, September 30, 2008

TDD vs TAD (Test After Development)

TDD offers the following benefits:
  1. Bugs are prevented or found early. Finding bugs late is expensive!
  2. Refactoring can be done with confidence. If the code has proper test coverage, it is unlikely that future refactorings will break it.
  3. Thinking of and designing for edge cases up front promotes a better and more stable design.
  4. One is forced to think about how the code will be used first, which should lead to code that actually meets its requirements.
  5. Less code! TDD is usually coupled with DTSTTCPW.
Theoretically, TAD applies to 2 and maybe 1. In practice, is this really the case? In my experience TAD is far inferior to TDD because its execution is sub par in the following ways:
  • Many TAD project just test the "complex" parts of the code.
  • Most TAD projects start out well, but end up with unit tests that just increase code coverage with little thought to quality.
  • Testing after development requires the developer to figure out the intent of the code again.
  • TAD does not benefit from 3, 4, and 5 above.

Labels: , , ,

Wednesday, September 24, 2008

Slow Adoption of TDD

Why is the adoption of Test Driven Development (TDD) so slow and why do developers not like to right tests?

Scott Ambler seems to be implying that since adoption of TDD is lagging, maybe the agile community should not be focusing on it.

I don't think there is a simple answer to the question, but I believe it involves:
  1. Developers are not seeing the benefits.
  2. Developers believe that it slows them down and since they are under constant pressure to produce a lot of functionality they take shortcuts.
What are the benefits? This has been documented extensively

Does it take longer to write TDD code? No! Firstly, a developer is less prone to write code that is not needed because the focus is usually on just passing the tests. TDD forces a developer to think about design before production code is written, which should result in less refactoring. Finally, the biggest time saver is discovering and fixing bugs right away as opposed to weeks or months down the line. 

Labels: , , ,

Tuesday, September 23, 2008

The inaccuracy of software project estimation

There are still many people that believe a software project can be estimated accurately up front. Industry-wide it is commonplace that costs and delivery dates go well over what was origninally estimated by 200% or more on non-agile projects.

  • When developers estimate a particular requirement or feature, they seldom think of everything especially on large tasks.
  • Customers seldom think of all the requirements up front.
  • Requirements change throughout the project. With traditional software processes, this is mitigated by change-control, but is this really change-prevention? Is a project really succesful if it delivers what the customer wanted at the beginning, but not what is really needed at the end?
  • Skill levels of BAs vary greatly. Developers can implement a requirement perfectly, but if the requirement is wrong the implementation is useless.
  • Skill levels of Developers vary greatly. It has been documented in many places such as The Mythical Man-Month and Peopleware that good developers can be up to 10 times more productive than average developers and bad developers actually contribute "negative-work" to the project.
If you are in an organization that does not allow agile at this time, but you want to estimate as accurately as possible, I recommend reading a great book by Steve McConnell entitled Software Estimation.

Labels: ,

Thursday, September 18, 2008


On my current project, we recently switched from Watin to BadBoy for functional testing. Watin is an excellent testing framework, but we ran into a lot of timing related "issues" because our application is AJAX intensive. A brief description of BadBoy follows.

BadBoy is a functional web application testing tool for non-programmers. It is a record-then-playback testing tool that builds up a “Script Tree” while in record mode, which allows for a variety of assertions, then in playback mode it simply runs the script and tests the assertions.

BadBoy offers Navigation and Request recording modes. Navigation mode is the traditional recording mode found in most record-then-playback tools; it records all of your mouse and keyboard activity. Request mode records just the HTTP requests and posts, which is ideal for load testing.

BadBoy is a good choice for functional testing on a project that has QA resources tasked with automated testing. If the primary functional testers are developers, a better choice is probably Watin or Watir as they are not just recorders, but they also allow for test configuration in code.

Labels: ,

Monday, September 15, 2008

Less is More

While contemplating the merits of agile development it occurred to me that it is really all about less.

Labels: ,

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]