|
2.0étoiles sur 5
Falls short of its goal, Avril 17 2004
Par Un client
This book is about Test-Driven Development (TDD). Its purpose is to help you write better code (by having more tests) and give you a head start with existing tools to achieve this.The book falls short of these goals: The explanations about writing tests are short on advice and are sometimes misleading. The presentation of the tools is long, with little useful facts. The book is organized into four parts: Background on TDD, refactoring and programming by intention; A look at JUnit and related tools used to write and run tests; A lengthy example of TDD; An overview of other tools in the xUnit family. The book is targeted at a Java audience but programmers using other languages should have little difficulties understanding the code. I have a major problem with the background section. The author repeatedly claims that TDD provides exhaustive test coverage and ensures that you can refactor your code with confidence. Any error will be caught by the tests. This is foolish. First, tests rarely reach 100% code coverage. Even the sample that the author provides in the book ends up with less than 90% coverage. This leaves many gaps where tests will fail to detect errors. Even if tests cover 100% branches in the code tests are not exhaustive. Depending on the data used, the same branch may exhibit different behavior. (Not to speak about race conditions and other sources of hard to find bugs.) I fully agree with the author that writing unit tests will improve the quality of the code and help find bugs. But claiming that this is a silver bullet is not wise. I would recommend reading books about tests (e.g., Myers' The Art of Software Testing and McConnell's Code Complete chapter on unit testing) in addition to this book. The section on refactoring is a summary of Martin Fowler's Refactoring book which I recommend. The second part presents JUnit. JUnit is a framework used to write and run tests. It is a good presentation. However I would have liked to get pieces of advices on what tests to write in addition to how to write them. The author briefly mentions boundary testing but does not have much to say about the tests themselves. Again a test book is invaluable for this. The author recommends using a test coverage tool as well as Jester to measure the tests coverage. This is a great idea. The third section is an (overly) extended example: the author walks us through writing TDD code. This could have been a great part, giving meaning to the 'practical' adjective in the book title. Unfortunately it is a long rambling, showing lots of code but short on insights. The actual 'meat' of this part could be summarized in less than five pages. The last section presents variations on the JUnit tool. Many languages (C++, C#, VB, Python, etc) are discussed. This part would have been better put on a website rather than printed in the book. Given the changes in some of these frameworks the information is obsolete. The books ends with several appendices dealing with extreme programming and agile modeling. Unit tests are a great tool to improve code quality. Whether or not you actively practice TDD, a good book on it can provide insights into improving your code. This book contains some interesting bits of wisdom. However much of it is buried by the rest of the material.
|
de Kent Beck
de Craig Larman
de Mike Cohn
de Craig Larman
de Joshua Kerievsky
