4 ms·

Usually the problem you'll get if you use a lot of functional/integration testing is that your test suite will run too slowly for you to run it often enough to

by lyudmil 15y ago

Usually the problem you'll get if you use a lot of functional/integration testing is that your test suite will run too slowly for you to run it often enough to validate your design. It ends up being something you run when you think you've completed a feature to make sure it works, but not after you've extracted a class to make your code cleaner. I have also had times when I moved away from unit testing in favor of higher-level tests, but ultimately found that the quality of the code got worse and the build time became unacceptable. I'm not trying to generalize here, I'm only talking about my code on a particular project at a particular point in time.

jerf 15y ago
"Usually the problem you'll get if you use a lot of functional/integration testing is that your test suite will run too slowly..." I've had good luck attacking this problem directly. If your integration tests are sufficiently integration-y, often this slowness directly reflects the fact that your system is slow to the users as well! Or, failing that, that you've got too many dependencies hardwired into your system, or some other real problem. Following up on my other proximal post here, the question is ultimate not whether it's high or low level, it's whether it's fast or slow, period. I've written slow low-level tests because they fully tested a 10x10x10x10x10x10 state space accidentally, I've written (after some work on the underlying system) some very fast tests that literally simulate user input to the system via the web server at the highest possible level. The real key is that you can't really follow a testing recipe, you always have to be looking out for the cost-benefits. I suspect the other key is that you must come to internalize the idea that automated testing is really important and if that means spending a man-week to improve your testing environment is what you need to do, then do it. It's really OK.

by lyudmil 15y ago

jerf 15y ago

"Usually the problem you'll get if you use a lot of functional/integration testing is that your test suite will run too slowly..." I've had good luck attacking this problem directly. If your integration tests are sufficiently integration-y, often this slowness directly reflects the fact that your system is slow to the users as well! Or, failing that, that you've got too many dependencies hardwired into your system, or some other real problem. Following up on my other proximal post here, the question is ultimate not whether it's high or low level, it's whether it's fast or slow, period. I've written slow low-level tests because they fully tested a 10x10x10x10x10x10 state space accidentally, I've written (after some work on the underlying system) some very fast tests that literally simulate user input to the system via the web server at the highest possible level. The real key is that you can't really follow a testing recipe, you always have to be looking out for the cost-benefits. I suspect the other key is that you must come to internalize the idea that automated testing is really important and if that means spending a man-week to improve your testing environment is what you need to do, then do it. It's really OK.