The art of software testing. Myers (2nd edition) (2004) (The art of software testing. Myers (2nd edition) (2004).pdf), страница 31

If theapplication worked, it often failed to meet the program specification.The purpose of the XP development methodology is to create quality programs in short time frames. Classical software processes stillwork, but often take too much time, which equates to lost income inthe competitive arena of software development.177178The Art of Software TestingThe XP model relies heavily on unit and acceptance testing ofmodules. In general, you must run unit tests for every incrementalcode change, no matter how small, to ensure that the code base stillmeets its specification. In fact, testing is of such importance in XPthat the process requires that you create the unit (module) andacceptance tests first, then create your code base.

This form of testingis called, appropriately, Extreme Testing (XT).Extreme Programming BasicsAs previously mentioned, XP is a relatively new software development process that enables developers to rapidly create high-qualitycode. In this instance, you may define “quality” as a code base thatmeets its specification. XP focuses on implementing simple designs,communicating between developers and customers, constantly testingyour code base, refactoring to accommodate specification changes,and seeking customer feedback.

XP tends to work well for smallto medium-size development efforts in environments that have frequent specification changes and where near-instant communication ispossible.XP differs from traditional development processes in a several ways.First, it avoids the large-scale project syndrome in which the customerand the programming team meet to design every detail of the application before coding begins. Project managers know this approach hasits drawbacks because customer specifications and requirements constantly change to reflect new business rules or marketplace conditions.For example, the finance department may want payroll reports sortedby processed date instead of check numbers, or the marketing department may determine that consumers will not buy product XYZ if itdoesn’t send e-mail.

XP planning sessions focus on collecting application requirements, not designing the application.Another difference with the XP methodology is that it avoids coding unneeded functionality. If your customer thinks the feature isneeded but not required, it generally is left out of the release. Thus,you can focus on the task at hand, adding value to a software prod-Extreme Testing179uct. Focusing only on the required functionality helps create qualitysoftware in short time frames.However, the primary difference of the XP methodology is that itfocuses on testing.

After an all-inclusive design phase, traditional software development models suggest you code first, then create testinginterfaces later. In XP, you must create the unit tests first, then youcreate the code to pass the tests. You design unit tests in an XP environment by following the concepts discussed in Chapter 5.The XP development model has 12 core practices that drive theprocess.

Table 8.1 summarizes the practices. In a nutshell, you cangroup the 12 core XP practices into four concepts:1. Listening to the customer and other programmers.2. Collaborating with the customer to develop the application’sspecification and test cases.3. Coding with a programming partner.4. Testing the code base.Most of the comments provided by each practice listed in Table8.1 are self-explanatory. However, a couple of the more importantprinciples, namely planning and testing, warrant further discussion.A successful planning phase provides the foundation for the XPprocess. The planning phase in XP differs from that in traditionaldevelopment models, which often combine requirements gatheringand application design. Planning in XP focuses on identifying yourcustomer’s application requirements and designing user stories (orcase stories) that meet them.

You gain a significant insight into theapplication’s purpose and requirements when creating user stories. Inaddition, the customer employs the user stories when performingacceptance tests at the end of a release cycle. Finally, an intangiblebenefit of the planning phase is that the customer gains ownershipand confidence in the application by heavily participating in it.Continuous testing is central to the success of an XP-based effort.Although acceptance testing falls under this principle, unit testingoccupies the bulk of the effort. You want to ensure that any codechanges improve the application and do not introduce bugs.

TheTable 8.1The 12 Practices of Extreme ProgrammingPracticeComment1. Planning and requirements• Marketing and business developmentpersonnel gathering work together toidentify the maximum business valueof each software feature.• Each major software feature isrewritten as a user story.• Programmers provide time estimatesto complete each user story.• The customer chooses the softwarefeatures based on time estimates andbusiness value.• Strive to add small, tangible, valueadded features and release a new codebase often.• Your programming team identifiesan organizing metaphor to help withnaming conventions and program flow.• Implement the simplest design thatallows your code to pass its unit tests.Assume change will come, so don’tspend a lot of time designing; justimplement.• Write unit tests before writing theircode module.

Each unit is not complete until it passes its unit test. Inaddition, the program is not complete until it passes all unit tests andacceptance tests are complete.• Clean up and streamline your codebase. Unit tests help ensure that youdo not destroy the functionality inthe process. You must rerun all unittests after any refactoring.2.

Small, incremental releases3. System metaphors4. Simple designs5. Continuous testing6. Refactoring180Extreme TestingPractice7. Pair programming8. Collective ownership ofthe code9. Continuous integration10. 40-hour work week11. On-site customer12. Coding standards181Comment• You and another programmer worktogether, at the same machine, tocreate your code base. This allows forreal-time code review, whichdramatically increases bug detectionand resolution.• All code is owned by all programmers.No single base programmer isdedicated to a specific code base.• Every day, integrate all changes, afterit passes the unit tests, back into thecode base.• No overtime is allowed. If you workwith dedication for 40 hours perweek, then overtime will not beneeded.

The exception is the weekbefore a major release.• You and your programming teamhave unlimited access to thecustomer so you may resolvequestions quickly and decisively,which keeps the development processfrom stalling.• All code should look the same.Developing a system metaphor helpsmeet this principle.continuous testing principle also supports refactoring efforts used tooptimize and streamline the code base. Constant testing also leads toan intangible benefit: confidence. The programming team gains confidence in the code base because you constantly validate it with unittests. In addition, your customers’ confidence in their investmentsoars because they know the code base passes unit tests every day.182The Art of Software TestingNow that we’ve presented the 12 practices of the XP process, howdoes a typical XP project flow? Here is a quick example of what youmight find if you worked on an XP-based project:1.

Programmers meet with the customer to determine the product requirements and build user stories.2. Programmers meet without the customer to break therequirements into independent tasks and estimate the time tocomplete each task.3. Programmers present the customer with the task list and withtime estimates, and have them create a priority list of features.4. The programming team assigns tasks to pairs of programmersbased on their skill sets.5. Each pair creates unit tests for their programming task usingthe application’s specification.6. The pair works on their task with the goal of creating a codebase that passes the unit tests.7.

Each pair fixes/retests their code until all unit tests are passed.8. All pairs gather and integrate their code base every day.9. The team releases a preproduction version of the application.10. Customers run acceptance tests and either approve the application or create a report identifying the bugs/deficiencies.11. Programmers release a version into production upon successful acceptance tests.12.

Programmers update time estimates based on latest experience.Although glamorous, XP is not for every project or every organization. Proponents of XP concluded that if a programming teamfully implements the 12 practices, then the chances of successfulapplication development increase dramatically. Detractors say thatbecause XP is a process, you must do all or nothing. If you skip apractice, then you are not properly implementing XP and your program quality may suffer. In addition, detractors claim that the cost ofchanging a program in the future to add more features is more thanthe cost of initially anticipating and coding the requirement. Finally,Extreme Testing183some programmers find working in pairs very cumbersome and invasive; therefore, they do not embrace the XP philosophy.Whatever your views, you should consider XP as a software methodology for your project. Carefully weigh its pros and cons along withthe attributes of your project and make the best decision you can.Extreme Testing: The ConceptsTo meet the pace and philosophy of XP, developers use extreme testing, which focuses on constant testing.

As mentioned earlier in thechapter, two forms of testing make up the bulk of XT: unit testingand acceptance testing. The theory used when writing the tests doesnot vary significantly from the theory presented in Chapter 5. However, the stage in the development process in which you create thetests does differ. Nonetheless, XT and traditional testing still have thesame goal: to identify errors in a program.The rest of this section provides more information on unit testingand acceptance testing, from an Extreme Programming perspective.Extreme Unit TestingUnit testing is the primary testing approach used in Extreme Testingand has two simple rules: All code modules must have unit testsbefore coding begins, and all code modules must pass unit tests beforebeing released into production.

At first glance this may not seem soextreme. However, the big difference between unit testing, as previously described, and XT is that the unit tests must be defined andcreated before coding the module.Initially, you may wonder why you should, or how you can, createtest drivers for code you haven’t even written. You may also thinkthat you do not have time to create the tests because the applicationmust meet a deadline. These are valid concerns, but they are easilyaddressed. The following list identifies some benefits associated withwriting unit tests before you start coding the application.184The Art of Software Testing• You gain confidence that your code will meet its specification.• You express the end result of your code before you start coding.• You better understand the application’s specification andrequirements.• You may initially implement simple designs and confidentlyrefactor the code later to improve performance withoutworrying about breaking the specification.Of these benefits, the insight and understanding you gain of theapplication’s specification and requirements cannot be underestimated.