Named Test Suite (592): We defi ne a test suite, suitably named, that contains a set of tests that we wish to be able to run as a
group.
Parameterized Test (607): We pass the information needed to do fi xture setup and result verifi cation to a utility method that
implements the entire test life cycle.
Prebuilt Fixture (429): We build the Shared Fixture separately from running the tests.
Recorded Test (278): We automate tests by recording interactions with the application and playing them back using a test
tool.
Scripted Test (285): We automate the tests by writing test programs by hand.
Setup Decorator (447): We wrap the test suite with a Decorator that sets up the shared test fi xture before running the tests
and tears it down after all the tests are done.
Shared Fixture (317): We reuse the same instance of the test fi xture across many tests.
Standard Fixture (305): We reuse the same design of the test fi xture across many tests.
State Verifi cation (462): We inspect the state of the SUT after it has been exercised and compare it to the expected state.
Stored Procedure Test (654): We write Fully Automated Tests for each stored procedure.
Suite Fixture Setup (441): We build/destroy the shared fi xture in special methods called by the Test Automation Framework
before/after the fi rst/last Test Method is called.
Table Truncation Teardown (661): We truncate the tables modifi ed during the test to tear down the fi xture.
Test Automation Framework (298): We use a framework that provides all the mechanisms needed to run the test logic so the
test writer needs to provide only the test-specifi c logic.
Test Discovery (393): The Test Automation Framework discovers all the tests that belong to the test suite automatically.
Test Double (522): We replace a component on which the SUT depends with a “test-specifi c equivalent.”
Test Enumeration (399): The test automater manually writes the code that enumerates all tests that belong to the test suite.
Test Helper (643): We defi ne a helper class to hold any Test Utility Methods we want to reuse in several tests.
Test Hook (709): We modify the SUT to behave differently during the test.
Test Method (348): We encode each test as a single Test Method on some class.
Test Runner (377): We defi ne an application that instantiates a Test Suite Object and executes all the Testcase Objects it
contains.
Test Selection (403): The Test Automation Framework selects the Test Methods to be run at runtime based on attributes of
the tests.
Test Spy (538): We use a Test Double to capture the indirect output calls made to another component by the SUT for later
verifi cation by the test.
Test Stub (529): We replace a real object with a test-specifi c object that feeds the desired indirect inputs into the SUT.
Test Suite Object (387): We defi ne a collection class that implements the standard test interface and use it to run a set of
related Testcase Objects.
Test Utility Method (599): We encapsulate the test logic we want to reuse behind a suitably named utility method.
Test-Specifi c Subclass (579): We add methods that expose the state or behavior needed by the test to a subclass of the SUT.
Testcase Class (373): We group a set of related Test Methods on a single Testcase Class.
Testcase Class per Class (617): We put all the Test Methods for one SUT class onto a single Testcase Class.
Testcase Class per Feature (624): We group the Test Methods onto Testcase Classes based on which testable feature of the
SUT they exercise.
Testcase Class per Fixture (631): We organize Test Methods into Testcase Classes based on commonality of the test fi xture.
Testcase Object (382): We create a Command object for each test and call the run method when we wish to execute it.
Testcase Superclass (638): We inherit reusable test-specifi c logic from an abstract Testcase Superclass.
Transaction Rollback Teardown (668): We roll back the uncommitted test transaction as part of the teardown.
Unfi nished Test Assertion (494): We ensure that incomplete tests fail by executing an assertion that is guaranteed to fail.
评论0
最新资源