Nội dung

implement the functions on demand for the customer. The functions are responsible for checking the computer’s role in the script. For example, this test script states that the user clicks on the Dogs link on the home page. If the Dogs link is missing from the home page or spelled incorrectly, the follow link action stops and indicates that the test script has failed. This approach is called fast fail, and makes it easy to write and maintain test scripts. In keeping with the movie script analogy, it’s like when the director sees computer screwing up its lines, and yells, “cut!”. Everybody stops. The director corrects what’s wrong, and the actors start over again. The next section tests the search facility. We should be able to find our dog by searching for corgi, CORGI, and dogs wales. We aren’t particularly interested in Corgis7 , rather our goal is to test that the search mechanism is case-insensitive and supports multiple words. And, most importantly, the list of search results allows the buyer to place found animals in their cart easily. Shoppers should be given an opportunity to buy what they find. 8.4 Group Multiple Paths 8.4. GROUP MULTIPLE PATHS The previous example demonstrated testing multiple paths, that is, different ways of doing the same thing. In one case, we searched for a Female Puppy Corgi hierarchically, and then we used the search box to find the same dog using different keywords. Here is another example that demonstrates multiple paths: test_setup(’PetShop’); home_page(); follow_link(’Reptiles’); follow_link(’Rattlesnake’); add_to_cart(’Rattleless Rattlesnake’); remove_from_cart(’Rattleless Rattlesnake’); search_for(’Angelfish’); add_to_cart(’Large Angelfish’); update_cart(’Large Angelfish’, 0); 7 Or other high-energy small dogs. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 60 This example tests the two ways you can remove animals from the cart. remove from cart uses a button labeled Remove to delete the item from the cart. update cart allows buyers to change the quantity desired. Setting it to zero should have the same effect as remove from cart. Most applications allow you to do something in more than one way, like in this example. Grouping similar functions in the same test is another organizational technique for your acceptance test suite. It also provides an opportunity to talk about an application cross-functionally. The creation of test scripts is a collaborative effort, much like pair programming. This sort of detailed matters, and probably won’t come up during the planning game. The details emerge when the stories and their acceptance tests are being implemented. The test suite opens a communication channel between the programmers and the customer to discuss application consistency and other technical details, such as what to do when the user enters an unexpected value. 8.5 Without Deviation, Testing Is Incomplete 8.5. WITHOUT DEVIATION, TESTING IS INCOMPLETE The acceptance test suite also checks that the application handles unexpected input gracefully. For example, if the user enters an incorrect login name, the application should tell the user not found or something similar. The technical term for this is deviance testing. It’s like kicking the tires or slamming the car into reverse while driving on the highway. The previous examples are conformance tests, because they only validate using the application for its intended purpose. When you write a deviance test, you break the rules in order to ensure the application doesn’t do the wrong thing, such as displaying a stack trace instead of an error message or allowing unauthorized access. For example, here’s how we test login conformance and deviance of the PetShop: test_setup(’PetShop’); home_page(); login_as(’demo’, ’password’); login_as(’DEMO’, ’password’); login_as(’demo@bivio.biz’, ’password’); login_as(’Demo@Bivio.Biz’, ’password’); Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 61 test_deviance(’does not match’); login_as(’demo’, ’PASSWORD’); test_deviance(’must supply a value’); login_as(’demo’, ’’); login_as(’’, ’password’); test_deviance(’not found’); login_as(’notuser’, ’password’); login_as("demo’||’", ’password’); login_as(’%demo%’, ’password’); The first section tests conformance. We login as demo and DEMO to test that user names can be case insensitive. The PetShop allows you to login with an email address, case insensitively. Passwords are case sensitive, however. The next section expects the application to return an error message that contains does not match when given a password in the wrong case. This is a deviance test, and the test deviance that begins the next section tells the test framework that the subsequent statements should fail and what the expected output should contain. This is an example where the test script specifies the computer’s role as well as the user’s. The application should ask the user to supply a value, if either the login name or password fields on the form are blank. The next section tests this. This case might be something a programmer would suggest to the customer. The customer might decide that must supply a value is too computer-like, and ask the programmer to change the application to say something like, Please enter your login ID or email address. In the last section, we test a variety of not found cases. The first case assumes that notuser is not a user in the system. The test suite database is constructed so that this is the case. The last two cases are highly technical, and are based on the programmer’s knowledge of the application internals, that is, SQL, a database programming language, is used to find the user. Some applications do not correctly validate application input, which can allows the user unauthorized access to system internals. This is how computer virii and worms work. This test case validates that the user name is checked by the application before it is used in a low-level SQL statement. If the user name syntax is not checked by the application, one of the last two cases might allow the user to login, and the deviance test would fail. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 62 Note that we didn’t test notuser without a password. It’s not likely that an invalid user could login without a password when a valid user couldn’t. In testing parlance, the two tests are in the same equivalence class. This means we only need to test one case or the other but not both. We use equivalence classes to reduce the size of the test suite. A large application test suite will have thousands of cases and take hours to run. It’s important to keep the runtime as short as possible to allow for frequent testing. And, as always, the less code to do what needs to get done, the better. 8.6 Subject Matter Oriented Programming 8.6. SUBJECT MATTER ORIENTED PROGRAMMING Another way to minimize test length is letting the problem, also known as subject matter, guide the development of the functions used by the scripts. The customer is probably not a programmer. Moreover, the customer’s terminology has probably been refined to match her subject matter. The programmers should let the customer choose the function names, and the order and type of the function parameters. The language she uses is probably near optimal for the subject and workflow. The process of bringing the program to the problem is what I call, subject matter oriented programming (SMOP). It is what XP strives for: creating an application that speaks the customer’s language. The acceptance test suite is probably the customer’s most important design artifact, because it encodes the detailed knowledge of what the application is supposed to do. If she or her co-workers can’t read the tests, the suite’s value is greatly diminished. The design and implementation of the acceptance test suite evolves as the customer encodes her knowledge. The programmer may need to help the customer to identify the vocabulary of the subject matter. Subject matter experts sometimes have difficulty expressing what they do succinctly. The programmer needs to be part linguist, just like Larry Wall, Perl’s inventor. Unlike other language designers, Larry lets the problems programmers face dictate the solution (the programming language) they use. Perl is not prescriptive, in linguistics terms, but descriptive, evolving to meet the language used by programmers, not the other way around. Enough theory. I’m in danger of getting lost in the solution myself. If you are a programmer, you’ll learn how to implement a subject matter oriented program in the It’s a SMOP chapter. I’ll get back to the customer, Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 63 and another method by which she can create the acceptance test suite. 8.7 Data-Driven Testing 8.7. DATA-DRIVEN TESTING The test examples up to this point have been written in Perl syntax. While I fully believe just about anybody can follow these simple syntactic conventions, customers may balk at the idea. Ward Cunningham, a well-known XPer, has taken subject matter oriented programming to a new level. His framework for intergrated testing (FIT) lets customers write acceptance tests in their own language using their own tools, office applications, such as, word processors and spreadsheets. Here’s the login test translated as a FIT document: FIT Login FIT ignores all text in the document except for tabular text. The tables contain the text inputs and expected outputs. This allows the customer to document the test, and to have one document which contains many tests. The order of the columns and what they are for is worked out between the Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 64 customer and the programmer. Once that’s done, the framework does the rest.8 Just like the Perl examples earlier, the customer must specify the test language interpreter, PetShop. In this type of FIT test, the customer enters actions (login) on a row-by-row basis. The programmer can create new actions. The cells to the right of the action name are parameters. The login action accepts a user name, a password, and an error message. If the there’s no error message, login tests that the login was successful. The subject matter may suggest a different organization for the tables. For example, here’s a denser test format for a simple math module:9 FIT Math As with the login test, the first line contains the test language interpreter, SimpleMath. The next row lists the actions in a columnar format. The first action sets an x value, the next sets y, and the last two columns test adding 8 Thanks to Brian Ingerson for implementing Test-FIT, and making it available on CPAN. 9 SimpleMath and the test data were adapted from Test-FIT, version 0.11, on CPAN. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 65 (sum)) and subtracting (diff). The subsequent rows contain a test in each cell of the table. The first row sets x and y to 1 and 2 and tests that sum and diff return 3 and -1. As you can see, this kind of FIT test gives the customer a clear overview of the acceptance test data using an ordinary word processor. With this style of testing, customers can create spreadsheets using formulas. The general term for using documents as test inputs is called data-driven testing. And, sometimes there’s no practical alternative to using tabular data. On one project we developed, we needed to test the correctness of a pre-marital evaluation tool. Each partner in a couple had to answer 350 questions. The scoring algorithm related the couple’s answers for compatibility. The customer had supplied us with the questions, answers, scores, and weights in tabular format. When we asked for acceptance test data, he simply added the answers for test couples in another column, and we generated the test suite by parsing out the data. As it turned out, the test data uncovered several areas that were misunderstood by the programmers. Without customer generated test data, the software would have contained critical defects. 8.8 Empower The Customer to Test 8.8. EMPOWER THE CUSTOMER TO TEST Whether the customer uses a spreadsheet, a word processor, or Perl, she can write tests. And, she needs to. No one else on the team knows the subject matter better than she does. Getting started is the hardest part. Take the simplest and most straightforward part of the application. Write a test outline for it together on the whiteboard. Implement that test, and run it together. After the first steps, you’ll fill in more and more detail. As the suite grows with the implementation, the application will benefit from the regular exercise. The programmers will gain deeper insight into the subject matter. The customer will see the quality improve firsthand. And, everybody will benefit from the well-structured knowledge base encoded by your acceptance test suite. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 66 Chapter 9 Coding Style Language requires consensus. – Larry Wall1 Code is the primary means of communication in an XP team. A uniform coding style greatly facilitates code comprehension, refactoring, pair programming, collective ownership and testing. An XP team agrees on a coding style before development starts. Coding style is the first problem and XP team has to work out as a group. The solution to the problem needs to be clear and unambiguous. It’s amazing how far this can be, and with some teams it’s impossible. Coding style discussions are like a lightning rod. If there’s a storm brewing within the team, coding style will usually attract the first lightning strike. If you can’t reach agreement on a style, your team is going to have difficulty building an application together. Tension around style choices is natural in some ways. We are all individuals. Programmers take pride in their own work, further motivating their own success, just as individual athletes value their own accomplishments. However, not even the best pitcher, quarterback, or forward in the world can win a game alone. It takes a team and teamwork to win a game or write a large application. Programming is a team sport.2 If you are a programmer, you may find yourself gritting your teeth at my coding style. It wouldn’t surprise me. Athletes and programmers on 1 Open Sources: Voices from the Open Source Revolution, DiBona et al, 1999, O’Reilly, p. 127. Available online at http://www.oreilly.com/catalog/opensources/book/larry.html 2 And more generally, “Business is a team sport.” Rich Kid, Smart Kid, Kiyosaki et al, Warner Books, 2001, p. 224-225. 67 different teams sometimes bristle at each other’s style. However, if we were to join the same team, we’d work out a compromise on coding style to ensure the success of the project. This chapter explains the need for a coding style in XP and discusses how to go about creating one. I also explain and demonstrate the coding style used in this book through a comparative example. 9.1 There’s More Than One Way To Do It Perl is a rich and complex language. If you ask a question about how to do something in Perl on the Internet, you’ll probably get several different answers. And, the answers will often include the caveat: TMTOWTDI. This is the acronym for Perl’s motto: There’s more than one way to do it. The solution you choose will depend on the way you program Perl. So how do you program Perl? Larry Wall et al present a coding style in the perlstyle man page.3 Yet there are myriad divergent styles on CPAN and in the Perl literature. In the Perl community, diversity is seen as a strength, and no one is going to tell you how to program Perl. Well, even if they did, you wouldn’t listen to them. 9.2 Give Me Consistency or Give Me Death Your team still needs to pick a style. This isn’t just XP dogma; it’s human nature. In the anthropology classic, The Silent Language, Edward Hall wrote, “The drive toward congruity would seem to be as strong a human need as the will to physical survival.” I conclude from this that if you don’t pick a Perl coding style, you’ll die. If that isn’t a good enough reason, stop reading now. Seriously, consistency is not an end in itself, it is the means to facilitate testing, collective ownership, pair programming, and refactoring. If you are developing a small application (a few thousand lines of Perl), it’s easy to keep the code consistent, or to clean it up in an afternoon or two. For large applications (tens or hundreds of thousands of lines spread over hundreds or thousands of files), quick fixes are impossible. You would never have the time to reformat the entire codebase. The code changes too quickly. You don’t get to ask everybody working on a large application to stop while you fix some style issue. However, for 3 http://www.perl.com/doc/manual/html/pod/perlstyle.html Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 68 some necessary refactorings, such as, a change in a widely used API, you may have no choice but to dive into tens or possibly hundreds of files. You’ll want this to happen as quickly as possible so you’ll automate the refactoring. With a consistent style, you can probably do this fairly easily. If you have to account for the many ways you can do things in Perl, you’ll probably resort to hand editing each file. Not only is this labor intensive, but it’s error prone, too. Even when you aren’t making global changes, you and your partner still have to read unfamiliar code. A programming pair’s ability to read and to communicate through the code is affected directly by its consistency. Communication is hard enough without you and your partner having to wade through several code dialects. And, allowing for style variations when writing code opens up too many unnecessary thoughts. Do I adapt to my partner’s style? Should we adopt the style of the code we’re editing now? Or perhaps, I should insist on my style. After all, it has worked well for me over the years. Starting out with an agreed upon style, frees our minds of such distractions and allows us to focus on the important bit: solving the customer’s problem. 9.3 Team Colors In Extreme Programming Explained, Kent Beck wrote, “The standard must be adopted voluntarily by the whole team.” This may not be so simple. Establishing consensus requires work on everybody’s part. If your team has coded together before, you’ll probably have an easy time agreeing on a style. For newly formed teams, use the style guide as a team building exercise. Everyone should be encouraged to contribute. If a particular point is too contentious, drop it until after the first iteration or so. The goal is to get full consensus on the entire guide. If someone is particularly inflexible during the discussions, it’s a warning sign that a team adjustment may be necessary. Better sooner than later. A style guide can be highly motivating, however. It’s like your team’s colors. It’s something relatively insignificant which provides significant cohesion. If even one team member is coerced into agreement, the team isn’t sticking together, and the rift may grow into a chasm. When everybody voluntarily accepts the style choices, you are functioning as a team, and you are ready to code. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 69