-have to change them less
-test first doesnt work with gui
-put into code just seperate starter
+The rise of Extreme Programming (XP) gave also rise to Test Driven Development (TDD),
+where you start the implementation by building tests. The rationale behind this:
+You have to think about what to achieve by defining it with a small program.
+Then it's easier to write the code and the new failing test motivates you to do so.
+And as soon you brake a function or specification, the testing suite will yell
+at you and you are spared of a very time consuming bug search 10 month later,
+when angry user yell at you, because the program deleted their data.
+Problem with this theory: its so hard to write out of the blue, because your
+notion of this code might be very vague at first. But even if you have a billiant
+idea, there are still a lot of details to be added and altered while you grok
+the algorithm, its use cases and its role in the larger scheme fully. And having
+to rewrite the code and the tests several times is frustrating. Besides - tests
+first is not even doable for GUI and other areas where the supporting structure
+has to be built first. Tests just can be modeled after it. A startling read about
+even more prescribed madness in software testing is Elisabeth Hendricksons paper:
+"better testing — worse quality?" at L<http://testobsessed.com/wp-content/uploads/2011/04/btwq.pdf>
+But the other benefits of testing are stil as worthwhile as describes by TDD people.
-BETTER TESTING — WORSE QUALITY?
+That's why in CP we write the tests hopefully once, after the dust is settled.
+Because tests are so precise, writing them down will give us a precious opportunity
+to rethink the code one last time from a logical and technical perspective.
+Because all the other issues were already solved we are now free to give special
+attention to the corner cases we may have overlooked so far. Yet another case of
+a better result with less effort in CP.
+One point that is still experimental, but worth considering is putting the tests
+into the code in the same file as the code it tests. The test suite will then be
+just a different "starter" for all this code, but no seperate dir tree of code.
+That would be really holistic. Writing tests would be easier, even if good editors
+can display several files beside each other and test would functions as an
+additional comment, explaining what we we want to achieve here. In fact to the
+parser of the main program test will appear as comments. This might be hard to
+realize in some languages, but not problem in Perl 6 and even Perl 5 should have
+at least one way to do that.