TID: Test-If-Development (A more pragmatic TDD)

The moment you need to introduce some if-logic into a method, you jump over to write the test, but not before.  This approach argues it is unnecessary overhead to write the test before you create the method because the method could be absent of any conditions, in the case it is comprised of calls to other methods.

Example - not needing a test

void populateContactInfo() {
   populateName();
   populateAddress();
   populatePhone();
}

Example - needs at least 2 tests because there are 2 branches of code

void populateContactInfo() {
   if (hasName) {
       populateName();
   }
   else {
       populateDefaultName();  
   }
   populateAddress();
   populatePhone();
}

The phrase Test-If-Development has one other benefit.  That is,"If" you are doing "Development", you "Test". Period.

Read More »

Programmer Productivity Hypothesis

Based on my observations and experience, I believe the following to be the business case for paying down Tecnical Debt.

• The acronym "DRY" stands for Don't Repeat Yourself. 
• Code Coverage means the lines of code exercised by automated tests.

DRY code yields full percentage gains in productivity.

If you have 100% duplicated code and clean it up to 0% (purely hypothetical) then your productivity improves by the same 100%. In other words, what took a team of 8 now takes a team of 4 because the amount of code to wade through is half. If your team did 16 points per sprint, they can now do 32.

Thus,
PRODUCTIVITY = MAX_PRODUCTIVITY * (1 - DUPLICATION)


Example: Team currently does 20 points, has 30% duplicate code. Their maximum productivity is...
     20 = MP * .7
     MP = 20 / .7 = 28 points
   This means the team could work on lowering duplication from 30% to 0% to bring up their productivity from 20 to 28.  Now size what kind of effort that would take to reduce duplication in order to make the right business decision.


Code Coverage yields half percentage gains in productivity.

If you have 0% Code Coverage and write unit tests so that it reaches 100% (purely hypothetical) then your productivity improves by 50%. This is due to the fact that while unit tests reduce defects and rework, it creates more code to maintain. In other words, what took a team of 8 now takes 6 because you can modify code, refactor safely, and add tests more easily. If your team did 16 points per sprint, they can now do 24.

Thus,
PRODUCTIVITY = MAX_PRODUCTIVITY * .5 * (1 + CODE_COVERAGE)

Example: Team currently does 20 points, has 30% code coverage. Their maximum productivity is...
     20 = MP * .5 * (1 + .3)
     MP = 20 / .65 = 30 points
   This means the team could work on increasing code coverage from 30% to 100% to bring up their productivity from 20 to 30.  Now size the effort it would take to write that many unit tests in order to make the right business decision.


Please let me know your thoughts.
.

Read More »

Presentation - ATDD Survival Guide

Download the presentation here: Slide Deck

Abstract:

Learn how to implement Acceptance Test Driven Development on any technology platform… even yours! Come for Engineering tips and Business Acceptance Tests tips to avoid a tangled mess.  See how ATDD can fit into your process.

Read More »