Information Technology Reference
In-Depth Information
time as performance tests. This isn't very effective. Because the cover-
age process affects the test performance, we highly recommend you
not run performance, stress, or load tests at the same time.
Listing 7-10 shows the JUnit task's
batchtest
element for run-
ning a series of component tests with coverage turned on. Note how a
few tests (corresponding to load, stress, and performance categories)
get excluded from the run. Much like you devise strategies for catego-
rizing tests and their frequencies, think through your coverage report
frequencies to obtain all of the benefits without any additional head-
aches from stressing out your computing resources.
LISTING 7-10
batchtest Element with Coverage Turned On, Excluding
Te s t s
<batchtest todir="${testreportdir}">
<fileset dir="test/component">
<include name="**/*Test.*" />
<exclude name="**/*StressTest.java" />
<exclude name="**/BatchDepXMLReportPerfTest.java" />
<exclude name="**/BatchDepXMLReportLoadTest.java"/>
</fileset>
</batchtest>
❑❑❑❑❑❑❑❑❑
In this chapter, you learned how to harness the power of CI—once
again—by automating software inspections. No matter how mundane
the anomaly, an inspection tool will consistently throw up flags on sus-
pect code that more than likely will lead to bigger technical risks. Code
inspections and reviews have proven to be an effective mechanism for
discovering defects; however, by
continuously
performing this inspec-
tion process any time a change occurs (using CI), the time between
the discovery and fix is consistently reduced.
As with testing, inspection can provide quantitative metrics of suc-
cess to developers, management, the customer, and potential custom-
ers. Teams can quantify qualitative measurements by running
inspectors on code to ensure quality thresholds are met, thus demon-
strating the software's future performance in the user's environment.
