Perry Hertler

Saturday, May 30, 2009

TDD in the Real World Slides

Here are the TDD in the Real World slides for the Chicago Code Camp presentation that I gave on May 30th.

# posted by Perry Hertler : 9:13 AM 0 Comments

Tuesday, May 19, 2009

Chicago Code Camp

Be sure to attend Chicago Code Camp on May 30th at the College of Lake County (CLC), in Grayslake, IL.

I will be doing a presentation entitled TDD in the Real World. There will be a lot of real-time coding! It should be fun.

Labels: Agile, Conference, Redpoint, TDD

# posted by Perry Hertler : 4:14 PM 0 Comments

Monday, November 3, 2008

Testable Code

One of the best ways to ensure testable code is practice Test Driven Development. How can code not be testable if it is already tested?

Another good idea is to write code that is easy to test in isolation, which is mostly done by mocking its dependencies. "Mockable" classes are achieved with:

Injecting dependencies with an Inversion of Control framework such as Spring
Avoiding singleton and static methods
Favoring composition over inheritance

Labels: Agile, Mock, Redpoint, TDD

# posted by Perry Hertler : 9:44 AM 0 Comments

Friday, October 24, 2008

Mock Example

Mocking is a great way to test a class in isolation. Not only can determinisitic results of the mocked class be forced, but parameters to the mocked object's methods can be tested.

Here is a unit test that uses mockito as its mocking framework. It is organized in the increasingly popular Arrange / Act / Assert format. This tests a yet to be written subclass of Spring's AbstractJDomPayloadEndpoint.

  1 @Test
  2 public void validDepthOfField( ) throws Exception {
  3     stub( _depthOfFieldCalculator.calculateDepthOfField( _expectedDofParams ) ).toReturn( _depthOfField );
  4
  5     final PhotoEndpoint photoEndpoint =
  6         new PhotoEndpoint( _depthOfFieldCalculator );
  7     final Element dofElem =
  8         photoEndpoint.invokeInternal( _depthOfFieldRequest );
  9       
 10     Assert.assertEquals( _depthOfField.getFarLimit(),
 11             _parseDouble( dofElem, _farLimitExpression));
 12     Assert.assertEquals( _depthOfField.getNearLimit(),
 13             _parseDouble(dofElem, _nearLimitExpression));
 14     Assert.assertEquals( _depthOfField.getHyperFocalDistance(),
 15             _parseDouble(dofElem, _hyperFocusDistanceExpression));
 16 }

Line 3: _depthOfFieldCalculator was mocked with mockito in JUnit's @Before. If calculateDepthOfField(...) is called with a object matching _expectedDofParams(equals overridden), _depthOfField will be returned. Important to note that if the calculateDepthOfField is called with the wrong parameter, the mock will return null.
Lines 5-6: Create a class that does not yet exist with our mock.
Lines 7-8: Call the endpoint's invoke method that is under test.
Lines 10-15: Assert that the returned Element is valid.

Labels: Mock, Redpoint, TDD

# posted by Perry Hertler : 3:50 PM 0 Comments

Tuesday, September 30, 2008

TDD vs TAD (Test After Development)

TDD offers the following benefits:

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.

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: Agile, Redpoint, TDD, Test

# posted by Perry Hertler : 11:18 AM 0 Comments

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:

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.

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.