＋设为首页 ＋添加到收藏夹
test-driven development received a lot of attention in 2003, and the interest will grow in 2004. for good reason: everyone agrees testing is important, but now many respected programmers are claiming that by writing tests first, they see better designs emerge. these same programmers quickly point out that test-driven development makes them feel more productive and less stressed. at the end of a shorter programming day theyve built a suite of passing tests and code with better designs. sound too good to be true? well, theres nothing to lose in giving it a whirl. in fact, theres much to be gained.
1. let your computer do the boring stuff 【程序编程相关:Weaving new Acronyms】this article gives you 12 practical ways to start writing tests, and keep writing tests, regardless of your development process. the first two techniques play off of things youre probably already doing, so you dont have to move too far out of your comfort zone. the next two challenge you to wade deeper into the pool to realize the benefits of test-driven development. the remaining techniques round out the regimen to keep you testing effectively all year. youll be well on your way to fulfilling your new years resolutions. caution: contents have been known to be infectious! 【推荐阅读:Introducing JDesktop】
for example, imagine that youre writing a java class that performs the functions of a simple spreadsheet. a spreadsheet cell -- indexed by a column and row combination such as "a1" -- can store a number or a formula that may include numbers and cell references. heres an example main() test driver for the spreadsheet class: 【扩展信息:Validating Custom Ta】
the easiest way to start writing tests is to identify situations where you visually inspect results, then replace that human checking process with automated checking. color me lazy, but i want to put this thing called a computer to work for me. its much more reliable than i am at keeping my expectations in check. some results are difficult to check without a human in the loop; dont start there. instead, go after low-hanging fruit to get a few small victories under your belt. ive found the pervasive main() test driver to be easy pickings for automating. im not referring to the entry point that bootstraps your application, but rather the main() method that acts like a test driver by printing results to the console.
public static void main(string args[]) { spreadsheet sheet = new spreadsheet(); system.out.println("cell reference:"); sheet.put("a1", "5"); sheet.put("a2", "=a1"); system.out.println("a2 = " + sheet.get("a2")); system.out.println("\ncell change propagates:"); sheet.put("a1", "10"); system.out.println("a2 = " + sheet.get("a2")); system.out.println("\nformula calculation:"); sheet.put("a1", "5"); sheet.put("a2", "2"); sheet.put("b1", "=a1*(a1-a2)+a2/3"); system.out.println("b1 = " + sheet.get("b1")); }you may recognize this testing style or may have even written similar test drivers yourself, if only to give you some confidence that the code produced the results you expected. the main() method was my testing harness of choice for many years, and i still get the urge to use it from time to time because its easy. but just as im about to take the bait, i remember how a main() test driver sucks the life out of me. see, every time i change code that affects the spreadsheet class, i want to run the test to see if my change broke anything. im confident in my changes if i run the test afterward and see the following console output:
cell reference: a2 = 5 cell change propagates: a2 = 10 formula calculation: b1 = 15this testing approach has at least one problem: it requires that i visually inspect the output every time i run the test. worse yet, as the number of results output by the test driver increases, my workload also increases. ill quickly grow weary of doing work best suited for a computer and stop running the test altogether. inspecting the output also implies that between test runs i have to remember how the expected output should look. is the correct result of the formula calculation 10 or 15? hmm, i cant remember. and if i cant remember, theres little hope of sharing the test with other folks.
junit is a computers taskmaster when it comes to checking expectations. if youve never used junit, the junit faq will get you up and running in less time than it takes to type a main() method signature. using junit, a main() test driver requiring human checking can be easily replaced by automated tests that check their own results. heres the equivalent spreadsheet test, expressed in a junit test:
... 下一页