How did/would you "force" yourself to do TDD rather than TAD?

1. It helps if you have a generic test framework.

   Have a library of generic functions applicable to various sorts of tests you run. Then re-use those as building blocks to build tests for the project you're on.

   To get there, note the common things you do in the tests you write after. Abstract them away into generalized library one by one.

   Doing so will enable you to do many simpler tests very quickly easily by not having to re-do the boring and time consuming test driver code, instead concentrating on actual test cases.

2. Do "test as documentation" approach. Don't add/change any wording in documentation not backed up by appropriate tests.

   This saves time - you don't have to re-parse documentation/requirements another tijme just to build the tests later - as well as helps with mental shift you asked about.

3. Do gradual phase-in - add tests for new features/changes as they are being started to work in.

   Nobody likes to change their ways cold turkey - human nature. Let the good habit slip in and eventually it becomes second nature.

4. Right away budget the time for writing tests at the beginning of your development schedule on a project

   This will both force you into proper habits (assuming you tend to follow your project plan) and protect you from running over due dates due to "extra" time spent building tests.

   Of course, the "extra" time for TDD ends up net time saver, but it is not always realized at the very beginning stage of the project, which puts negative pressure on the TDD practice ("Where are the prototype screenshots??? What do you mean you're still writing tests???").

5. Also, try to follow the usual recommended practices of small one-purpose classes and functions. This - among all the other benefit - allows much easier unit test writing. Couple that with #2 (by writing unit test as part of the API documentation,

Our TDD drives the development, from the name. Best learned from someone that already is extreme/disciplined about it. If your velocity affected applying TDD immediately on the work project, what is stopping you from growing your TDD muscles outside of work on a side project?

Here's a repost of how I became a BDD / TDD convert:

A year ago, I had little idea how to do TDD (but really wanted to (how frustrating)) and had never heard of BDD... now I do both compulsively. I have been in a .Net development environment, not Java, but I even replaced the "F5 - Run" button with a macro to either run Cucumber (BDD) or MBUnit (TDD) depending if it is a Feature/Scenario or Specification. No debugger if at all possible. $1 in the jar if you use the debugger (JOKING (sort of)).

The process is very awesome. The framework we are additionally using is by The Oracle I've been blessed to come across, and absorbing information from, and that framework he/we use is MavenThought.

Everything starts with BDD. Our BDD is straight up cucumber ontop of iron ruby.

Feature:

Scenario: .... Given I do blah...
When I do something else... Then wonderful things happen...

Scenario: ...

And that's not unit testing itself, but it drives the feature, scenario by scenario, and in turn the unit (test) specifications.. So you start on a scenario, and with each step you need to complete in the scenario it drives your TDD.

And the TDD we have been using is kind of BDD in a way, because we look at the behaviours the SUT (System Under Test) requires and one behaviour is specified per specification (class "test" file).

Example:

Here is the Specification for one behaviour: When the System Under Test is created.

There is one more specification (C# When_blah_happens class file) for another behaviour when a property changes, but that is separated out into a another file.

using MavenThough