Ok, so this really doesn’t qualify as test driven development because a key of that discipline is to automate your tests.

That means you actually would have a set of functions that would automatically test various things as you create them and you leave those tests in place so you can keep running them over and over as you change other things to ensure that what you’ve coded in the past doesn’t fail one of these automated tests.

While automated tests in and of themselves aren’t necessarily useful (for example, if your tests don’t really test anything substantial like how the system really behaves when running) they are extremely useful when they are written with a certain mindset.

That’s where I’m getting at with “Manual test driven development”. I think my thought process as I develop is very much about testing. I think about what behavior I am trying to achieve, I devise a test to make sure it will work, and then run through that behavior manually to see if what I coded actually works. I’m really only a small step away from TDD in my everyday programming, except my tests are not automated or recorded in any way. Once I get the behavior working, I’ll think of another way to use the form or parameters to pass a report and see if I can break it. In this way, my coding is always written to solve specific problems. I just find the problems as I go.

Of course, what I’ve really discovered is that even working this way, writing automated tests is way more difficult than one might think. How do you test a form where a user enters things and presses buttons and ultimately gets a result that is either passing your test or failing your test? It’s easy when I’m manually testing because the system is generally designed for a human to interact with it and use it.

The difficulty is in learning how to separate the human input dependencies and events and simulate them in some meaningful way so that an automated test can actually be testing some abstracted code that can map both to an automated test command AND a human action.

That so far has been the difficulty behind me fully utilizing Test Driven Development.