> The unit test definition you are suggesting has a rather > questionable foundation. The definition cherry picks some > common input/output services but in effect you are saying > "speed" is a defining characteristic of a unit test.
Just because people already know many of the others.
> The execution speed determines whether the unit test is > slow or fast, not whether it is a unit test or not. What > you seem to be leaning on for your definition is test > independence. A test that does database access is not > independent. Everything has dependencies at some level so > that's not a criterion with much practical value either. > > A unit test should not depend on other unit tests. You > define what a "unit" is and you may very well have several > levels of granularity. Functional tests are tests from the > user's perspective, be that a human being or another > system: > > http://www-128.ibm.com/developerworks/library/j-test.html > > > Side note: the comment was made that the XP solution to > slow tests was to optimize the tests. Think about that. Is > it the test or the UUT (unit under test) that is slow? > Refactoring is not a unit test speed-up process.
Yes, refactoring is not optimization. The fact is this "slow test" problem is a big deal with many teams. And I can't remember a case where the speed of the code under test was an issue and the code didn't do something with an external system (network, file system, database). I know it can happen, but I haven't run into a team with the problem of compute-intensive unit tests. External system access, leading to glacially slow unit tests, seems to be a much more popular way to fail.
Flat View: This topic has 50 replies
on 51 pages
[
«
|
424344454647484950
|
»
]
Previous Topic
