Đang chuẩn bị liên kết để tải về tài liệu:
Growing Object-Oriented Software, Guided by Tests- P7

Không đóng trình duyệt đến khi xuất hiện nút TẢI XUỐNG Tải xuống

Growing Object-Oriented Software, Guided by Tests- P7: Test-Driven Development (TDD) hiện nay là một kỹ thuật được thành lập để cung cấp các phần mềm tốt hơn nhanh hơn. TDD là dựa trên một ý tưởng đơn giản: các bài kiểm tra Viết cho code của bạn trước khi bạn viết đoạn code riêng của mình. Tuy nhiên, điều này "đơn giản" ý tưởng có kỹ năng và bản án để làm tốt. Bây giờ có một tài liệu hướng dẫn thiết thực để TDD mà sẽ đưa bạn vượt ra ngoài những khái niệm cơ bản. Vẽ trên một. | Chapter 24 Test Flexibility complex. Different test scenarios may make the tested code return results that differ only in specific attributes so comparing the entire result each time is misleading and introduces an implicit dependency on the behavior of the whole tested object. There are a couple of ways in which a result can be more complex. First it can be defined as a structured value type. This is straightforward since we can just reference directly any attributes we want to assert. For example if we take the financial instrument from Use Structure to Explain page 253 we might need to assert only its strike price assertEquals strike price 92 instrument.getStrikePrice without comparing the whole instrument. We can use Hamcrest matchers to make the assertions more expressive and more finely tuned. For example if we want to assert that a transaction identifier is larger than its predecessor we can write assertThat instrument.getTransactionId largerThan PREVIOUS_TRANSACTION_ID This tells the programmer that the only thing we really care about is that the new identifier is larger than the previous one its actual value is not important in this test. The assertion also generates a helpful message when it fails. The second source of complexity is implicit but very common. We often have to make assertions about a text string. Sometimes we know exactly what the text should be for example when we have the FakeAuctionServer look for specific messages in Extending the Fake Auction page 107 . Sometimes however all we need to check is that certain values are included in the text. A frequent example is when generating a failure message. We don t want all our unit tests to be locked to its current formatting so that they fail when we add whitespace and we don t want to have to do anything clever to cope with timestamps. We just want to know that the critical information is included so we write assertThat failureMessage allOf containsString strikePrice 92 containsString id .