Re:How the Pomodoro Technique changed my workday
by CydeWeys on Tuesday November 17, 2015 @09:47PM
(#10585593)
Cloud development and testing help a lot too. I can kick off a run of the entire test suite in the cloud, and get right back to coding, all while keeping tabs on the tests' output in a tmux terminal.
I'm typically editing in parallel with tests running. This can frequently result in no down time whatsoever owing to tests, even during a large refactor. Let's say I make a big refactor and 90 different test classes break (this is not theoretical). I modify some code that might make one of those test classes past, kick of a test run, and immediately go edit another failing test class. By the time I think I've got that figured out, the test run on the first has completed, and I can either move on, or try something else to fix it if it's failed again. This requires keeping the state of multiple test classes in your head simultaneously, but fortunately I'm good at that.
I have the same experience as you do, and these numbers of 2 seconds and 6 seconds really seem about right. If the test runs in less than 2 seconds, I can stay focussed on what I'm doing. By 6 seconds, I'm already thinking about something else. My personal experience has been that if the tests takes longer than 2 seconds, it is virtually impossible to do TDD. Instead you have to write large chunks of code -- or at the very least write several tests in one go.
I'm fairly well known in my current group for the 2 second rule :-) 2 seconds is really a long time for a modern computer, so my feeling is that if you can't build and run a large section of tests in 2 seconds, you've got a serious problem somewhere. When pairing with people who don't mind longer test runs, I've noticed that they never actually TDD. Instead they right large pieces of code (entire functions at the very least), or they write 5-10 tests all in one go. When I show people the normal rhythm of TDD, they suddenly understand why you need to have incredibly fast tests.
I also preach a 2 minute limit for the entire test suite. Kent Beck has talked about that previously (although I can't remember what number he used -- something like 2-4 minutes). He has even advocated simply throwing away long tests. Test coverage is less important than being able to run your tests quickly. I have found that if the test suite creeps up to about 10 minutes, the frequency of running that test suite is reduced to about once per day -- meaning that you have totally lost the context of the problem when you discover it.
Whatever you need to do to keep those tests running quickly is what you should do. Whether that means only running a subset, hot loading modules, stubbing out slow moving pieces (even the database), etc. I could write for quite a long time on testing strategy... This needs to go on my queue for a blog post ;-)