tailieunhanh - 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. | 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 meaningful 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 IV Sustainable Test-Driven Development This part discusses the .