4 ms·

Superb article (some small nitpicks but they are ignorable). I would like to add just one more anti-pattern: Focusing too much on fast feedback Nope. One shou

Superb article (some small nitpicks but they are ignorable). I would like to add just one more anti-pattern: Focusing too much on fast feedback Nope. One should get priorities straight. The #1 purpose of tests is safety. The "sleep well in the night" test. The "deploy with eyes closed" test. Performance of the test suite, while "nice to have", is not the core objective. If push comes to shove, if it comes down to safety vs performance, safety should just win hands down as a principle. Doing a bunch of mocks for speeding up 80% of unit tests? Great, but its a borrowed debt, and must be balanced out with 20% of higher level tests.

achamayou 8y ago
Can't agree enough. Degrading the quality of the tests to make them quicker is particularly frustrating, especially when it's easy enough to split them out into something that runs at a lower frequency. Just because you can run all the tests and all the optimisations on every keypress doesn't mean you shouldn't have them.
keithnz 8y ago
I find this a bit of a strange statement. I started with Extreme Programming in 99 and grew and evolved through all the refinements to the process around testing. It's always been about providing safety. Fast has always been about not running silly tests that take too long Fast Feedback is a core objective. It is not in competition with safety, safety is an integral part. Safety is the feedback you are expecting. We want to know about that safety fast. A popular term that came around in the early 2000s was "Brain Engaged", meaning you needed always to be aware of why you were doing things and not following blind rules. Meaning you need to know the purpose of going fast. The whole point is to go as fast as possible safely. Some of the biggest challenges is how to get things quick while maintaining safety. Kind of makes no sense to have fast tests with no safety. Now you mention mocks, and I have seen people mock in very strange ways that devalue tests. I like the general guidance from Kent Beck "I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence"

achamayou 8y ago

Can't agree enough. Degrading the quality of the tests to make them quicker is particularly frustrating, especially when it's easy enough to split them out into something that runs at a lower frequency. Just because you can run all the tests and all the optimisations on every keypress doesn't mean you shouldn't have them.

keithnz 8y ago

I find this a bit of a strange statement. I started with Extreme Programming in 99 and grew and evolved through all the refinements to the process around testing. It's always been about providing safety. Fast has always been about not running silly tests that take too long Fast Feedback is a core objective. It is not in competition with safety, safety is an integral part. Safety is the feedback you are expecting. We want to know about that safety fast. A popular term that came around in the early 2000s was "Brain Engaged", meaning you needed always to be aware of why you were doing things and not following blind rules. Meaning you need to know the purpose of going fast. The whole point is to go as fast as possible safely. Some of the biggest challenges is how to get things quick while maintaining safety. Kind of makes no sense to have fast tests with no safety. Now you mention mocks, and I have seen people mock in very strange ways that devalue tests. I like the general guidance from Kent Beck "I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence"