Extreme Programming with Ant: The First Iteration
This chapter is from the book
This chapter is from the book
This chapter is from the book
In This Chapter
Benefits of Automated Testing
Benefits of Integrating Testing into Ant
Types of Automated Testing
What Is Unit Testing?
Test First Design
JUnit
Version-Control Systems
CVS Access and Logins
Basic Deployment
Ant can play an important role in testing. By integrating testing into the build and deployment process, it becomes easier to implement and enforce ease-of-use considerations and compliance with testing standards. Development teams will see a marked improvement in quality and can more easily stick to delivery schedules. Ant plays a key role in merging the testing process with the build process, to provide a seamless integration of the often-divergent processes.
Story
Networks Byte Design, Inc., has embarked on a project to implement eMarket, their new e-commerce solution for sales and marketing. The core project team has been assembled and is developing the product using XP. So far, the eMarket project team has collected user stories written by the customer, decided on a high-level architecture, and implemented spikes to reduce the risks associated with the technical design decisions. Sandy, the project leader, schedules a release planning meeting between the development team and the customer to sort out the user stories in order to create a release plan.
At the meeting, the developers listen to the customer present each story. The development team divides into smaller groups and assigns a point value to each story to indicate its expected difficulty. During the meeting, some user stories are torn up and rewritten, some are discarded entirely, and a few new stories are added.
The development team returns the stories to the customer with their initial estimates and anticipated velocity. After seeing the estimates, the customer begins to define the priorities. The customer determines the order in which the stories should be implemented, based on the business value and time required to complete the story. The result of the meeting is that the first release plan is developed, which was created to get the stories with the highest business value completed first.
The customer has selected the stories that she wants to have completed in the first iteration, and puts them at the top of the stack of all the stories. The developers and customer go over the user stories, and the development team discusses the technical aspects of the stories and the tasks that need to be completed. Finally, the developers sign up for tasks for this iteration.
Sandy is concerned with the customer's uncertainty about requirements related to workflow and usability. She directs the team to focus on the user interface so that the customer can have an early look at the proposed design and workflow.
Michael, the lead developer, decides that for the first iteration, they will use dummy business objects that have their interfaces developed as needed, but will just return hard-coded data for the time being. The real implementation of the business objects will occur in later iterations.
Having completed the first release plan and iteration plan, the group begins work on the first iteration, which is to begin implementing the Web interface and mocking up the business objects. Each pair of developers will write a unit test that tests the functionality that they are about to implement. That is followed by the required class implementation. As new functionality is added to each class, the unit test is first modified before adding the new functionality to the class. The developers must run their unit tests each time they build their code. To do this efficiently, they need to modify the buildfile to handle unit testing. JUnit, a free open-source tool that integrates easily with Ant, is selected as the team's unit-testing tool.
The expense of fixing a bug also generally increases as you move along the development cycle. A bug caught during development is less expensive to fix than a bug caught during testing. The cost rises dramatically when a bug must be fixed in a product that has already shipped. The sooner bugs can be detected and fixed, the less money they cost to fix.
Testing is an important aspect of every development project. Unless the software can meet the minimal standards for usability, reliability, performance, requirements, and overall quality, it might never make it to a production system. All the work spent in planning, design, and coding will go to waste if the intended audience never uses the system.
With all the emphasis on testing, it would seem that the various forms of testing would be a major aspect of most software-development projects. Unfortunately, many projects start out with good intentions but rarely follow through with those plans. Most people agree on the importance that testing should play in the project, but testing often is conducted toward the end of the project, when the schedule for testing becomes severely compacted, sometimes to the point of becoming ineffective.
To attempt to combat this trend, newer development methodologies, such as XP, emphasize testing early and often in the process. Many of the techniques for testing in these methodologies are not new; they are simply changes in the frequency and schedule of testing procedures. Emphasis is placed on unit testing, in which developers test the smallest components of the system. These new concepts are not miracle cures or silver-bullet solutions, but they can help ensure that the software being developed has been designed and coded with testing in mind.
Benefits of Automated Testing
Automated testing brings a number of benefits. For one, the tests are repeatable. When a test is created, it can be run each time the testing process is launched. Automating testing reduces the fatigue of performing testing manually, which leads to more consistent results. Also, because the tests are automated, they're easy to run, which means that they will be run more often. As new bugs are discovered and fixed, tests can be added to check for those bugs, to ensure that they aren't reintroduced. This increases the overall completeness of testing.
Automating the testing process can be as beneficial as automating the build process. The testing process is based on the concept of being repeatable, which requires an automated or, at the very least, well-documented process. Some of the benefits of automated testing are that it
Is a repeatable process
Uses a consistent approach
Follows a documented process
Frees up developer-hours for more profitable tasks
Is expandable and flexible, with changes in code propagated to the testing procedure faster and more efficiently
Negates the fatigue factor as development deadlines approach because automated tests will eliminate the stress and workload of manual testing on developers
Some drawbacks are worth mentioning, of course. Some features don't easily lend themselves to automated testing. For example, sometimes automation-testing software can be used to test complex GUI applications, but often these applications must be tested by hand.
Automated testing is not a panacea for all problems, but it can contribute to an efficient and effective software development process. Integrating a testing tool into Ant that wasn't designed to be executed from Ant can require additional work. This can be accomplished by extending Ant, using BSF scripting, or using the <exec> task to launch another tool. If the test will be run frequently, the effort is worth the benefits gained in ease of testing.
Because it's a repeatable process, automated testing achieves an important part of the testing process by making it possible to conduct regression testing, to retest the same scenario again. How many bugs reported by testing teams cannot be duplicated by the developers? How many bugs are fixed, yet the tests that are run to check the fixes are insufficient or different from the original tests? These are the types of issues that regression testing helps address, and this is why the benefit of repeatable tests is so high.
Consistency issues are easiest to observe in teams with multiple testers and developers, but even a single tester would rarely conduct the same tests the same way each time. Automating the process maintains consistency from one run of the test to the next, regardless of how much time passes between the two runs of the tests or who is executing the tests.
The best kind of documentation is documentation that does not have to be written and yet is guaranteed to be correct. In a nutshell, that is a description of a self-documenting system. The goal is to create readable code. When the programmer clearly defines the testing goals for the test, someone who comes along later can easily understand the purpose of the test. This documentation does not have to be written; it is a beneficial side effect. The code is guaranteed to be correct because the tests have been executed under certain conditions and passed. Basically, tests should be as self-documenting as possible. Most developers don't like to comment the code that's going into the product. They're even less likely to comment the unit tests that accompany the product code because they know that the unit-test code won't go into the product. By developing readable code, the need to heavily comment the unit tests is greatly reduced.
By automating the testing process, the computer will usually execute the testing process in less time than it takes a tester to perform manually. Although the code will take the same time to execute, the prep time and interpretation of the results will be quicker with the automated process. Also, because this is a repeatable test, the automated approach becomes even more beneficial when the tests must be run multiple times. People get tired of conducting the same tests repeatedly, and will make mistakes, but the automated processes run consistently each time. Again, manual testing has its place; the advantage of automated testing is that it can easily catch many of the problems before manual testing even begins.