It's common practice for developers to make small "TODO" notes in code as they work for themselves or others to clarify at some time...
// TODO: confirm this business requirement...
// TODO: make this better!
// TODO: bread, butter, eggs and milk...
Issues can arise when the TODO's are not taken care of for whatever reason or get lost in the mayhem of meeting deadlines. A worst case scenario could arise when there is a production defect for an obscure situation and the maintenance programmer finds something like this:
// TODO: Not sure if there are any more response codes for this one, check before release.
Opps! Now that's expensive.
Now I am not saying this is good or bad (!) practice - but what I have started to do within my team is create either a
failing or
ignored unit test (depending on the importance) marking what would normally be an innocent "TODO" item. The unit test stays in the build as either a fail or ignore and does not drop off the radar.
[Test]
public void Need_to_confirm_foo()
{
Assert.Fail();
}
Or...
[Test]
[Ignore("Confirmation required from the business")]
public void A_foo_only_has_a_bla()
{
}
It's much harder to miss a bunch of ignored or failing unit tests before that production release than some well hidden TODO comments!
Subscribe