What are the pitfalls of test after development?

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

Answer 1

Testing before implementation is always encouraged. Aside from actually fixing bugs that may have been existing in your software it helps weed out what bits of your code are necessary as an engineer may have the tendency to 'over code'.

What I always tell myself "If i was writing software for a plane auto-pilot, what would I do to make assure myself that that piece of software would never fail?" Would these people doing it in reverse put their family on auto pilot before testing the software? Thinking like this helps give a disciplined approach to software engineering.

Answer 2

Writing the tests first and implementing after ensures that you are writing implementation code that is definitely going to pass the tests. Implementing first and writing the test code after runs the inherent risk that you will have to refactor (sometimes significantly) your implementation code to ensure correct testing coverage, which can become expensive depending on how late those tests are written.

Personal experience, I've seen the best productivity/medium come from developers doing the tests concurrent to the implementation, doing enough up-front to ensure the boundaries of the interface contracts are correctly locked in and test-worthy, leaving tests that would not cause redesign/major refactoring toward the end, but not considering the component complete until a complete set of unit tests were delivered.

Answer 3

• 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!