Some newbie questions about TestDrivenDevelopment...

----

'''Q:''' Suppose I want to write a fairly complex program to read the moves of a chess game and to emit an HTML page containing JavaScript that allows a user to play through that game.

What is an appropriate first test?

* Input a game with no moves and output an HTML page of that trivial game?

or

* Create some object (e.g. a board or a move) and test some method on it?

In other words, how would most people start: top down or bottom up (or both)?

'''A:''' I would start bottom-up.  (As a TestFirst advocate, I'd like to hear PhlIp's opinion on this.)

Either of those sound like good early goals. However, your first test should be assertTrue(false) just to make sure your UnitTest framework is working.

----

'''Q:''' I don't have experience with XP. So, what would people ''guess'', what is the ProductionCodeVsUnitTestsRatio, if you consequently CodeUnitTestFirst. In terms of lines? n terms of time needed to write? 

'''A(1):''' Seems to vary with practitioner. Surveying the XP books, some articles place the loc count equal, but others talk of the number of test methods being around 1/4 of the number of tested methods (as a result of a single test exercising several related methods). I doubt people are saying the test code has longer methods, so there is quite a large gap here.

'''A(2):'''' One data point: for a project just completing using many XP practices, the total lines of code is almost 20K, number of classes is 59, and the number of methods is 638. The test code is almost 8K lines, 17 classes, and 261 methods.

'''A(3):''' In my very limited experience, my production and test codebases have about the same number of lines of code. There's certainly the same number of methods (each production method should be tested by one testing method).

----
CategoryTesting