in

Ative at Work

Agile software development

Ative at Work

Saved by the ITimestampProvider

If you are doing any kind of timestamping on your data, testability requires you to get the timestamps from a mockable provider, rather than using unpredictable and thus untestable values from the system.

For this purpose we usually inject an ITimestampProvider with methods to get the UTC time into any classes that need it.

Earlier we worked on a military project that did not do this. Instead it relied on a combination of the application and the database assigning timestamps.

Unfortunately SQL Server DateTime does not offer the same precision as System.DateTime in .NET meaning that the timestamps were truncated to a lower precision when written and so an object read back from the database would not equal the object that was written.

This is bad for testing. The OR-mapping code in the system was legacy code (meaning: code without tests) so they didn't know this until very late in the project. At that time, fixing it incurred a great cost.

On our current project we are using an ITimestampProvider and assigning timestamps in the application. The datastore is used for just that - storing data.

A side-effect of this is that when we discovered some failing tests in the persistence layer due to timestamps being truncated by the database we only had to modify the application in one place: have the timestamp provider provide data that matches the precision of the datastore (we don't need more than a precision of seconds anyway).

In effect, the requirement to make the code testable forced us to introduce better, more loosely coupled design which in turn saved us a lot of work downstream.

This way test-driven development is not just about line-by-line code quality. It also drives the system towards a higher quality design.

Published nov 14 2006, 11:39 by Martin Jul
Filed under: ,

Comments

 

Søren Lindstrøm said:

Allong the same lines: I my current project the system-time is injected at startup. This is huge advantage during both unit- and regressiontesting, since it is very easy to simulate "passage of time". This refaktoring has saved the project vast amounts of testing complexity, thus expenses.  

november 17, 2006 2:46
 

Frederic Gos said:

>In effect, the requirement to make the code testable forced us to introduce better, >more loosely coupled design which in turn saved us a lot of work downstream.

People often ask me why we need to have interfaces and loosely coupled classes. When I tell them 'It's because that's the way software ends up when you need to test stuff', most look at me in disbelief. They probably thought it was just because i wanted to be fancy. ;) Test first leads to fancy TESTABLE & FLEXIBLE software.

I love it when developers come back after trying this reluctantly for 2 month and say 'ooh my, this is cool'. The joy in their eyes makes up for the endless discussions and frustration in trying to explain to them why TDD is the way to go.

december 29, 2006 1:18

About Martin Jul

Building better software faster is Martin's mission. He is a partner in Ative, and helps development teams implement lean/agile software development and improve their craftmanship teaching hands-on development practises such as iterative design and test-first. He is known to be a hardliner on quality and likes to get things done-done.
© Ative Consulting ApS