Like most people I have a few projects on the go at once. To efficiently switch between them I must be able to quickly pick up where I left off. In my programming projects I’ve been using failing tests as reminders to myself. This fits in nicely with my programming workflow, and enables me to make progress before I’ve recalled all the details of the project I’m working on. Here’s how it works:
In my programming workflow I cycle between writing tests, writing code, and running tests (this is just test driven development). When I’m about to stop working on a project I write some failing tests, which act as a specification for what I should do next. At this point in time I’ve been working on the project for a while so I have recalled its structure and I’m in a good position to make this decision.
When I pick up a project after a break I enter straight into my normal workflow and run my tests. I inspect the failing tests and start implementing the functionality they specify. At this point in time I don’t even have to remember why I’m implementing this; the tests provide enough detail that I can just start coding. As I do so I invariably recall more details of the project. By the time I’ve finished the feature I’m ready to go at full speed.
This technique allows me to “hide” the time it takes to recall the project details; I still get useful work done in this period. It’s quite a simple idea and no doubt some of you are already using it, but if you haven’t tried it, give it a shot.
Hi,
I use automated tests in a similar todo way.
We use Use Cases to drive our development. When I start out coding a Use Case, I first sit down and figure out what functionality the case covers – and then express this in a set of automated tests, as close to the use case functionality as possible (I guess this is called regression tests?).
Then I start coding the functionality making the first test case run, and basically work my way down the list of test cases, making each run. This way I am always sure of not breaking existing user functionality, and I have a good indication of when I am done. Should I find something that is not yet covered by my test cases, I write a test case for it right away, and continue working on the code.
I have been pretty successful using this method to implement complex use cases. And I have a confident feeling in my stomach once I am done, plus it makes it easier for other programmers to understand the code and make changes to it.
Best regards,
Jacob
I used this style sometimes and it worked very well, even if you’re simply interrupting for the weekend. I’ve heard first about this technique from “Uncle Bob” (http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd).
Jacob: what you do might be called functional tests
depending on the level at which you write tests. I find it
quite difficult to code all my tests at the start of
development. I usually do just a few and code up the rest
as development proceeds.
Luis: interesting article. Thanks.