Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^3: Refactoring makes unit tests obsolete

by FoxtrotUniform (Prior)
on Oct 23, 2004 at 05:53 UTC ( #401774=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Refactoring makes unit tests obsolete
in thread Refactoring makes unit tests obsolete

Quite a few people have pushed through the "it's incredibly hard" barrier and lived to tell that it's simpler than they'd feared, even for GUI tests. Look around a bit, and you'll find lots of good ideas for writing simple tests.

I find that the bits that are really difficult to test are the ones that have to "look right". For instance, I have some normal-mapping code with fairly well-defined requirements, but I'm interested in the final image on the screen. It's difficult to test that programatically: even if I take a screenshot and do a pixel-by-pixel comparison, what do I compare it to? An older result from the same program (hello, circular argument). Besides, the only real way to make sure that some of the stuff I do is correct is to move the viewpoint around and check that it looks "right". I could do a video capture and compare uncompressed, frames, but then I'd have to write and debug and test that code.

What I do instead isn't perfect, but it's pretty good: I write interactive test programs. When I do a build, I get about half a dozen simple little rotate-the-model popups; if they look "about right" I consider it a qualified pass. It's not pretty, but it's better than no tests at all.

On the other hand, I've been quite amazed at the number of tests I've been able to automate that I thought would be "test-by-hand" problems. (Actually, I have some ideas about testing that normal-mapping code.) One of the neat things about testing through an external library is that you have to understand that library very well to write good tests -- you have to understand what comes out the other side, and why.

--
Yours in pedantry,
F o x t r o t U n i f o r m

"Lines of code don't matter as long as I'm not writing them." -- merlyn


Comment on Re^3: Refactoring makes unit tests obsolete
Re^4: Refactoring makes unit tests obsolete
by BrowserUk (Pope) on Oct 23, 2004 at 09:00 UTC

    A while ago I was involved in developing an automated test suite for unit testing and functional verification of the OS/2 gui. Both the graphics primitives to be tested and the tests to verify it were generated programmically.

    Eg. A pseudo-random sequence of primitives would be generated to draw a random number of lines, boxes, circles etc. The size, position, color, fill characteristics, patterns etc would all be randomly chosen. Every time the testcase generator generated a random graphic, it also generated 1 or more tests to verify it into a separate file. If it generated a line from (10,10) to (20,20) in red, it would generate a tests to verify:

    The pixels at (9,9),(10,9),(11,9),(9,10),(11,10),(9,11),(10,11) were all background colored and (10,10) & (11,11) where red. Same thing at the other end and one or two bracketing triples down the length of that line.

    It's more complicated than that with thickness, dotted and dashed lines etc, but the principle remains same.

    If transforms where randomly applied to teh drawing primitives, they were also applied to the check codes.

    To verify these, the test-harness that ran the generated code would do a screen grab (Alt-printscreen so that on the application main frame was grabbed) after the picture was drawn. It would then run the checkcodes against the grabbed bitmap.

    All the testcodes were essentially the same; Position(x,y)=>expected(rgb). In this way, when later primitives overlayed earlier ones, the earlier tests where also overwritten. (It got complicated when trying to account for primitives that combined (src xor dest; not(src)and(dst) etc.) but the principle remained).

    Generate a random primitive and a few random tests to verify it.

    By using the Alt-printscreen function, we removed dependance upon the position and size of the application window, which was also randomly chosen at each run. And each run also applied a randomly chosen set of transforms (scale, rotate, shear etc) to apply to the generated picture. The same tranforms were applied to the checkcode before running.

    It worked very well. Each new testcase generated usually took a developers attention to correct anomolies, but once generated and tested, it then became a part of the regression test suite also.

    Prior to the RTG, we had half a dozen guys writing testcases for several weeks but when they were analysed, they all covered 15% or so of the same ground (in terms of the primatives exercised), over and over, another 10% or so partially and the rest not at all. A few weeks of generating testcases, the coverage was much, much more evenly spread across the range of primatives and many more combinations of parameters had been exercised.

    Besides, writing the generator was an aweful lot more fun than writing the boring tests themselves:)

    I just wish I had been using Perl to write it instead of C & REXX.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://401774]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (9)
As of 2014-12-25 21:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (163 votes), past polls