没有合适的资源?快使用搜索试试~ 我知道了~
温馨提示
试读
948页
1.本书获得2008年 Jolt Award技术图书类生产力大奖。. 2.本书作者Gerard Meszaros是ClearStream Consulting(专注于敏捷开发的Calgary咨询机构)的首席科学家和高级顾问。他具有十多年的自动化单元测试架构经验,是测试自动化模式、软件和测试重构以及易测性设计方面的知名专家。.. 3.本书是使用当今最受欢迎的单元测试架构xUnit写自动化测试的权威指南。 4.本书适用于采用敏捷或常规开发过程的开发人员、管理人员和测试人员,而不管他们是进行测试驱动开发还是最后写测试。...
资源推荐
资源详情
资源评论
List of Patterns
Assertion Message (370): We include a descriptive string argument in each call to an Assertion Method.
Assertion Method (362): We call a utility method to evaluate whether an expected outcome has been achieved.
Automated Teardown (503): We keep track of all resources that are created in a test and automatically destroy/free them
during teardown.
Back Door Manipulation (327): We set up the test fi xture or verify the outcome by going through a back door (such as direct
database access).
Behavior Verifi cation (468): We capture the indirect outputs of the system under test (SUT) as they occur and compare them
to the expected behavior.
Chained Tests (454): We let the other tests in a test suite set up the test fi xture.
Confi gurable Test Double (558): We confi gure a reusable Test Double with the values to be returned or verifi ed during the
fi xture setup phase of a test.
Creation Method (415): We set up the test fi xture by calling methods that hide the mechanics of building ready-to-use
objects behind Intent-Revealing Names.
Custom Assertion (474): We create a purpose-built Assertion Method that compares only those attributes of the object that
defi ne test-specifi c equality.
Data-Driven Test (288): We store all the information needed for each test in a data fi le and write an interpreter that reads the
fi le and executes the tests.
Database Sandbox (650): We provide a separate test database for each developer or tester.
Delegated Setup (411): Each test creates its own Fresh Fixture by calling Creation Methods from within the Test Methods.
Delta Assertion (485): We specify assertions based on differences between the pre- and post-exercise state of the SUT.
Dependency Injection (678): The client provides the depended-on object to the SUT.
Dependency Lookup (686): The SUT asks another object to return the depended-on object before it uses it.
Derived Value (718): We use expressions to calculate values that can be derived from other values.
Dummy Object (728): We pass an object that has no implementation as an argument of a method called on the SUT.
Fake Object (551): We replace a component that the SUT depends on with a much lighter-weight implementation.
Four-Phase Test (358): We structure each test with four distinct parts executed in sequence.
Fresh Fixture (311): Each test constructs its own brand-new test fi xture for its own private use.
Garbage-Collected Teardown (500): We let the garbage collection mechanism provided by the programming language clean
up after our test.
Generated Value (723): We generate a suitable value each time the test is run.
Guard Assertion (490): We replace an if statement in a test with an assertion that fails the test if not satisfi ed.
Hard-Coded Test Double (568): We build the Test Double by hard-coding the return values and/or expected calls.
Humble Object (695): We extract the logic into a separate, easy-to-test component that is decoupled from its environment.
Implicit Setup (424): We build the test fi xture common to several tests in the setUp method.
Implicit Teardown (516): The Test Automation Framework calls our clean up logic in the tearDown method after every Test
Method.
In-line Setup (408): Each Test Method creates its own Fresh Fixture by calling the appropriate constructor methods to build
exactly the test fi xture it requires.
In-line Teardown (509): We include teardown logic at the end of the Test Method immediately after the result verifi cation.
Layer Test (337): We can write separate tests for each layer of the layered architecture.
Lazy Setup (435): We use Lazy Initialization of the fi xture to create it in the fi rst test that needs it.
Literal Value (714): We use literal constants for object attributes and assertions.
Minimal Fixture (302): We use the smallest and simplest fi xture possible for each test.
Mock Object (544): We replace an object the SUT depends on with a test-specifi c object that verifi es it is being used correctly
by the SUT.
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.
xUnit Test Patterns
剩余947页未读,继续阅读
joylnwang
- 粉丝: 438
- 资源: 4
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
- 1
- 2
- 3
前往页