If I recall correctly, the term "unit test" was borrowed from outside of computer programming, and refered to the testing of a single part or piece, removed from its whole. For example, instead of testing a whole engine at once, a single piston can be removed from the engine and placed in a testing device. This allows the testers to simulate things that would either rarely or never happen to the piston it in its lifetime, or would take years of real world use to determine, say how the piston wore over one year of use.
The key thing is that the part has been isolated. If there is a failure, there is no doubt about what, exactly, failed, or what the part was doing when it failed.
Your five rules can essentially be rolled into one: Isolate and test only one part.
But in software, we have a wrinkle to contend with: What, exactly, is "one part"? Some say it's a single method, however, I've seen methods that were pages long. This brings us to the concept of Test Driven Design; refactor that big method into many small methods that each do only one thing, and they become easier to test.
Flat View: This topic has 50 replies
on 51 pages
[
«
|
272829303132333435
|
»
]
Previous Topic
