This section will take you about 30 minutes to over an hour, depending on how much of the video you choose to watch.

Before you begin in earnest with the course, I have a little introductory material for you.

Many programmers believe that they "get" TDD. When I work with them it becomes clear to me that most of them do not. That's OK. That means just one thing: we need to clarify what we mean by "TDD". Of course, I'm the only one talking here, so that means that I get to clarify what I mean by TDD, and you get to decide whether you can live with it. :)

First, read "A (Re)Introduction to TDD". After that, you can watch one of the videos to demonstrate how I set up an environment to do TDD. I do not consider myself the foremost authority on setting up environments, so I don't pretend that my way is "the way". If you have a suggestion, then don't be shy: share what you know with your fellow participants. If I see something compelling, then I might re-shoot one of the videos. Also, as I become more comfortable in more languages, I can add more videos.

Once you have completed this section, you can proceed to the Fundamentals of High-Discipline TDD.

Example: Setting Up a Java Environment for TDD

This next video shows one very simple way to set up a Java project with JUnit 4. This shows a quick and easy way to achieve the primary goal to run all the tests in the project with a single command inside the IDE, because this gives the programmer very quick and very easy feedback from running tests.

The simple set up involves creating a project, adding dependencies to the testing libraries, then executing the "run all tests" command to run all the tests in the project. Here, I have a single project with both production code and tests in different source trees. This suffices for simple projects, but even in the most complicated build structure, the primary goal remains the same: to run all the tests in the project with a single command inside the IDE.

However you set up your project, it is valuable to configure the build so that only test code depends on the testing libraries. IntelliJ IDEA calls this "test scope", which means that a dependent library is placed on the classpath only to compile and run the test code, not the production code. In some IDEs you might need to have two modules, one for production code and one for test code, where only the "test" module depends on the testing libraries. In the very old days of Eclipse (before 2002, if I recall correctly), we had a "tests" project that depended on the testing libraries and on the "production code" project, which only depended on production libraries. However you set up your project, it is important that test code depends on production code, but production code does not depend on test code. It should be possible to destroy all your testing assets and still build your production code.

A typical industrial-strength project would use a build tool like Gradle or Maven to describe the project, then the IDE would import the build files and configure the IDE to match them. If I don't know the IDE very well or it doesn't work the way I expect, I usually get a build running using Gradle, then once the command "gradle clean test" runs all my tests, I import the build into my IDE, then I can use the "run all tests" command inside the IDE. As of 2019, this is how I work with Gradle 4.10+, IDE 2019.x, and JUnit 5. If you aren't sure how to set up your project to use JUnit 5, then as of late 2019, you'll find sample projects at junit.org which you can use as a starting point.

Example: Setting Up a Ruby Environment for TDD

This next video shows a straightforward Ruby environment to run tests with RSpec. No IDE, merely because I don't use one. (I tried using a handful of Ruby IDEs years ago and didn't like any of them. If you have any suggestions, I'll try one.) As with the Java example, I don't intend to show you state-of-the-art build tools, but rather to set up a project to be able to run all the tests with a single command, albeit from the command line instead of from within an IDE.

Keep in mind that Ruby moves fast, and something here might have gone out of date. Don't be afraid: tell me in the comments. We might need to update this video a bit more often. The most important thing: getting fast feedback. (For example, have you see Kent Beck's video setting up a CoffeeScript TDD environment, complete with writing the testing library itself? Take 20 minutes and watch it here.)