Slashdot

I've recently been writing unit test code at work, for work, based on preliminary experience with thuds. It's going a lot smoother at work than with thuds, and it took me a while to realize why:
I don't control requirements of the code I write at work, so I do almost no "rethinking" ("inline design refactoring") while writing the unit test code for the product at work.
I should note that I'm writing test code for product that has already been 90% completed. Due to the overall complexity of the product, writing test code was simpler than writing unit test plans and scripts and then doing and tracking them. I know the unit test code should be written first with agile development, but I don't control the software development lifecycle process at work.
The unit test design thinking/rethinking process with work code goes like this:

• The unit test code is hard to write, so is the test that I'm writing too complex or is it the product code I'm trying to test?
• If the test is too complex, simplify test, rethinking done.
• else look at the product code: is the product code in too big a chunk? (nearly always, "yes")
  • then refactor product code into smaller chunks

• else is the product code too complex? (only sometimes "yes")
  • then refactor product code into simpler chunks

• else am I vague on the requirements of the product code? Surprisingly since I wrote this code myself, the answer to this is sometimes "yes".
  • then relook at the assembler that I am rewriting to gain greater insight into requirements, then refactor product design and code accordingly.

• Refactor/redesign unit test and write code for unit test

With thuds, when I run into a difficulty with the test code, I rethink too much. That is, I rethink these topics:

• The unit test code is hard to write, (so see above list up to but not including "am I vague on the requirements....")
• Am I vague on the requirements of the thud code? If so, then
  • rethink the requirements I am coding to
  • CHANGE product requirements
  • and "refactor" (actually, "change") product design and code.

• Since thud's unit test requirements have changed, redesign and recode the unit tests, including some that are done already.

Now that I realize that I was doing this, I understand somewhat what was happening. I stopped liking the thuds project fairly quickly, because of this and the display problem (see next journal post). I'll change my ways. I will be re-starting the thud project soon, and will begin updating this log of my explorations into XP.