The 12 Practices of Extreme Programming
(ref :The Art of Software Testing by Glenford J. Myers Revised and Updated by Tom Badgett and Todd M.Thomas with Corey Sandler)
1. Planning and requirements
1. Planning and requirements
• Marketing and business development personnel gathering work together to identify the maximum
business value of each software feature.
• Each major software feature is rewritten as a user story.
• Programmers provide time estimates to complete each user story.
• The customer chooses the software features based on time estimates and business value.
2. Small, incremental releases
• Each major software feature is rewritten as a user story.
• Programmers provide time estimates to complete each user story.
• The customer chooses the software features based on time estimates and business value.
2. Small, incremental releases
• Strive to add small, tangible, value added features and release a new code base often.
3. System metaphors
3. System metaphors
• Your programming team identifies an organizing metaphor to help with naming conventions and program flow.
4. Simple designs
4. Simple designs
• Implement the simplest design that allows your code to pass its unit tests. Assume change will come,so
don’t spend a lot of time designing; just implement.
5. Continuous testing
5. Continuous testing
• Write unit tests before writing their code module. Each unit is not complete until it passes its unit test.In
addition, the program is not complete until it passes all unit tests and acceptance tests are complete.
6. Refactoring
6. Refactoring
• Clean up and streamline your code base. Unit tests help ensure that you do not destroy the functionality in
the process. You must rerun all unit tests after any refactoring.
7. Pair programming
• You and another programmer work together, at the same machine, to create your code base. This allows for
real-time code review, which dramatically increases bug detection and resolution.
8. Collective ownership of the code
real-time code review, which dramatically increases bug detection and resolution.
8. Collective ownership of the code
• All code is owned by all programmers.No single base programmer is dedicated to a specific code base.
9. Continuous integration
9. Continuous integration
• Every day, integrate all changes, after it passes the unit tests, back into the code base.
10. 40-hour work week
10. 40-hour work week
• No overtime is allowed. If you work with dedication for 40 hours per week, then overtime will not be
needed.The exception is the week before a major release.
11. On-site customer
11. On-site customer
• You and your programming team have unlimited access to the customer so you may resolve questions quickly and decisively, which keeps the development process from stalling.
12. Coding standards
12. Coding standards
• All code should look the same.Developing a system metaphor helps meet this principle.
Extreme Testing: The Concepts
To meet the pace and philosophy of XP, developers use extreme testing,which focuses on constant testing. Two forms of testing make up the bulk of XT: unit testing and acceptance testing. The theory used when writing the tests does not vary significantly from the theory of Module(unit) testing. However,the stage in the development process in which you create the tests does differ. Nonetheless, XT and traditional testing still have the same goal: to identify errors in a program
Extreme Unit Testing
Unit testing is the primary testing approach used in Extreme Testing and has two simple rules: All code modules must have unit tests before coding begins, and all code modules must pass unit tests before being released into production. At first glance this may not seem so extreme. However, the big difference between unit testing,and XT is that the unit tests must be defined and created before coding the module.Initially, you may wonder why you should, or how you can, create test drivers for code you haven’t even written. You may also think that you do not have time to create the tests because the application must meet a deadline. These are valid concerns, but they are easily addressed. The following list identifies some benefits associated with writing unit tests before you start coding the application.
• 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 and requirements.
• You may initially implement simple designs and confidently refactor the code later to improve performance without worrying about breaking the specification.
Of these benefits, the insight and understanding you gain of the application’s specification and requirements cannot be underestimated.
For example, you may not fully understand the acceptable data types and boundaries for the input values of an application if you start coding first. So how can you write a unit test to perform boundary analysis without understanding the acceptable inputs? Can the application accept only numbers, only characters, or both? If you create the unit tests first, you must understand the specification. The practice of creating unit tests first is the shining point of the XP methodology, as it forces you to understand the specification to resolve ambiguities before you begin coding.
Only you, as the programmer, know the architecture of the application and how best to build the unit tests for it.
Manually running unit tests, even for the smallest application, can be a daunting task. As the application grows, you may generate hundreds or thousands of unit tests. Therefore, you typically use an automated software testing suite to ease the burden of constantly running unit tests. With these suites you script the tests and then run all or part of them. In addition, testing suites typically allow you to create reports and classify the bugs that frequently occur in your application. This information may help you proactively eliminate bugs in the future.Interestingly enough, once you create and validate your unit tests,the “testing” code base becomes as valuable as the software application you are trying to create. As a result, you should keep the tests in a code repository for protection. In addition, you should ensure that adequate backups occur, as well as that the needed security is in place.
Acceptance Testing
Acceptance testing represents the second, and an equally important,type of XT that occurs in the XP methodology. The purpose of acceptance testing is to determine whether the application meets other requirements such as functionality and usability. You and the customer create the acceptance tests during the design/planning phases.Unlike the other forms of testing customers, not you or your programming partners, conduct the acceptance tests. In this manner, customers provide the unbiased verification that the application meets their needs. Customers create the acceptance tests from user stories. The ratio of user stories to acceptance tests is usually one to many. That is, more than one acceptance test may be needed for each user story. Acceptance tests in XT may or may not be automated. For example, an unautomated test is required when the customer must validate that a user-input screen meets its specification with respect to color
and screen layout. An example of an automated test is when the application must calculate payroll values using data input via some data source such as a flat file to simulate production values.
With acceptance tests, the customer validates an expected result from the application. A deviation from the expected result is considered a bug and is reported to the development team. If customers discover several bugs, then they must prioritize them before passing the list to your development group. After you correct the bugs, or after any change, the customers rerun the acceptance tests. In this manner,the acceptance tests also become a form of regression testing.
An important note is that a program can pass all unit tests but fail the acceptance tests. Why? Because a unit test validates whether a program unit meets some specification such as calculating payroll deductions correctly, not some defined functionality or aesthetics.For a commercial application, the look and feel is a very important component. Understanding the specification, but not the functionality,generally creates this scenario.
Unit testing is the primary testing approach used in Extreme Testing and has two simple rules: All code modules must have unit tests before coding begins, and all code modules must pass unit tests before being released into production. At first glance this may not seem so extreme. However, the big difference between unit testing,and XT is that the unit tests must be defined and created before coding the module.Initially, you may wonder why you should, or how you can, create test drivers for code you haven’t even written. You may also think that you do not have time to create the tests because the application must meet a deadline. These are valid concerns, but they are easily addressed. The following list identifies some benefits associated with writing unit tests before you start coding the application.
• 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 and requirements.
• You may initially implement simple designs and confidently refactor the code later to improve performance without worrying about breaking the specification.
Of these benefits, the insight and understanding you gain of the application’s specification and requirements cannot be underestimated.
For example, you may not fully understand the acceptable data types and boundaries for the input values of an application if you start coding first. So how can you write a unit test to perform boundary analysis without understanding the acceptable inputs? Can the application accept only numbers, only characters, or both? If you create the unit tests first, you must understand the specification. The practice of creating unit tests first is the shining point of the XP methodology, as it forces you to understand the specification to resolve ambiguities before you begin coding.
Only you, as the programmer, know the architecture of the application and how best to build the unit tests for it.
Manually running unit tests, even for the smallest application, can be a daunting task. As the application grows, you may generate hundreds or thousands of unit tests. Therefore, you typically use an automated software testing suite to ease the burden of constantly running unit tests. With these suites you script the tests and then run all or part of them. In addition, testing suites typically allow you to create reports and classify the bugs that frequently occur in your application. This information may help you proactively eliminate bugs in the future.Interestingly enough, once you create and validate your unit tests,the “testing” code base becomes as valuable as the software application you are trying to create. As a result, you should keep the tests in a code repository for protection. In addition, you should ensure that adequate backups occur, as well as that the needed security is in place.
Acceptance Testing
Acceptance testing represents the second, and an equally important,type of XT that occurs in the XP methodology. The purpose of acceptance testing is to determine whether the application meets other requirements such as functionality and usability. You and the customer create the acceptance tests during the design/planning phases.Unlike the other forms of testing customers, not you or your programming partners, conduct the acceptance tests. In this manner, customers provide the unbiased verification that the application meets their needs. Customers create the acceptance tests from user stories. The ratio of user stories to acceptance tests is usually one to many. That is, more than one acceptance test may be needed for each user story. Acceptance tests in XT may or may not be automated. For example, an unautomated test is required when the customer must validate that a user-input screen meets its specification with respect to color
and screen layout. An example of an automated test is when the application must calculate payroll values using data input via some data source such as a flat file to simulate production values.
With acceptance tests, the customer validates an expected result from the application. A deviation from the expected result is considered a bug and is reported to the development team. If customers discover several bugs, then they must prioritize them before passing the list to your development group. After you correct the bugs, or after any change, the customers rerun the acceptance tests. In this manner,the acceptance tests also become a form of regression testing.
An important note is that a program can pass all unit tests but fail the acceptance tests. Why? Because a unit test validates whether a program unit meets some specification such as calculating payroll deductions correctly, not some defined functionality or aesthetics.For a commercial application, the look and feel is a very important component. Understanding the specification, but not the functionality,generally creates this scenario.
---The Art of Software Testing by
Glenford J. Myers
Revised and Updated by
Tom Badgett and Todd M.Thomas
with Corey Sandler
Glenford J. Myers
Revised and Updated by
Tom Badgett and Todd M.Thomas
with Corey Sandler