At 26:40 "I've been toying with this hypothesis that fast tests lead to good code. It might be a bi-directional relationship. If the tests have to be slow, it might be because there are issues in the code. If the tests are fast, it might be because the code is well factored. (other guy) A lot of times, if your tests are slow it's because you have a lot of coupling between your classes, so they're difficult to test in isolation, so you involve all these other parts, and that makes it slow." (#)
Extremely fast tests allow you to do testing-concept-mutation-testing much more easily, because you can run iterations on the code quickly.
Some thoughts: fast-tests-drive-toward-clean-architecture
You need fast tests because:
Good red, green, refactor forces you to "stay on the baby steps path". This can't be overstated. When I first bumped into Martin Fowler's "refactoring" I couldn't believe how little he did at each step. (This also plays into fast testing, since you need to be able to run them all the time) (#)
"I want my feedback to be so fast that I can't think before it shows up. If I can think, then I'll sometimes lose attention, and I don't want to lose attention."
"I would specifically put something into its own class so I could load just that class and nothing else. The feedback loop you get when you have sub-second test suites for the thing that you're working on is unbelievable. It's a huge enabler for flow." (#)
Depending on how you look at it, fast tests, or testing-concept-no-tests can help make code that is easy-to-delete. On the flipside, slow tests can make code incredibly hard to delete.
... in order to really realize the benefits of good tests, you need to be able to run tests – or, at a minimum, the subset of tests covering your changes – quickly, in order to keep a fast development cycle. (#)
The most important lesson from this example is the rhythm of refactoring: test, small change, test, small change, test, small change. It is that rhythm that allows refactoring to move quickly and safely. (#)
34:30 "Justin: If it's faster to use a REPL to answer the question of 'If I do X will I get Y?', people will use the REPL and then as soon as the REPL session is over, it goes away forever. But if it's equally fast to just codify that in a quick test or check like it is in Smalltalk or, even environments like Java where your IDE you just hit ctrl-r and it will run the tests under the line in a half second. It definitely reduces that cost." (#)
At 9:40 "even though I'm the creator of cucumber, I'm still learning how to use the tool. In the past year or so, I've been experimenting with how to get really, really fast feedback from cucumber scenarios. I'm talking about end-to-end tests" (#)
testing-concept-isolated-tests
talk-fast-test-slow-test-gary-bernhardt
blog-post-testing-without-the-database