"Why should I, it works..." The idea of Test-After Development
is to write a set of automated white-box tests after writing
your production code. Since probably every CS student in the
world has learned that unit tests are a good idea, you'd expect
unit testing to be an industry state standard for quite a while
now. Interestingly the idea of automated unit and integration
test is lately becoming more popular due to the widespread use
of Test-Driven Development. So why do we need Test-Driven
Development to be able to efficiently write automated unit
tests? - If you write your code first and don't think about how
to test the code, the code will not be testable. Thus testing
becomes expensive and frustrating. Test-Driven Development will
guide your software design by the old mantra of "how-do-I-want-
to-use-this-class", leading to a highly decoupled design. - When
you write your tests, you'll discover a lot of errors. But
instead of the red bar in Test-Driven Development, which you
expect, the red bar in Test-Aft