Nội dung

checking, and printing are contained in separate routines. Each routine is responsible for one and only one behavior. • The localtime and gmtime calls are now in the correct order. This defect in the original version only became apparent to me when I separated the two output lines. • Argument type validation is consistent, because it has been isolated into a single routine ( plan arg assert) that is used for all three parameters. Several new cases are caught. For example, passing undef to tests or passing both tests and test (deprecated form) is not allowed. • Carp::croak unrecognized directive warning is printed once instead of a warning per unrecognized directive. The check for unrecognized directives still does not fail fast (croak or die). I would have liked to correct this, because passing an invalid directives to plan probably indicates a broken test. However, the broad user base of Test makes this change infeasible. Somebody may be depending on the behavior that this is only a warning. • Two temporary variables (@todo and $x) were eliminated by using a functional programming style. By avoiding temporary variables, we simplify algorithms and eliminate ordering dependencies. See the It’s a SMOP chapter for a longer example of functional programming. • $planned was eliminated after $ TODO was converted to a reference. $planned is known as a denormalization, because it can be computed from another value ($ TODO in this case). Normal form is when data structures and databases store the sources of all information once and only once. • plan print writes a single string. The seven calls print were unnecessary duplication. I often use logical operators instead of imperative statements to avoid the use of temporary variables, which are another form of duplication (denormalization). • The return value from plan is better represented as an empty return, because it handles list and scalar return contexts correctly. This is a subtle point about return, and it actually involves an interface change. The following use assigns an empty list: Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 76 my(@result) = Test::plan(tests => 1); In the old version, @result would contain the list (undef), that is, a list with a single element containing the value undef. • The check for an odd number of arguments is unnecessary, because the assignment to a hash will yield a warning and the argument parsing is more rigorous (no argument may be undef, for example). • print encapsulates the output function that is used throughout Test. The concept that the output is directed to $TESTOUT is only expressed once. • The global variables are named consistently ($ ONFAIL and $ TODO). I name global variables in uppercase. I use a leading underscore to identify variables and routines which are to be used internally to the package only. $TESTOUT was not renamed, because it is exported from the package Test. In general, variables should never be exported, but this would be an interface change, not a refactoring. • I fully qualify all names defined outside a package (Carp::carp and Carp::croak). This helps the reader to know what is defined locally as well as enabling him to find the implementation of or documentation for external functions quickly. I apply this guideline to perl modules. In specialized Perl scripts, such as, templates and tests, I prefer the brevity of the unqualified form. For example, in the unit test example above, I used ok, not Test::ok. • carp and croak print the file and line number for you, so including Test::plan in the error string is unnecessarily redundant. • The spelling error (verison) in the $MacPerl::Version output string was corrected. • The two calls to sprintf and scalar are unnecessary. The concatenation operator (dot) is sufficient, more succinct, and used consistently. • The old style call syntax (&Win32::BuildNumber()) was eliminated, because it was not used in all places ( reset globals()). • The comment # Retval never used: was removed, because it is superfluous, and it indicates an unprovable assertion. You can’t know that the return value won’t be used. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 77 • The comment # guard against -l and... was removed, because the context of print is enough to explain why the local call is needed.8 Even if you don’t know what $, and $\ are, you know they are relevent only to the call to print, since that’s the only thing that it could possibly affect. 9.9 Refactoring Now kids, don’t try this at work. Refactorings and small corrections are not an end to themselves. The do not add business value–unless you are writing your coding style guideline as is the case here. Refactorings need to be related to the task at hand. For example, if there I was given a story to fix the minor defects in plan or to add automatic test case counting, then I would have refactored the code to allow for those changes, and possibly a bit more. However, random and extensive refactoring as I’ve done here is worthless. The original version works just fine, and all the corrections are minor. If you spend your days refactoring and making small corrections without explicit customer approval, you’ll probably lose your job. The new plan is also not just a refactoring. When an interface changes, it’s only a refactoring if all its uses are changed simultaneously. For public APIs like this one, that’s impossible to do. In this particular case, I took a chance that the return value of plan was not used in this rather obscure way, that is, expecting a single list containing undef. 9.10 Input Validation Perl is a dynamically typed language. The routine plan contains a set of type assertions, and the refactored version expanded on them. Is this the best way to write dynamically typed code? but It depends. In this case, explicit type checking is possibly overkill. For example, the $ TODO and $ ONFAIL are dereferenced elsewhere in the package. Dereferencing a non-reference terminates execution in Perl, so the error will be caught anyway. Since Test is only used in test programs, it’s probably sufficient to catch an error at any point. On the other hand, Test is a very public API, which means it has a broad and unknown user base. Explicit type checking almost always yields more 8 In XP, “we comment methods only after doing everything possible to make the method not need a comment.” See http://xp.c2.com/ExtremeDocuments.html for a document about documentation by XP’s founders. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 78 easily understood error messages than implicit error checks. This helps users debug incorrect parameters. plan is only called once during a test execution so the performance impact of the additional checking is insignificant. Here are some guidelines we use to determine when to add type assertions: • Always validate data from untrusted sources, for example, users or third party services. It’s important to give informative error messages to end users. This type of validation occurs at the outermost level of the system, where meaningful error messages can be returned with the appropriate context. • Add type assertions to low level modules that define the data types, and leave them out at the middle levels where they would be redundant. There may be a performance trade off here. In general, the more public the API, the more important validation is. For example, plan defines and asserts that the test count is positive integer. • Assert what is likely to be wrong. • Write deviance tests, that is, tests which result in exceptions or type validation errors. Add assertions if the tests don’t pass. The appropriateness of a particular type assertion is often hard to assess. Don’t sweat it. You’ll learn what’s appropriate as your system evolves. • Don’t expect to get it right, and think about the consequences if you get it wrong. The more that’s at stake, the more important assertions are.9 Writing robust code is hard. If you add too many assertions, their sheer volume will introduce more defects than they were intended to prevent. Add too few assertions, and one day you’ll find a cracker who has compromised your system, or worse. Expect the code to evolve as it gets used. 9.11 You’d Rather Die Nothing is more boring than reading someone’s opinion about coding style. Rather than kill off my readership, I’ll stop here. When you get up to stretch your legs, I’d like you to walk away with five points: • An XP team needs a consistent coding style. 9 Thanks to Ged Haywood for reminding me of this one. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 79 • It doesn’t matter what the style is, as long as everyone agrees to adhere to it. • Take refactoring into consideration when determining your coding style. • Do the simplest thing that could possibly work when writing new code. • Simplify your design so that concepts are expressed once and only once. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 80 Chapter 10 Logistics Failure is not an option. It comes bundled with the software. – Anonymous This chapter is under construction. 81 Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 82 Chapter 11 Test-Driven Design The belief that a change will be easy to do correctly makes it less likely that the change will be done correctly. – Gerald Weinberg1 An XP programmer writes a unit test to clarify his intentions before he makes a change. We call this test-driven design (TDD) or test-first programming, because an API’s design and implementation are guided by its test cases. The programmer writes the test the way he wants the API to work, and he implements the API to fulfill the expectations set out by the test. Test-driven design helps us invent testable and usable interfaces. In many ways, testability and usability are one in the same. If you can’t write a test for an API, it’ll probably be difficult to use, and vice-versa. Test-driven design gives feedback on usability before time is wasted on the implementation of an awkward API. As a bonus, the test documents how the API works, by example. All of the above are good things, and few would argue with them. One obvious concern is that test-driven design might slow down development. It does take time to write tests, but by writing the tests first, you gain insight into the implementation, which speeds development. Debugging the implementation is faster, too, thanks to immediate and reproducible feedback that only an automated test can provide. Perhaps the greatest time savings from unit testing comes a few months or years after you write the test, when you need to extend the API. The 1 Quality Software Management: Vol. 1 Systems Thinking, Gerald Weinberg, Dorset House, 1991, p. 236. 83 unit test not only provides you with reliable documentation for how the API works, but it also validates the assumptions that went into the design of the API. You can be fairly sure a change didn’t break anything if the change passes all the unit tests written before it. Changes that fiddle with fundamental API assumptions cause the costliest defects to debug. A comprehensive unit test suite is probably the most effective defense against such unwanted changes. This chapter introduces test-driven design through the implementation of an exponential moving average (EMA), a simple but useful mathematical function. This chapter also explains how to use the CPAN modules Test::More and Test::Exception. 11.1 Unit Tests A unit test validates the programmer’s view of the application. This is quite different from an acceptance test, which is written from the customer’s perspective and tests end-user functionality, usually through the same interface that an ordinary user uses. In constrast, a unit test exercises an API, formally known as a unit. Usually, we test an entire Perl package with a single unit test. Perl has a strong tradition of unit testing, and virtually every CPAN module comes with one or more unit tests. There are also many test frameworks available from CPAN. This and subsequent chapters use Test::More, a popular and well documented test module.2 I also use Test::Exception to test deviance cases that result in calls to die.3 11.2 Test First, By Intention Test-driven design takes unit testing to the extreme. Before you write the code, you write a unit test. For example, here’s the first test case for the EMA (exponential moving average) module: use strict; use Test::More tests => 1; BEGIN { 2 Part of the Test-Simple distribution, available at http://search.cpan.org/search?query=Test-Simple I used version 0.47 for this book. 3 Version 0.15 used here. Available at http://search.cpan.org/search?query=TestException Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 84 use_ok(’EMA’); } This is the minimal Test::More test. You tell Test::More how many tests to expect, and you import the module with use ok as the first test case. The BEGIN ensures the module’s prototypes and functions are available during compilation of the rest of the unit test. The next step is to run this test to make sure that it fails: % perl -w EMA.t 1..1 not ok 1 - use EMA; # Failed test (EMA.t at line 4) # Tried to use ’EMA’. # Error: Can’t locate EMA.pm in @INC [trimmed] # Looks like you failed 1 tests of 1. At this stage, you might be thinking, “Duh! Of course, it fails.” Testdriven design does involve lots of duhs in the beginning. The baby steps are important, because they help to put you in the mindset of writing a small test followed by just enough code to satisfy the test. If you have maintenance programming experience, you may already be familiar with this procedure. Maintenance programmers know they need a test to be sure that their change fixes what they think is broken. They write the test and run it before fixing anything to make sure they understand a failure and that their fix works. Test-driven design takes this practice to the extreme by clarifying your understanding of all changes before you make them. Now that we have clarified the need for a module called EMA (duh!), we implement it: package EMA; use strict; 1; And, duh, the test passes: % perl -w EMA.t Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 85