I beleive concurrency unit testing deserves a special mention here. I have written concurrency unit tests (CUTs) that are "pure" according to your rules, but still require a non-trivial running time.
The unfortunate nature of CUTs is that they are non-deterministic, i.e., one iteration does not prove that the code is correct, as it does for a regular unit test. Uncovering concurrency bugs requires hitting the code with multiple threads for a sufficient length of time. (Even then, correctness can only be stated in terms of probability, e.g., I have hit this code with 100 threads for an hour, so it is highly probable that there are no concurrency bugs.)
Some might argue that CUTs are load tests, but I beleive that the purpose of a unit test is to verify the correctness of a unit of code, and a unit of concurrent code cannot be verified without CUTs.
Perhaps a fast/slow categorization of tests is more useful than a pure/impure one for the purposes of deciding run frequency. Although pure tests are typically fast and impure can often be slow, the inverse is not uncommon.
Flat View: This topic has 50 replies
on 51 pages
[
«
|
464748495051
|
»
]
Previous Topic
