unittests.html

极限编程 Extream Programing

</PRE>
<hr>
1) My experience is that very long running tests and those that require manual verification (<a href="http://c2.com/cgi/wiki?GuruChecksOutput">GuruChecksOutput</a>) are run less often than the other tests.
The <a href="ExtremeProgramming.html">ExtremeProgramming</a> advocates say that their tests run so fast that they can always run all of them at a whim.
Others, like <a href="http://c2.com/cgi/wiki?MicrosoftCorporation">MicrosoftCorporation</a>, split the tests into groups, running slow and expensive batches at night or over weekends.
<p>
2) Yes, it makes sense to refactor <a href="http://c2.com/cgi/wiki?JavaUnit">JavaUnit</a> (for example) code from time to time to make it better meet your needs.
But you should avoid redesigning the testing library and your production code at the same time:
Ordinary humans, like us, can really only do one thing at a time.  ;-&gt;
-- <a href="http://c2.com/cgi/wiki?JeffGrigg">JeffGrigg</a>
<p>
Are there <a href="http://c2.com/cgi/wiki?UnUnitTestableUnits">UnUnitTestableUnits</a>?
<p>
See <a href="http://c2.com/cgi/wiki?UnitTestingMarsOrbiters">UnitTestingMarsOrbiters</a>.
<p>
<hr>
<p>
Question: What's the best way of unit testing Oracle Stored Procedures and related database table constraints?
<p>
I have done some crude unit tests in the Oracle world, but they were a bit draconian:
<OL>
<li> Basic method was to run the test, redirect to a file, and compare it with expected.  Inside the test, I call a procedure, then SELECT * FROM table; for all tables that mattered, ensuring the procedure had the right side-effects.  The test has several procedure-call and SELECT cycles in it.
<li> Because the output includes the system date, I had to use a sed script to change the date to a fixed word, prior to diff.
<li> The first step in the test is to DELETE all the data from the tables that mattered.  That is quite draconian, when other developers share the database.  I also had to DROP and re-CREATE the SEQUENCEs to make them restart at 1
<p>
</OL>
Deleting everybody's data is draconian, in a shared environment.  It comes from: <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>.
<p>
From my own thinking (<a href="http://c2.com/cgi/wiki?ExtremeProgrammingChallengeThirteenPointFive">ExtremeProgrammingChallengeThirteenPointFive</a> doesn't add much), The way I see it, I have a few unappealing options:
<OL>
<li> Ask for my own environment
<li> Continue and hope that there aren't too many active developers trying to do stuff when I want to unit test
<li> Invest time and energy to see how I can normalise the output without restarting the sequences
<li> Invest time and energy to see how I can suppress the output of other people's data in the database
<li> Invest time and energy to see how I can restore the database to what it was before the test (there are complications with ROLLBACK).
<p>
</OL>
At least the unit test is fully automatic.
<p>
Any ideas on this one?
<p>
<PRE>
  -- <a href="http://c2.com/cgi/wiki?NickBishop">NickBishop</a>
<p>
</PRE>
Does everyone have his or her own Oracle account? That's how we did it in our <a href="http://c2.com/cgi/wiki?XpLeiden">XpLeiden</a> project. There's a file schema.sql in our cvs repository and the unit tests automatically delete whatever is in your schema and then recreate it with schema.sql. Individual tests insert a few records, perform a query, compare the results with the expected output and then remove all records again.
--<a href="http://c2.com/cgi/wiki?MartijnMeijering">MartijnMeijering</a>
<p>
What about <a href="http://c2.com/cgi/wiki?UnitTestsForLegacyCode">UnitTestsForLegacyCode</a>?
Question: If you code unit tests up front, how can you code them if you do not know the interface of the thing you're testing yet?
-- Serge Beaumont &lt;<a href="mailto:[e-mail]">mailto:[e-mail]</a>&gt;
<p>
You make it up as you go along, which is what you would be doing anyway. At least, it's what I would be doing anyway. --<a href="http://c2.com/cgi/wiki?AlastairBridgewater">AlastairBridgewater</a>
<p>
Question: How much overhead is there in moving unit tests when you refactor between classes?  Is it a drag or does it not happen much? -- <a href="http://c2.com/cgi/wiki?TomAyerst">TomAyerst</a>
<p>
It happens occasionally, but it only adds 20% to the effort of refactoring when it does. --<a href="KentBeck.html">KentBeck</a>
<p>
Recall that one must refactor the <a href="UnitTests.html">UnitTests</a> to prove the functionality moved from one class to another, and only then move the functionality. Such a Unit Test, like any XP Unit Test, pulls one in the correct direction. It is not make-work added after a fix effort.  --<a href="http://c2.com/cgi/wiki?PhlIp">PhlIp</a>
<p>
<hr>
It doesn't address every issue with testing GUIs (by any means!) but I created
a small example that gives the feel of testing and coding a Java GUI,
at <a href="http://users.vnet.net/wwake/xp/xp0001/index.shtml">http://users.vnet.net/wwake/xp/xp0001/index.shtml</a>  --<a href="http://c2.com/cgi/wiki?BillWake">BillWake</a>
<p>
Bill, this is fabulous! Please publish it somewhere soon. --<a href="KentBeck.html">KentBeck</a>
<p>
This is fabulous!! This will really help out our Java people with the problem of Java GUI testing.
<p>
--<a href="http://c2.com/cgi/wiki?SamGentile">SamGentile</a>
<p>
On www.xprogramming.com you'll be finding version 2.1 of <a href="http://c2.com/cgi/wiki?DelphiUnit">DelphiUnit</a>. It also has a GUI driver, complete with a little scripting language.
<p>
--<a href="http://c2.com/cgi/wiki?SergeBeaumont">SergeBeaumont</a>
<hr>
What about things that can't be tested without human interaction?  For example, suppose you have some code that handles printing.  (And suppose the code is sufficiently deep in the system that it's not directly tested by a customer-written functional test.  And suppose that it is necessary to test it at each integration, because breaking it can have subtle effects that will not easily be identified with this code without unit tests.)  For most projects, the only practical way to test this printing code is to have a human inspect the paper that comes out of the printer and verify that it appears as it should.  How does the XP testing process deal with this?
<p>
<p>
If you <a href="http://c2.com/cgi/wiki?CodeUnitTestFirst">CodeUnitTestFirst</a> your design will be far different than what you might expect.  Most likely you will isolate the code which actually prints something to a physical printer from the code which formats something to be printed.  Once the physical printer driver is tested it is unlikely to be changed anytime soon.  That puts it into the not-likely-to-break category and is then exempt from unit tests.  If it ever does change it is tested again by inspection of the physical output.  The code that formats output destined for printing can be unit tested as usual. 
<p>
Also remember that <a href="FunctionalTests.html">FunctionalTests</a> (XP style) cover anything that is of value to the customer.  If it is not valuable enough to figure out how to test it then it should be removed immediately if not sooner.  <em>Where there is a will there is a way to test.</em> --<a href="DonWells.html">DonWells</a>
<p>
<hr>
<p>
I just came across this paper, which oozes XP-ness: <a href="http://c2.com/cgi/wiki?GuerillaHci">GuerillaHci</a> 
on usability testing. It's by <a href="http://c2.com/cgi/wiki?JakobNielsen">JakobNielsen</a>, author of <a href="http://c2.com/cgi/wiki?UsabilityEngineering">UsabilityEngineering</a>, 
and though he doesnt mention the word <a href="http://c2.com/cgi/wiki?UnitTest">UnitTest</a> (he talks of 'scenarios') 
it is a kind of unit testing for usability (of course, its not automated; 
but his tests are not meant to be full functional tests). Interesting 
reading. -- <a href="http://c2.com/cgi/wiki?BrianEwins">BrianEwins</a> 
<p>
Has anyone tried a local Wiki to store unit tests in? -- <a href="http://c2.com/cgi/wiki?ThaddeusOlczyk">ThaddeusOlczyk</a>
<p>
<hr>
<p>
Has anyone got a <a href="http://c2.com/cgi/wiki?TestingFramework">TestingFramework</a> or experience in testing the correctnes of DataConversion<a href="http://c2.com/cgi/wiki?edit=DataConversion">?</a> programs (lots of SQL)? -- <a href="http://c2.com/cgi/wiki?TomCrossland">TomCrossland</a>
<p>
<hr>
<p>
I am currently trying to integrate <a href="UnitTests.html">UnitTests</a> into my favorite training application, a chess program.  I find it very difficult to tease the &quot;Units&quot; apart well enough to test them seperatly.  Especially when trying to test chess pieces for legal moves, I find myself needing to use the board configuration as part of the scaffold.  Does anyone have any good advice, links or experience on how to tease units apart for testing?  
<p>
Also, in an application with as many legal situation as chess, I find myself wanting to test a lot of &quot;useless cases&quot;.  I.e. for each piece in a given position, I give in the moves that should be legal for each piece, and then I try moving the piece to every square on the board, comparing the moves to the input.  Is this overkill?  Is it impractial?  How can I do effective testing when there are as many legal board configurations as there is in chess? -- <a href="http://c2.com/cgi/wiki?JohannesBrodwall">JohannesBrodwall</a>
<p>
Try using a mechanism like the <a href="http://c2.com/cgi/wiki?CyclomaticComplexityMetric">CyclomaticComplexityMetric</a> to determine the sufficient level of testing for a method.
<p>
<em>Ahhhhh!!! -- <a href="http://c2.com/cgi/wiki?RobertDiFalco">RobertDiFalco</a> (running like hell from CCM's)</em>
<p>
CCM-style test theory uses a crippling assumption, which XP blows away. This theory assumes the testor is not empowered to change the tested code. XP theory states that if metrics reveal your code is too complex to test, you SIMPLIFY THE CODE FIRST. --PCP
<p>
I am not sure why you state that CCM makes any assumption about the role of tester vs. developer.  I find that it meshes quite nicely with the concept of refactoring code and provides some theory about why refactoring improves code.  CCM provides a fairly objective measure of whether code complexity is reduced and is a good way to show the benefit of refactoring to doubters.  --<a href="http://c2.com/cgi/wiki?WayneMack">WayneMack</a>
<p>
<hr>
<p>
I find it hard to write <a href="UnitTests.html">UnitTests</a> where the unit being tested is heavily network-related, especially where it relies on components across the network to function properly. Does anyone have experience with <a href="http://c2.com/cgi/wiki?UnitTestingNetworkFunctionality">UnitTestingNetworkFunctionality</a> ? --<a href="http://c2.com/cgi/wiki?GabrielWachob">GabrielWachob</a>
<p>
I would suggest looking at <a href="http://c2.com/cgi/wiki?MockObject">MockObject</a> to help here. Your code should be designed to seperate the model from network interaction (perhaps through appropriate APIs). The model can be tested properly with a set of <a href="http://c2.com/cgi/wiki?MockObjects">MockObjects</a> implementing your networking API. Testing the networking API itself can be done without involving your model too. But then again, your particular problem might just be the exception to the rule. --<a href="http://c2.com/cgi/wiki?ChanningWalton">ChanningWalton</a>
<p>
<hr>
<p>
From XP mailing list:
<p>
<PRE>
   Date: Fri, 13 Oct 2000 00:22:30 -0400
   From: &quot;Michael D. Hill&quot; &lt;[e-mail]&gt;
</PRE>
Subject: Re: Problems with unit testing and design
<p>
Chris...
<p>
At 09:16 PM 10/12/00 -0400, you wrote:
<PRE>
 &gt;I'm trying to introduce some XP practices where I work. People are
 &gt;resisting unit tests for a couple of reasons and I'm looking for help. One
 &gt;of the problems is that the tests are fragile in the face of XP's dynamic
 &gt;and evolving design. Someone goes to the effort of writing a bunch of unit
 &gt;tests, and then they realize that their design was wrong. To change the
 &gt;design they have to modify some or all of the tests. Typically they just
 &gt;comment out the tests. The feeling is that it would be easier to write the
 &gt;tests once the design has solidified a bit more.
</PRE>
There are some other good suggestions here in response, but let
me try a different (and somewhat meta-) track.
<p>