To start a test-driven development process, it’s important to have some requirements in mind. Without some sense of what your code should be doing, it’s hard to write tests to describe behavior.
Requirements-gathering could be an entire book by itself (specifically, this one: Software Requirements, 2nd Edition [Wie03]). In our case, we’re our own client and we’re working on a small project, so we don’t exactly need military-grade precision. Here’s my informal list of the first few things we’ll tackle:
A user can create a project and seed it with initial tasks using the somewhat contrived syntax of task name:size.
A user can enter a task, associate it with a project, and see it on the project page.
A user can change ...