Growing Object-Oriented Software, Guided by Tests- P6

Growing Object-Oriented Software, Guided by Tests- P6: 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...
Nội dung trích xuất từ tài liệu:
Growing Object-Oriented Software, Guided by Tests- P6226 Chapter 19 Handling Failure development cycle is so critical—we always get into trouble when we don’t keep up that side of the bargain. Small Methods to Express Intent We have a habit of writing helper methods to wrap up small amounts of code—for two reasons. First, this reduces the amount of syntactic noise in the calling code that languages like Java force upon us. For example, when we disconnect the Sniper, the translatorFor() method means we don’t have to type AuctionMessageTranslator twice in the same line. Second, this gives a mean- ingful name to a structure that would not otherwise be obvious. For example, chatDisconnectorFor() describes what its anonymous class does and is less intrusive than defining a named inner class. Our aim is to do what we can to make each level of code as readable and self- explanatory as possible, repeating the process all the way down until we actually have to use a Java construct. Logging Is Also a Feature We defined XMPPFailureReporter to package up failure reporting for the AuctionMessageTranslator. Many teams would regard this as overdesign and just write the log message in place. We think this would weaken the design by mixing levels (message translation and logging) in the same code. We’ve seen many systems where logging has been added ad hoc by developers wherever they find a need. However, production logging is an external interface that should be driven by the requirements of those who will depend on it, not by the structure of the current implementation. We find that when we take the trouble to describe runtime reporting in the caller’s terms, as we did with the XMPPFailureReporter, we end up with more useful logs. We also find that we end up with the logging infrastructure clearly isolated, rather than scattered throughout the code, which makes it easier to work with. This topic is such a bugbear (for Steve at least) that we devote a whole section to it in Chapter 20.Part IVSustainable Test-DrivenDevelopment This part discusses the qualities we look for in test code that keep the development “habitable.” We want to make sure the tests pull their weight by making them expressive, so that we can tell what’s important when we read them and when they fail, and by making sure they don’t become a maintenance drag themselves. We need to apply as much care and attention to the tests as we do to the production code, although the coding styles may differ. Difficulty in testing might imply that we need to change our test code, but often it’s a hint that our design ideas are wrong and that we ought to change the production code. We’ve written up these guidelines as separate chapters, but that has more to do with our need for a linear structure that will fit into a book. In practice, these qualities are all related to and support each other. Test-driven development combines testing, specification, and design into one holistic activity.11. For us, a sign of this interrelatedness was the difficulty we had in breaking up the material into coherent chapters.This page intentionally left blankChapter 20Listening to the Tests You can see a lot just by observing. —Yogi BerraIntroductionSometimes we find it difficult to write a test for some functionality we want toadd to our code. In our experience, this usually means that our design can beimproved—perhaps the class is too tightly coupled to its environment or doesnot have clear responsibilities. When this happens, we first check whether it’s anopportunity to improve our code, before working around the design by makingthe test more complicated or using more sophisticated tools. We’ve foundthat the qualities that make an object easy to test also make our code responsiveto change. The trick is to let our tests drive our design (that’s why it’s called test-drivendevelopment). TDD is about testing code, verifying its externally visible qualitiessuch as functionality and performance. TDD is also about feedback on the code’sinternal qualities: the coupling and cohesion of its classes, dependencies that areexplicit or hidden, and effective information hiding—the qualities that keep thecode maintainable. With practice, we’ve become more sensitive to the rough edges in our tests, sowe can use them for rapid feedback about the design. Now when we find a featurethat’s difficult to test, we don’t just ask ourselves how to test it, but also why isit difficult to test. In this chapter, we look at some common “test smells” that we’ve encounte ...