'&$%CSE 303:Concepts and Tools for Software DevelopmentDan GrossmanWinter 2006Lecture 17— Unit testing, stubs, specification, etc.Dan Grossman CSE303 Winter 2006, Lecture 17 1'&$%Where are We• In the middle of software development tools– “Done”: preprocessors, compilers, debuggers, profilers,– “To do”: compilation-managers, version-control systems,linkers, archive-generators• Today: “software engineering” topics related to homework 5.Dan Grossman CSE303 Winter 2006, Lecture 17 2'&$%Testing 1, 2, 3• Role of testing and its plusses/minuses• Unit testing or “te sting in the s mall”• Stubs, or “cutting off the rest of the world” (which might notexist ye t)Dan Grossman CSE303 Winter 2006, Lecture 17 3'&$%A little theory• Motto (Hunt and Thomas): “Test your software or your users will”• Testing is very limited and difficult:– Small number of inputs– Small number of calling contexts, environments, compilers, ...– Small amount of observable output– Requires more things to get right, e.g., test code• Standard coverage metrics (statement, branch, path) are usefulbut only emphasize how limited it is .Dan Grossman CSE303 Winter 2006, Lecture 17 4'&$%Colored boxes“black-box” vs. “white-box”• black-box: test a unit without looking at its implementation– Pros: don’t make same m istakes, think in terms of interface,indepdent validation– Basic example: remember to try negative numbers• white-box: test a unit with looking at its implementation– Pros: can be more efficient, can find the implementation’scorner cases– Basic example: try loop boundaries, “special constants”Dan Grossman CSE303 Winter 2006, Lecture 17 5'&$%Stubs• Unit testing (a small group of functions) vs. integration testing(combining units) vs. system testing (the “whole thing” whateverthat means)• How to test units (“code under test”) when the other code:– may not exist– may be buggy– may be large and slow• Answer: You provide a “fake implementation” of the other codethat “works well enough for the tests”.– Fake implementation is as small as possible, so the functionsare often called “stubs”.Dan Grossman CSE303 Winter 2006, Lecture 17 6'&$%Stubbing techniquesHonestly something I’ve never been taught, but here are some tricks Iuse:• Instead of computing a function, use a small table of pre-encodedanswers• Return wrong answers that won’t mess up what you’re testing• Don’t do things (e.g., print) that won’t be missed• Use a slower algorithm• Use an implementation of fixed size (an array instead of a list?)• ... other ideas?Lecture-size example can be tough, but we can show the ideas withthe prime-number code from last lecture.Dan Grossman CSE303 Winter 2006, Lecture 17 7'&$%Eating your vegetables• Make tests :– early– easy to run– that test interesting and well- understood properties– that are as well-written and documented as other code• Write the tests first?• Write much more code than the “assignment requires you turn-in”• Manually or automatically compute test-inputs and right-answers?Dan Grossman CSE303 Winter 2006, Lecture 17 8'&$%Testing – of whatSummary: Testing has some concepts worth knowing and using• Coverage• White-box vs. black-box• StubbingBut we made a big assumption, that we know what the c ode issupposed to do!Oftentimes, a complete specification is as difficult as writing the code.But:• It’s still worth thinking about.• Partial specifications are better than none.• Checking specificatins (at compile-time and/or run-time) is greatfor finding bugs early and “assigning blame”.Dan Grossman CSE303 Winter 2006, Lecture 17 9'&$%Full SpecificationOften tractable for very simple stuff: “Take an int x and return 0 iffthere exists ints y and z such that y ∗ z == x (where x, y, z > 0and y, z < x).What about sorting a doubly-linked list?• Precondition: Can input be NULL? Can any prev and next fieldsbe NULL? Must it be a cycle or is “balloon” okay?• Postcondition: Sorted (how to specify?) – and a permutation ofthe input (no missing or new e leme nts).And there’s often more than “pre” and “post” – time/space overhead,other effects (such as printing), things that may happen in parallel.Specs should guide programming and testing!Dan Grossman CSE303 Winter 2006, Lecture 17 10'&$%Partial SpecificationsThe difficulty of full specs need not mean abandon all hope.Useful partial specs:• Can args be NULL?• Can args alias?• Are stack pointers allowed? Dangling pointers?• Are cycles in data structures allowed?• What is the minimum/maximum length of an array?• ...Guides callers, callees, and testers.Dan Grossman CSE303 Winter 2006, Lecture 17 11'&$%Beyond testingSpecs are useful for more than “things to think about while coding”and testing and comments.Sometimes you can check them dynamically, e.g., with asse rtions (allexamples true for C and Java)• Easy: argument not NULL• Harder but doable: list not cyclic• Impossible: Does the caller have other pointers to this object?Or statically using stronger type systems or other tools:• Plusses: earlier dete ction (“cove rage” without running program),faster code• Minus: Potential “false positives” (spec couldn’t ever actually beviolated)Dan Grossman CSE303 Winter 2006, Lecture 17
View Full Document
Unlocking...