Đang chuẩn bị liên kết để tải về tài liệu:
xunit test patterns refactoring test code phần 5

Các thử nghiệm chuỗi (454): Chúng tôi cho phép các xét nghiệm khác trong một bộ phần mềm thử nghiệm thiết lập trận đấu thử nghiệm. Cấu hình thử nghiệm đôi (558): Chúng ta cấu hình một đôi thử nghiệm tái sử dụng với các giá trị được trả lại hoặc kiểm tra trong giai đoạn thiết lập trận đấu | Shared Fixture 8 SimpcHPDFRMergeEandSplitUbregistered Version - http www.simpopdf.com When to Use It Regardless of why we use them Shared Fixtures come with some baggage that we should understand before we head down this path. The major issue with a Shared Fixture is that it can lead to interactions between tests possibly resulting in Erratic Tests page 228 if some tests depend on the outcomes of other tests. Another potential problem is that a fixture designed to serve many tests is bound to be much more complicated than the Minimal Fixture page 302 needed for a single test. This greater complexity will typically take more effort to design and can lead to a Fragile Fixture see Fragile Test on page 239 later on down the road when we need to modify the fixture. A Shared Fixture will often result in an Obscure Test page 186 because the fixture is not constructed inside the test. This potential disadvantage can be mitigated by using Finder Methods see Test Utility Method on page 599 with Intent-Revealing Names SBPP to access the relevant parts of the fixture. There are some valid reasons for using a Shared Fixture and some misguided ones. Many of the variations have been devised primarily to mitigate the negative consequences of using a Shared Fixture. So what are good reasons for using a Shared Fixture Variation Slow Tests We can use a Shared Fixture when we cannot afford to build a new Fresh Fixture for each test. Typically this scenario will occur when it takes too much processing to build a new fixture for each test which often leads to Slow Tests page 253 . It most commonly occurs when we are testing with real test databases due to the high cost of creating each of the records. This growth in overhead tends to be exacerbated when we use the API of the SUT to create the reference data because the SUT often does a lot of input validation which may involve reading some of the just-written records. A better solution is to make the tests run faster by not interacting