The test infection technique adapts the workflow of test-driven development approaches to classroom assignments. The technique's name derives from Erich Gamma's observation that, once a programmer adopts test-driven development, he or she never "goes back," and subsequently advocates this change to fellow software developers. The technique may be combined with sample code bazaar , or applied to code written from scratch. With test infection , both the instructor and the students validate submitted code by preparing test fixtures for detecting as wide a variety of errors as possible.
In the first phase of the exercise, students submit unit test suites that, in their view, would sufficiently confirm appropriate implementation of the required functionality. The instructor runs these suites against a variety of possible implementations, both correct and incorrect. The primary goal of the first phase is to eliminate false-positive tests: unit tests that fail code which is known to be correct. Initial elimination of such false-positives is necessary because they would otherwise disrupt the subsequent testing of students' submitted implementations. The instructor may choose to provide one round of evaluation at this point, scoring students based on the number of false-positive tests that were submitted.
With the battery of tests --- from both the instructor and every student in the class --- now ready and pruned of false-positives, students may submit their own respective implementations of the required functionality. Upon submission, each implementation is then run against each set of tests, resulting in a two-dimensional matrix of test suites vs. implementations. With false-positives already eliminated, two issues remain:
Students with the fewest combined true-positives in their implementations and false-negatives in their test suites (or none at all) then "do best" for the exercise.
A particularly engaging approach to test infection is to build the test suite vs. implementation matrix in class. As tests fail (or incorrectly pass wrong implementations), the code in question can be displayed and discussed. The code can then be modified on the fly, until the correct behavior is achieved ("going green," to borrow a phrase from the test-driven development arena). This way, students are exposed to yet another recommended development practice in the context of learning the material at hand.