unittests.html

极限编程 Extream Programing

The fragility of the unit tests is a smell.
<p>
Your co-workers are probably right:  What we are doing now
is not working.  You are probably right:  What XP says we are doing
now ought to be working.
<p>
Here are some possible points on the path where what we are
doing now and what XP says we are doing might part ways.  If one
of these seems right, reply to us and the group can help you in
more detail.
<p>
<strong>Is the testing framework awkward?</strong>
<p>
It should feel easier to add a new test than to add the
code that passes it, most (though not all) of the time.
<p>
<strong>Are we writing mini-functionals?</strong>
<p>
A common newbie mis-step is to write unit tests whose focus
is on an object's behavior in complex interactions with other
objects.  In effect, the unit test becomes a mini-functional test.
<p>
<strong>Is the object testable without mini-functionals?</strong>
<p>
Some objects don't seem testable in isolation.  This is a smell.
Bang at the object until you *can* test it in isolation.  Or
abandon the design that created that object.  Investigate
mock object and/or other strategies that help to put one
object at a time under the microscope.
<p>
<strong>Is the testing going top down?</strong>
<p>
Top-down testing is usually more difficult than bottom-up
testing.  We will let some mini-functional'ish unit tests in when
we test from the top.  This is not always wrong.  But we can
move with more confidence and speed if we know that the
collaborators are themselves thoroughly tested.
<p>
<strong>Are the tests looking too deep into the guts?</strong>
<p>
If our tests poke too deep into mechanisms, then every time we
change the mechanism we have to change all the tests.  The less
you expose to the world, the fewer the unit tests you will write.
<p>
<strong>Are we testing too much?</strong>
<p>
I get my ass in a sling all the time with this one, but I'll say
it again:  The purpose of unit testing is to increase developer
mobility.  It is decidedly *not* to verify the correctness of
your program.  Are you testing privates?  Are you testing
simple accessors?  Are you trying to make unit tests perform
100% code coverage?  These are all practices that may have
some value, but also may serve to defeat the real purpose of
unit tests.
<p>
<strong>Are we testing the object from hell?</strong>
<p>
Objects should be tiny and stupid.  That way we can write
tests that are tiny and stupid.
<p>
<strong>Conclusion</strong>
<p>
When I was a boy, Kent's grandma used to offer all kinds of
extremely pithy advice.  She had one that works here:
<p>
When you find yourself in a hole, the very first thing
to do is to STOP DIGGING.
<p>
I think you're in a hole.  I think that pressuring your colleagues
to continue is digging.  I think we need to debug the process
a little more before we twist arms.  The reason I think this?
<p>
When we're doing it right, unit testing works so amazingly
well that anyone who codes for a living will become instantly
and permanently addicted to it.
<p>
Good luck, and get back to us if you figure out more details...
Hill
<p>
--<a href="http://c2.com/cgi/wiki?MichaelHill">MichaelHill</a> 
<p>
<hr>
<em>To change the design they have to modify some or all of the tests. Typically they just comment out the tests.</em>
<p>
Omigawd.
<p>
Have them refactor the tests.  The refactored tests will tell them if the refactored design no longer works in a way that removed tests won't.  --<a href="http://c2.com/cgi/wiki?MattRickard">MattRickard</a>
<hr>
From: <a href="http://c2.com/cgi/wiki?JavaUnit">JavaUnit</a>
<p>
The way I accomplished unit testing of a class is to have a main method in the 
class itself.  In the main, instantiate that class, call its public 
method and see if expected results are returned.  Presumably calling the
public methods tests all the services that the class can and will deliver.  
Also, call the methods with different set of input and see if it crashes.  This
allow test for robustness.
<p>
The above approach would work if the class is stand-alone (above refered as self-contained).  When in a c/s architecture, I often write a client site application (such as an applet or command prompted application)to test every valid network call to the server (i.e. the services that the server object provision).
<p>
../Wendy Liew, April 16, 1999
<hr>
Wendy, when you say &quot;see if the expected results are returned&quot;, do you mean
that you examine them yourself and say yea or nay; or does the program check
them and tell you yes it worked or no it didn't?
The first way is <a href="http://c2.com/cgi/wiki?GuruChecksOutput">GuruChecksOutput</a>, the second way is <a href="http://c2.com/cgi/wiki?CheckOutputAutomatically">CheckOutputAutomatically</a>.
In the last month I have been writing <a href="UnitTests.html">UnitTests</a> for parts of my code,
and I have to say that <a href="http://c2.com/cgi/wiki?CheckOutputAutomatically">CheckOutputAutomatically</a> is so much more effective
that it should be compulsory.
<p>
The advantages are:
<UL>
<li> automatic checks fail no matter what mood you are in - tired, drunk, indifferent
<li> if you get sick, your kids can run the unit tests for you
<li> automatic checks can run while you are surfing the web
<p>
</UL>
The disadvantages are:
<UL>
<li> automatic tests are a bit harder to write, in fact as hard as the code was in the first place (but that makes the job more interesting)
<li> your boss and QA people can run <a href="UnitTests.html">UnitTests</a> too
<p>
</UL>
I am a pretty good programmer, and pretty arrogant about how few bugs there
are in my code.
When my unit tests started failing, I was pretty appalled at how talentless I was.
Now that I have got the unit tests in, I can afford to be arrogant again :-).
But I no longer claim that there are no bugs in my code when I haven't got a
unit test for it.
--<a href="http://c2.com/cgi/wiki?JohnFarrell">JohnFarrell</a>
<p>
Its a wonderful humbling experience, <a href="UnitTests.html">UnitTests</a>. I don't write code any other way anymore. My code has less problems, I have more confidence and management has more confidence. 
<p>
--<a href="http://c2.com/cgi/wiki?SamGentile">SamGentile</a>
<hr>
<a href="http://c2.com/cgi/wiki?CategoryTesting">CategoryTesting</a>
<hr>
<a href="http://c2.com/cgi/wiki?TopicGlossaryComputerScience">TopicGlossaryComputerScience</a> | <a href="http://c2.com/cgi/wiki?TopicGlossaryXp">TopicGlossaryXp</a>
<hr>
<a href="http://c2.com/cgi/wiki?edit=UnitTests">EditText</a> of this page (last edited March 22, 2001)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=UnitTests">FindPage</a> by browsing or searching<p>
<font color=gray size=-1>This page mirrored in <a href="index.html">ExtremeProgrammingRoadmap</a> as of March 31, 2001</font>
</body>