Perry Hertler

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

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.