Question

Recently I was assigned to a project which was already in its midway. It was TDD environment.
Everyone was following right principle of Code Unit Test First and Implementation code later. But couple were doing in reverse, implementation code first and unit test later.

Though on a debate they say either way its similiar.

What are potential issues may arise if implementation code first and unit test later is followed?

Answer 1

• Overengineering – you may have written more code than you actually need.
• Bias – you may write tests that test your implementation rather than the requirement.
• Tests wont drive your design – tests can signal design improvements. Over time your design can become rigid and averse to changes.
• Slow you down – your implementation may have testability issues which will surface only when you attempt to write your tests. By which time, you may be inclined to kludge something up because now the test is standing in your way to implementing the next feature. Trying to unit test an untestable blob is frustrating.. more often you will end up with non-thorough tests (test what is easy and move on).
• Tests may not be written – once your implementation is ready and you’ve manually verified it to work, there is a tendency to skip the boring unit tests and skip to the interesting part… writing more code. Over time, untested chaos.

If it isn’t obvious enough, test-first FTW!