What do you think?
Rate this book
A Kent Beck Signature Book
Growing Object-Oriented Software, Guided by Tests
Foreword by Kent Beck "The authors of this book have led a revolution in the craft of programming by controlling the environment in which software grows.” --Ward Cunningham “At last, a book suffused with code that exposes the deep symbiosis between TDD and OOD. This one's a keeper.” --Robert C. Martin “If you want to be an expert in the state of the art in TDD, you need to understand the ideas in this book.”-- Michael Feathers Test-Driven Development (TDD) is now an established technique for delivering better software faster. TDD is based on a simple Write tests for your code before you write the code itself. However, this "simple" idea takes skill and judgment to do well. Now there's a practical guide to TDD that takes you beyond the basic concepts. Drawing on a decade of experience building real-world systems, two TDD pioneers show how to let tests guide your development and “grow” software that is coherent, reliable, and maintainable. Steve Freeman and Nat Pryce describe the processes they use, the design principles they strive to achieve, and some of the tools that help them get the job done. Through an extended worked example, you’ll learn how TDD works at multiple levels, using tests to drive the features and the object-oriented structure of the code, and using Mock Objects to discover and then describe relationships between objects. Along the way, the book systematically addresses challenges that development teams encounter with TDD--from integrating TDD into your processes to testing your most difficult features. Coverage includes • Implementing TDD getting started, and maintaining your momentum throughout the project • Creating cleaner, more expressive, more sustainable code • Using tests to stay relentlessly focused on sustaining quality • Understanding how TDD, Mock Objects, and Object-Oriented Design come together in the context of a real software development project • Using Mock Objects to guide object-oriented designs • Succeeding where TDD is managing complex test data, and testing persistence and concurrency.
345 pages, Paperback
First published October 1, 2009
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 134 reviews
November 3, 2014
A great read for anyone interested in automated testing and TDD.
Pros:
* Makes a strong case for testing: better design, faster feedback, user experience first, regression, and most importantly, the confidence to make changes quickly.
* Includes a nice walk through of an iterative, test driven development process of a small app.
* Lots of great examples of how "listening" to tests leads to better design (ie, what the "driven" really means in TDD).
* I learned a lot from the discussion of how to make tests readable and maintainable.
Cons:
* The book is 100% Java. How do these lessons apply to other OO languages?
* The authors spend too much time selling the jMock framework
* The app they develop iteratively is a Java swing app full of distracting details like the way Swing manages threads. It was a bit boring at times and the code was verbose, so it was easy to lose focus.
Fun quotes:
What if software wasn’t “made,” like we make a paper airplane—finish folding it and fly it away? What if, instead, we treated software more like a valuable, productive plant, to be nurtured, pruned, harvested, fertilized, and watered? Traditional farmers know how to keep plants productive for decades or even centuries. How would software development be different if we treated our programs the same way?
As John Gall wrote in [Gall03], “A complex system that works is invariably found to have evolved from a simple system that works.”
In our work, we apply feedback cycles at every level of development, organizing projects as a system of nested loops ranging from seconds to months, such as: pair programming, unit tests, acceptance tests, daily meetings, iterations, releases, and so on. Each loop exposes the team’s output to empirical feedback so that the team can discover and correct any errors or misconceptions.
One lesson that we’ve learned repeatedly is that nothing forces us to understand a process better than trying to automate it.
Our experience is that, when code is difficult to test, the most likely cause is that our design needs improving. The same structure that makes the code difficult to test now will make it difficult to change in the future.
When composing objects into a new type, we want the new type to exhibit simpler behavior than all of its component parts considered together. The composite object’s API must hide the existence of its component parts and the interactions between them, and expose a simpler abstraction to its peers.
In most systems we build, we end up writing a runtime exception called something like Defect (or perhaps StupidProgrammerMistakeException). We throw this when the code reaches a condition that could only be caused by a programming error, rather than a failure in the runtime environment.
By repeatedly fixing local problems in the code, we find we can explore the design safely, never straying more than a few minutes from working code. Usually this is enough to lead us towards a better design, and we can always backtrack and take another path if it doesn’t work out. One way to think of this is the rock climbing rule of “three-point contact.” Trained climbers only move one limb at a time (a hand or a foot), to minimize the risk of falling off. Each move is minimal and safe, but combining enough of them will get you to the top of the route.
Pros:
* Makes a strong case for testing: better design, faster feedback, user experience first, regression, and most importantly, the confidence to make changes quickly.
* Includes a nice walk through of an iterative, test driven development process of a small app.
* Lots of great examples of how "listening" to tests leads to better design (ie, what the "driven" really means in TDD).
* I learned a lot from the discussion of how to make tests readable and maintainable.
Cons:
* The book is 100% Java. How do these lessons apply to other OO languages?
* The authors spend too much time selling the jMock framework
* The app they develop iteratively is a Java swing app full of distracting details like the way Swing manages threads. It was a bit boring at times and the code was verbose, so it was easy to lose focus.
Fun quotes:
What if software wasn’t “made,” like we make a paper airplane—finish folding it and fly it away? What if, instead, we treated software more like a valuable, productive plant, to be nurtured, pruned, harvested, fertilized, and watered? Traditional farmers know how to keep plants productive for decades or even centuries. How would software development be different if we treated our programs the same way?
As John Gall wrote in [Gall03], “A complex system that works is invariably found to have evolved from a simple system that works.”
In our work, we apply feedback cycles at every level of development, organizing projects as a system of nested loops ranging from seconds to months, such as: pair programming, unit tests, acceptance tests, daily meetings, iterations, releases, and so on. Each loop exposes the team’s output to empirical feedback so that the team can discover and correct any errors or misconceptions.
One lesson that we’ve learned repeatedly is that nothing forces us to understand a process better than trying to automate it.
Our experience is that, when code is difficult to test, the most likely cause is that our design needs improving. The same structure that makes the code difficult to test now will make it difficult to change in the future.
When composing objects into a new type, we want the new type to exhibit simpler behavior than all of its component parts considered together. The composite object’s API must hide the existence of its component parts and the interactions between them, and expose a simpler abstraction to its peers.
In most systems we build, we end up writing a runtime exception called something like Defect (or perhaps StupidProgrammerMistakeException). We throw this when the code reaches a condition that could only be caused by a programming error, rather than a failure in the runtime environment.
By repeatedly fixing local problems in the code, we find we can explore the design safely, never straying more than a few minutes from working code. Usually this is enough to lead us towards a better design, and we can always backtrack and take another path if it doesn’t work out. One way to think of this is the rock climbing rule of “three-point contact.” Trained climbers only move one limb at a time (a hand or a foot), to minimize the risk of falling off. Each move is minimal and safe, but combining enough of them will get you to the top of the route.
July 1, 2010
I think there's a lot of food for thought in this book. Personally, I can remember reading Martin Fowler's Mocks Aren't Stubs some time ago and concluding that I'd be a "classicist."
Some time later, I started working with mocks as a way to isolate unit tests from "slow" dependencies, such as databases, trying to make them run more quickly. I didn't have much success, though, because I was still writing my tests in a classicist style.
This book helped open my eyes to how the "mockist" style really works, and why it can be a good thing. I absolutely recommend it to any programmer who is doing TDD (or writing unit tests), but who still feels like when it comes to being a mockist, they just don't get it.
I also think a great complement to the book is the video of J. B. Rainsberger's presentation Integration Tests Are A Scam.
As a note on how to read the book, I got a bit bogged down in the middle section, with the worked example. I ended up skipping to the final section and came back to the middle after. Reading it like that worked just fine. I also think it could be interesting to alternate chapters of the middle section with those of the final section.
Some time later, I started working with mocks as a way to isolate unit tests from "slow" dependencies, such as databases, trying to make them run more quickly. I didn't have much success, though, because I was still writing my tests in a classicist style.
This book helped open my eyes to how the "mockist" style really works, and why it can be a good thing. I absolutely recommend it to any programmer who is doing TDD (or writing unit tests), but who still feels like when it comes to being a mockist, they just don't get it.
I also think a great complement to the book is the video of J. B. Rainsberger's presentation Integration Tests Are A Scam.
As a note on how to read the book, I got a bit bogged down in the middle section, with the worked example. I ended up skipping to the final section and came back to the middle after. Reading it like that worked just fine. I also think it could be interesting to alternate chapters of the middle section with those of the final section.
January 14, 2014
Do not read this if you don't wanna know that you are writing your tests all wrong!
Introduction is rather slow and uninteresting for someone already testing on day to day basis. Throughout half of the book there is a step by step introduction into the TDD - I did not care that much for this part. Especially in the end it was somehow hard to follow when the code base for the example grows - especially for a non-java programmer.
But the last 100 pages with the examples of how to write more maintainable and readable were the best. I feel like I am writing better test code already ;-)
Introduction is rather slow and uninteresting for someone already testing on day to day basis. Throughout half of the book there is a step by step introduction into the TDD - I did not care that much for this part. Especially in the end it was somehow hard to follow when the code base for the example grows - especially for a non-java programmer.
But the last 100 pages with the examples of how to write more maintainable and readable were the best. I feel like I am writing better test code already ;-)
June 4, 2019
One of best books about software design and TDD and tests in general.
November 16, 2010
A definite must-read for professional developers, this book taught me a lot about incrementally building software that's constantly deployable and maintainable - not only the technical know-how required to do it, but also the mentality needed. Reading the book made me realize that my unit testing skills are woefully lacking in comparison, so I'm grateful that it provides extension tips, tricks, and examples that I can study for improvement. But this book covers much more than unit testing, which is why I plan on referring back to it quite often, as it has forced me to completely reconsider how I approach building software.
October 4, 2014
I didn't know what to expect when I picked up this book. In spite of its excellent reviews I feared it was going to be another redundant addition to the mountain of books harping on the virtues of Test-Driven Development (TDD), without adding anything significant to the standard sermon.
Nothing could be further from the truth.
I read a fair share of technical books, but this book is the only one in years that I immediately began to re-read again after finishing. It is easily one of the most important books on software engineering out there, and is likely to remain so for some time to come.
The authors present what is now known as the London school of TDD, where the correctness of an object is defined by its interactions with its collaborators, not necessarily by its state. Although I had seen mocking frameworks in action before, never had I seen one being used throughout the development of a software project.
Another fascinating idea is the notion of writing an end-to-end test first, before even starting to write unit tests. We have been so thoroughly drilled on the virtues of fast tests, that it doesn't occur to us anymore that it's even possible---even preferable---to exercice the whole system, perhaps in a separate test suite.
But the best part of the book is the sample project used to illuminate these concepts. It consists in writing a desktop application with which a user can automate the process of bidding in online auctions. The graphical part is done with the Swing framework in Java, and the application talks via XMPP to the auction house. The first chapter in the case study is about setting up literally an end-to-end test, i.e. a test (written with JUnit) that will verify if the graphical display matches the XMPP communications.
From there on, the case study proceeds with the implementation of feature after feature, always following the same pattern: write the end-to-end test first, implement the feature with TDD, refactor, repeat.
No book is worth reading if it doesn't change your approach to your existing projects. This one showed me immediately where our current project (an embedded system for energy management) was lacking in terms of testing.
Go read this book, and send me flowers and chocolates.
Nothing could be further from the truth.
I read a fair share of technical books, but this book is the only one in years that I immediately began to re-read again after finishing. It is easily one of the most important books on software engineering out there, and is likely to remain so for some time to come.
The authors present what is now known as the London school of TDD, where the correctness of an object is defined by its interactions with its collaborators, not necessarily by its state. Although I had seen mocking frameworks in action before, never had I seen one being used throughout the development of a software project.
Another fascinating idea is the notion of writing an end-to-end test first, before even starting to write unit tests. We have been so thoroughly drilled on the virtues of fast tests, that it doesn't occur to us anymore that it's even possible---even preferable---to exercice the whole system, perhaps in a separate test suite.
But the best part of the book is the sample project used to illuminate these concepts. It consists in writing a desktop application with which a user can automate the process of bidding in online auctions. The graphical part is done with the Swing framework in Java, and the application talks via XMPP to the auction house. The first chapter in the case study is about setting up literally an end-to-end test, i.e. a test (written with JUnit) that will verify if the graphical display matches the XMPP communications.
From there on, the case study proceeds with the implementation of feature after feature, always following the same pattern: write the end-to-end test first, implement the feature with TDD, refactor, repeat.
No book is worth reading if it doesn't change your approach to your existing projects. This one showed me immediately where our current project (an embedded system for energy management) was lacking in terms of testing.
Go read this book, and send me flowers and chocolates.
May 22, 2018
Even if the book describes some OO concepts, in order to get the most out of it I suggest reading a couple of OO related books beforehand and get a good grasp of things like encapsulation, polymorphism and specially objects collaboration. As the authors state it: one of their main focus when constructing OO software is to think about how objects will send messages to each other rather than their roles, in other words, drive the design from how the moving pieces would collaborate with each other.
In my case I just read:
- Refactoring [Martin Fowler]
- Designing Object-Oriented Software [Rebecca Wirfs-Brock]
It's also recommended to read a few of the books from "The Addison-Wesley Signature Series". Apart from having a similar structure, it feels like each one builds on top of the others which makes them easier to follow along after you've gone through a few of them.
From the book: we spend much more time reading code than writing, so we should optimise for that, writing tests it's a great way of having a coherent up-to-date documentation of the system.
Unit testing doesn't impact much of the external quality of the code (from the user's perspective), it impacts the internal quality (from the developer's perspective), which in terms determines how easy it is for the code to be extended and bugs to be fixed.
Use the builder pattern to not burry tests intentions in setup calls and improve readability.
Don't strive for testing individual functions but rather your expected behaviour, start each feature by writing an acceptance test, then write unit tests while you incrementally implement the feature, usually the acceptance test will be the last to pass, this can be an end-to-end test if possible but it can also be less than that, any type of test that you think satisfies the definition of done.
In my case I just read:
- Refactoring [Martin Fowler]
- Designing Object-Oriented Software [Rebecca Wirfs-Brock]
It's also recommended to read a few of the books from "The Addison-Wesley Signature Series". Apart from having a similar structure, it feels like each one builds on top of the others which makes them easier to follow along after you've gone through a few of them.
From the book: we spend much more time reading code than writing, so we should optimise for that, writing tests it's a great way of having a coherent up-to-date documentation of the system.
Unit testing doesn't impact much of the external quality of the code (from the user's perspective), it impacts the internal quality (from the developer's perspective), which in terms determines how easy it is for the code to be extended and bugs to be fixed.
Use the builder pattern to not burry tests intentions in setup calls and improve readability.
Don't strive for testing individual functions but rather your expected behaviour, start each feature by writing an acceptance test, then write unit tests while you incrementally implement the feature, usually the acceptance test will be the last to pass, this can be an end-to-end test if possible but it can also be less than that, any type of test that you think satisfies the definition of done.
June 20, 2011
The person who handed me this book said it was "better than Lasse's book" (Test Driven.) I disagree. One can't compare the two books - Test Driven is meant for beginners and this book is meant for an advanced audience. If you have never written unit tests before, this book is very hard to follow. So put it down, get an intro book and come back.
I really liked the emphasis on making the software responsive to change along with separating acceptance and unit tests. The book uses Junit 4.6 and therefore covers Hamcrest matchers for both JUnit and JMock. I like the authors cover best practices, good design and clearly indicate what is a personal preference. I really liked part 4's emphasis on things that are hard to test at a higher level than "extract method."
The only thing that prevents me from giving full marks, is the case study. While I did read this part in one sitting, it was still hard to follow. There was a lot of information to keep in mind while trying to focus on the lessons of the example. I also think it was admirable for the authors to use a Swing example since Swing is harder to test. However, Swing is also less common for Java developers to use actively adding another block to understanding the software growing/testing aspects. And it is even harder for non-Java developers who are in the target audience for the book.
Except for the case study, I thought the book was amazing. And I'm sure the case study is a matter of taste.
---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.
I really liked the emphasis on making the software responsive to change along with separating acceptance and unit tests. The book uses Junit 4.6 and therefore covers Hamcrest matchers for both JUnit and JMock. I like the authors cover best practices, good design and clearly indicate what is a personal preference. I really liked part 4's emphasis on things that are hard to test at a higher level than "extract method."
The only thing that prevents me from giving full marks, is the case study. While I did read this part in one sitting, it was still hard to follow. There was a lot of information to keep in mind while trying to focus on the lessons of the example. I also think it was admirable for the authors to use a Swing example since Swing is harder to test. However, Swing is also less common for Java developers to use actively adding another block to understanding the software growing/testing aspects. And it is even harder for non-Java developers who are in the target audience for the book.
Except for the case study, I thought the book was amazing. And I'm sure the case study is a matter of taste.
---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.
June 24, 2017
A must read for anyone willing to learn and understand how to write concise and maintainable tests, and how to grow a code base in an object oriented fashion. The techniques and principles shown in this book are pure gold: walking skeleton, depth of testing, async code testing, data test builders, mocking, single responsibility, only mock classes you own, hexagonal architecture, etc. If you're still in the fence about the advantages of TDD, this is for you. It displays how quick it is to add new features and make changes with the confidence that you aren't breaking other parts of the system.
However, the only reason I won't rate it a 5 star is that this book study case, which is great if you persevere through its setup and try it out yourself, takes time to understand the techniques they are using. If you try the code it won't compile sometimes, there will be missing code and setting up the server is tricky (you can checkout my GitHub project which have a README to help you out on this https://github.com/vrcca/auction-sniper). Nevertheless, I must say that writing it myself helped a lot! It's way easier to understand the project navigating the code through an IDE than a book.
To sum up, this is an amazing book for the beginner and the experienced. It may take some time and TDD experience to swallow it, but it's totally worth it.
However, the only reason I won't rate it a 5 star is that this book study case, which is great if you persevere through its setup and try it out yourself, takes time to understand the techniques they are using. If you try the code it won't compile sometimes, there will be missing code and setting up the server is tricky (you can checkout my GitHub project which have a README to help you out on this https://github.com/vrcca/auction-sniper). Nevertheless, I must say that writing it myself helped a lot! It's way easier to understand the project navigating the code through an IDE than a book.
To sum up, this is an amazing book for the beginner and the experienced. It may take some time and TDD experience to swallow it, but it's totally worth it.
February 3, 2013
It took me too long to finish the book. First part was quit interesting and promising. I enjoyed reading stories from the author's practice as consultants trying to adopt TDD and unit-testing doctrine in real life. It was interesting to read their props and cons particularly because I have seen myself in the same role at my daily job. I have seen or wished to see. So I tried to learn new tricks to convince colleagues and managers to accept unit-testing as necessary part of the development process.
But as soon as I reached actual examples I have lost my interest in reading. I found basic examples are already obvious to me. More complicated examples over explained and sometimes too difficult to follow the code over and over again. Since authors tried to show step by step code transformations it leads to the several blocks of code which are almost the same except minor details. To see the difference one would need to proceed reading for the explanation and then go back to the code or scan the code line by line interrupting reading.
Last two chapter that were mostly about discussing integration testing and "advanced topics" helped me to finally finish the book.
Overall I would recommend this book to anyone who is interested in the art of unit-testing in the first place.
But as soon as I reached actual examples I have lost my interest in reading. I found basic examples are already obvious to me. More complicated examples over explained and sometimes too difficult to follow the code over and over again. Since authors tried to show step by step code transformations it leads to the several blocks of code which are almost the same except minor details. To see the difference one would need to proceed reading for the explanation and then go back to the code or scan the code line by line interrupting reading.
Last two chapter that were mostly about discussing integration testing and "advanced topics" helped me to finally finish the book.
Overall I would recommend this book to anyone who is interested in the art of unit-testing in the first place.
July 13, 2016
Before reading this book, it would be wise to set your worldly affairs in order and prepare your psyche for a transformation which may move you in entirely new and unanticipated directions. Not only does GOOS offer a collection of solid practices for any software engineer to follow, it also describes a mechanism for design through disciplined planning and execution. Many have scribbled on the topic of software development, but the Venn diagram between recorded wisdom and the art of software design is sparsely populated. Growing Object-Oriented Software, Guided by tests resides within that prestigious union.
May 28, 2011
It started a bit slow so I was concerned, but it really kicked off. Wish I'd read this 4 years ago. The guided walkthrough is good but as with clean code would have been better as a screencast. The final chapters on testing are spectacular.
Key takeaways:
- Focus on the communication between objects.
- Ports and adapters architecture to separate the domain.
- Proper division between unit, integration and acceptance tests.
- Use test builders for complex test setup.
- Transactional tests are a hack because you can't do proper unit tests with rails. Commit is important!
Key takeaways:
- Focus on the communication between objects.
- Ports and adapters architecture to separate the domain.
- Proper division between unit, integration and acceptance tests.
- Use test builders for complex test setup.
- Transactional tests are a hack because you can't do proper unit tests with rails. Commit is important!
January 5, 2023
There's some good and solid advice in this book, but there are also opinions in there that can have a devastating effect on the TDD approach of software teams as whole. Read this book with the necessary caution.
Shelved as 'dnf'
October 28, 2019I hope to come back to this one at a later time.
February 1, 2018
OK... so now I understand why this book became so popular :-)
It's that kind of book that I feel I should reread immediately after finishing it.
The part with the worked example is great, but personally I found specially interesting the chapters with insights about OOP design and sustainable TDD.
The ideal way to get all the value of this book is to write yourself the worked code as they are doing it. If you don't do it, at least take a look to the code here http://www.growing-object-oriented-so...
To be honest, I didn't grab everything they explain. And after finishing, the imposter syndrome is devastating me: I think I know nothing 0_o '
But it was definitely worthy and I'm sure it has helped me to become a better developer :-)
It's that kind of book that I feel I should reread immediately after finishing it.
The part with the worked example is great, but personally I found specially interesting the chapters with insights about OOP design and sustainable TDD.
The ideal way to get all the value of this book is to write yourself the worked code as they are doing it. If you don't do it, at least take a look to the code here http://www.growing-object-oriented-so...
To be honest, I didn't grab everything they explain. And after finishing, the imposter syndrome is devastating me: I think I know nothing 0_o '
But it was definitely worthy and I'm sure it has helped me to become a better developer :-)
February 3, 2020
This book is truly amazing, I have learned a lot of things about: what types to mock, how to write my tests properly, test driven development, UI testing and other things.
The only downside is that this book uses Java and I'm not experienced with it, reading Chapter 3 was hard and not very rewarding.
The only downside is that this book uses Java and I'm not experienced with it, reading Chapter 3 was hard and not very rewarding.
June 18, 2020
Great book. I wish more people would follow the advice from this book.
May 5, 2011
Nejlepší kniha o testování (Unit testy, Integrační testy, Akceptační testy), kterou jsem četl. Autoři-praktici precizně popisují svůj přístup k vývoji a testování aplikací a nevyhýbají se na konci knihy ani doporučením, jak psát složitější testy, které zohledňují existenci více nezávislých threadů v aplikaci, nebo jak si poradit s testy, které testují metody závislé na aktuálním datu a čase, a nechybí ani příklady testů, které musí ověřit výsledek volání asynchronní operace.
Ke knize bych měl jen pár výhrad:
1) Praktické příklady jsou v knihách vždy užitečné, ale prostřední část s hutnými výpisy kódu, které demonstrují, jak napsat a hlavně otestovat aplikaci komunikující s aukčním serverem, je po chvíli úmorná. Při čtení této kapitoly jsem si říkal, že platí: 10x zopakovat variaci na pravidlo Red-Green-Refactor je asi poznávací znamení každého opravdového agilního vývojáře. Něco jako profylaktické pokřižování zahánějící ďábla, který refaktorizací svého stávajícího aplikačního pekla pyšně pohrdl. :)
2) V titulu knihy není zmínka o tom, že všechny příklady budou v Javě a s využitím Java knihoven(JMock). Při čtení příkladů mě rušilo, že jsem se soustředil podvědomě na to, jak některé konstrukce v Javě a také API Java knihoven působí při přímém srovnání se současnými výrazovými prostředky jazyka C# archaicky. Dokonce bych řekl, že v některých příkladech maji (IMHO) metody v JMocku lehkou pachuť hacku.
3) Některá pravidla pro psaní kódu v první části knihy na mě působila rozpačitě nebo neúplně. Například rozdělení spolupracujících objektů na "dependencies", "notifications" a "adjustments" v kontextu knihy (a DI kontajnerů) dává smysl, ale mně třeba hranice mezi dependencies a adjustments přijdou neostré a u notifications tuším, že autoři jsou hodně závislí na notifikacích ve specifické formě "Java" listenerů.
Kniha ale i přes tyto drobné výhrady za přečtení určitě stojí.
Ke knize bych měl jen pár výhrad:
1) Praktické příklady jsou v knihách vždy užitečné, ale prostřední část s hutnými výpisy kódu, které demonstrují, jak napsat a hlavně otestovat aplikaci komunikující s aukčním serverem, je po chvíli úmorná. Při čtení této kapitoly jsem si říkal, že platí: 10x zopakovat variaci na pravidlo Red-Green-Refactor je asi poznávací znamení každého opravdového agilního vývojáře. Něco jako profylaktické pokřižování zahánějící ďábla, který refaktorizací svého stávajícího aplikačního pekla pyšně pohrdl. :)
2) V titulu knihy není zmínka o tom, že všechny příklady budou v Javě a s využitím Java knihoven(JMock). Při čtení příkladů mě rušilo, že jsem se soustředil podvědomě na to, jak některé konstrukce v Javě a také API Java knihoven působí při přímém srovnání se současnými výrazovými prostředky jazyka C# archaicky. Dokonce bych řekl, že v některých příkladech maji (IMHO) metody v JMocku lehkou pachuť hacku.
3) Některá pravidla pro psaní kódu v první části knihy na mě působila rozpačitě nebo neúplně. Například rozdělení spolupracujících objektů na "dependencies", "notifications" a "adjustments" v kontextu knihy (a DI kontajnerů) dává smysl, ale mně třeba hranice mezi dependencies a adjustments přijdou neostré a u notifications tuším, že autoři jsou hodně závislí na notifikacích ve specifické formě "Java" listenerů.
Kniha ale i přes tyto drobné výhrady za přečtení určitě stojí.
July 28, 2013
Pretty cool book. I wish I had it 6 years ago. Learned quite a few of the lessons they talk about the hard way in those years. I really, really like the emphasis on growing and nurturing a software design. I've seen too many codebases that slowly but gradually went off the rail because of too much pragmatism or simply the lack of a big picture on what the software was supposed to do and how it actually did it.
Software teams often don't fail delivering the first version of a software. They fail on the subsequent versions. The ones where requirements are added or changed and coupling problems in the software become visible. It's not problematic to get a design wrong, we all do (and we all will probably continue to do so in the future). Not learning from your new insights though will kill your software in the long run. This book gives you an excellent idea how you can cope with that. Just because of that I would probably alone give this book 5 stars.
If I had to name one new idea I'm going to take from this book with me, then I'd probably go with the importance of the communication patterns between objects. It's such a neat way to explain the 'tell don't ask' principle.
I'm still not 100% convinced whether a classic unit testing framework is the best medium for acceptance testing, though. Especially the camel case names for tests is something I've come to dislike. I would rather prefer something like RSpec (Ruby) or NaturalSpec (FSharp) that let's me express my intent in plain sentences.
Well and that Java JMock syntax. Boy am I glad that I'm working with C# and Ruby :-)
Software teams often don't fail delivering the first version of a software. They fail on the subsequent versions. The ones where requirements are added or changed and coupling problems in the software become visible. It's not problematic to get a design wrong, we all do (and we all will probably continue to do so in the future). Not learning from your new insights though will kill your software in the long run. This book gives you an excellent idea how you can cope with that. Just because of that I would probably alone give this book 5 stars.
If I had to name one new idea I'm going to take from this book with me, then I'd probably go with the importance of the communication patterns between objects. It's such a neat way to explain the 'tell don't ask' principle.
I'm still not 100% convinced whether a classic unit testing framework is the best medium for acceptance testing, though. Especially the camel case names for tests is something I've come to dislike. I would rather prefer something like RSpec (Ruby) or NaturalSpec (FSharp) that let's me express my intent in plain sentences.
Well and that Java JMock syntax. Boy am I glad that I'm working with C# and Ruby :-)
April 2, 2023
As an Engineering Manager, I cannot recommend this book enough. Freeman and Pryce have provided a comprehensive, practical guide to implementing TDD in software projects. The book strikes an excellent balance between theory and practice, with relevant examples and a real-world case study, making it easy for developers to understand and apply the concepts.
The design principles and testing techniques outlined in this book have helped us build more robust, maintainable, and scalable applications, ultimately leading to higher-quality software and increased customer satisfaction. Our team has also experienced increased efficiency and collaboration due to adopting TDD practices.
The design principles and testing techniques outlined in this book have helped us build more robust, maintainable, and scalable applications, ultimately leading to higher-quality software and increased customer satisfaction. Our team has also experienced increased efficiency and collaboration due to adopting TDD practices.
February 15, 2016
A great book on a little bit different approach of testing. Going end-to-end and grow your software one test at a time will result in a much more stable software that most other approaches. The authors know a lot about writing good and useful test-suites and can explain the main things you should look out for.
The only downside in this book is the big focus on a library like jMock. Outside Java you can’t use it and when you program in any other language that part is of no use to you.
The only downside in this book is the big focus on a library like jMock. Outside Java you can’t use it and when you program in any other language that part is of no use to you.
August 22, 2011
Best TDD book and best OO book I ever read. Amazing.
March 30, 2013
This is the best guide to TDD and emergent design I've read. I have two copies, one of which is permanently loaned out to friends and colleagues.
December 7, 2013
While there was a lot to learn and take away you have to overlook the over architecting that took place in the code.
January 12, 2019
I found this to be a tough read, even for a dry topic like this. Its mostly in Java, which is applicable enough to most languages that it’s still accessible even if you program in a different object oriented language.
There are a number of books out there on TDD, but this one is pretty unique out of the ones I’ve read so far in that it includes integration testing of the example, not just unit testing. There’s almost a whole chapter on testing persistence layers, which most books on testing practices wholly ignore.
The “meat” of this book centers around a step-by-step building of an application to handle bidding via an online forum. There are a lot of code examples that are well formatted, and include some bold typeface to emphasize the changes. It seems well thought out, but it’s an example that’s pretty tightly linked to Java libraries (Swing, XMPP libs, etc) and intricacies that it makes me surprised the title doesn’t specifically mention Java.
All in all, I read technical manuals for fun, but I found this a pretty grueling slog. There are definitely some great tips on testing and team TDD in here peppered throughout, but I doubt I’ll be picking this one up again.
There are a number of books out there on TDD, but this one is pretty unique out of the ones I’ve read so far in that it includes integration testing of the example, not just unit testing. There’s almost a whole chapter on testing persistence layers, which most books on testing practices wholly ignore.
The “meat” of this book centers around a step-by-step building of an application to handle bidding via an online forum. There are a lot of code examples that are well formatted, and include some bold typeface to emphasize the changes. It seems well thought out, but it’s an example that’s pretty tightly linked to Java libraries (Swing, XMPP libs, etc) and intricacies that it makes me surprised the title doesn’t specifically mention Java.
All in all, I read technical manuals for fun, but I found this a pretty grueling slog. There are definitely some great tips on testing and team TDD in here peppered throughout, but I doubt I’ll be picking this one up again.
September 4, 2017
This is an amazing book. I've read some classic books about programming but they seems to be more targeted at beginner programmers. They don't offer so much for developers with some experience (even it is useful to read them to remind yourself about industry basics). On the other hand this book is better for advanced programmers. You will know most of described concepts at least from theory but this book shows useful practical usage. The main part of the book is an example of application development. It is not just a simple application but it has swing UI, dependent external services and asynchronous aspects. All those parts which are not easy to test. Authors do a great job with this example application in showing how your design will be guided by tests. I learned a lot. And even if you are not a fan of Test Driven Development which is used in the book you can learn so much about application design and how to structure your code.
April 19, 2022
Good book that really makes you think critically, but so much code that should’ve just been a GitHub link, and repetition throughout. They summarize a lot of the middle chapters in the final section. I skipped most of the “worked example” section and skimmed through the last section in about a half hour. The worked example is just broken up code on multiple pages (on Kindle) that makes it difficult to follow and exhausting to get through. I found a GitHub online with the transcribed code that I’ll probably look through to get a grip on what they were mentioning. I would probably use that section as more of a reference when writing your own tests.
The most valuable part by far to me was the beginning section and the section about multi-threading. I would recommend concentrating on the beginning chapters, skimming through the rest and critically reading what interests / applies to you directly, and using it as a reference.
The most valuable part by far to me was the beginning section and the section about multi-threading. I would recommend concentrating on the beginning chapters, skimming through the rest and critically reading what interests / applies to you directly, and using it as a reference.
Read
December 20, 2022Why AWS in Particular?
As previously stated, the pricing of AWS services is based on the quantity and kind of resources utilised by customers. You might acquire a basic notion of AWS certification advantages by having a look at the abilities given by AWS. Users might leverage AWS's capabilities to design and launch services. AWS's other services also give consumers with the same capabilities.
Cloud-based web and application servers for hosting internal applications and client-facing websites.
All files and sensitive data are securely stored and easily accessible on cloud resources. The ease of access is useful for data backup and disaster recovery purposes.
Create a portfolio of cloud computing including 12 labs, 4 projects, and a capstone project. Enroll Right Now! For AWS Training in Pune, Azure, DevOps, and other services. Get hands-on experience with labs and projects.
As previously stated, the pricing of AWS services is based on the quantity and kind of resources utilised by customers. You might acquire a basic notion of AWS certification advantages by having a look at the abilities given by AWS. Users might leverage AWS's capabilities to design and launch services. AWS's other services also give consumers with the same capabilities.
Cloud-based web and application servers for hosting internal applications and client-facing websites.
All files and sensitive data are securely stored and easily accessible on cloud resources. The ease of access is useful for data backup and disaster recovery purposes.
Create a portfolio of cloud computing including 12 labs, 4 projects, and a capstone project. Enroll Right Now! For AWS Training in Pune, Azure, DevOps, and other services. Get hands-on experience with labs and projects.
October 4, 2017
An absolutely wonderful book on TDD. Really explains the process of writing tests before features both technically and pratically.
In the middle of the book the authors develop a Auction Sniper application using Swing using the TDD method and bring the reader through the TDD process every step of the way which is a brilliant idea for a technical book as it explains the concept very well.
Don't let the fact that it's a swing app deter you however as this could easily be a web framework or some other third party ui framework instead, showing how you can test and design with those kind of dependencies.
The book relys on the JMock2 framework which isn't too far from mockito if your more familar with that.
Really recommended, especially as a companion to Clean Code or Working effectively with Legacy Code.
In the middle of the book the authors develop a Auction Sniper application using Swing using the TDD method and bring the reader through the TDD process every step of the way which is a brilliant idea for a technical book as it explains the concept very well.
Don't let the fact that it's a swing app deter you however as this could easily be a web framework or some other third party ui framework instead, showing how you can test and design with those kind of dependencies.
The book relys on the JMock2 framework which isn't too far from mockito if your more familar with that.
Really recommended, especially as a companion to Clean Code or Working effectively with Legacy Code.
July 20, 2020
I am really disappointed by this book (especially after reading TDD by Example from Kent Beck).
There are some typical good advices around Object Oriented Programming (some of them directly coming from DDD) and the book goes very deep on the example it uses to explain their "Outside In" method.
But I have, personnaly, two big issues:
- on the book itself, the focus on the example, the code and the "how" make it hard to understand the why and not to be lost in the details
- on the approach proposed, I am not really sure that the advice to use full integration tests and so much mocking with each class in isolation is the best way to do TDD. In fact, this style have brought many critism.
In the end, it's not a bad book but it's more for advanced practicionners who want a deep dive into the extreme TDD Mockist way.
There are some typical good advices around Object Oriented Programming (some of them directly coming from DDD) and the book goes very deep on the example it uses to explain their "Outside In" method.
But I have, personnaly, two big issues:
- on the book itself, the focus on the example, the code and the "how" make it hard to understand the why and not to be lost in the details
- on the approach proposed, I am not really sure that the advice to use full integration tests and so much mocking with each class in isolation is the best way to do TDD. In fact, this style have brought many critism.
In the end, it's not a bad book but it's more for advanced practicionners who want a deep dive into the extreme TDD Mockist way.
Displaying 1 - 30 of 134 reviews