Tuesday, September 30, 2008
TDD vs TAD (Test After Development)
- Bugs are prevented or found early. Finding bugs late is expensive!
- Refactoring can be done with confidence. If the code has proper test coverage, it is unlikely that future refactorings will break it.
- Thinking of and designing for edge cases up front promotes a better and more stable design.
- One is forced to think about how the code will be used first, which should lead to code that actually meets its requirements.
- Less code! TDD is usually coupled with DTSTTCPW.
- 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: Agile, Redpoint, TDD, Test
Wednesday, September 24, 2008
Slow Adoption of TDD
- Developers are not seeing the benefits.
- Developers believe that it slows them down and since they are under constant pressure to produce a lot of functionality they take shortcuts.
Labels: Agile, Mock, Redpoint, TDD
Tuesday, September 23, 2008
The inaccuracy of software project estimation
- 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.
Thursday, September 18, 2008
BadBoy
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.
Monday, September 15, 2008
Less is More
- Less code because only enough code is written to satisfy a Story requirement.
- Less defects while writing code through TDD.
- Less time spent fixing defects because considerable effort goes into early detection of bugs (Continuous Integration).
- Less regression bugs because code is protected by good unit tests with adequate code coverage.
Subscribe to Posts [Atom]