Growing Object-Oriented Software, Guided by Tests
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 maintai ...more
* 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 m ...more
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 ...more
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 import ...more
- 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 bec ...more
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.. ...more
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.
I did not realize how much I still have to learn about writing good object-oriented (OO) code, and about hewing to a tight test driven development (TDD) methodology, before I read Growing Object-Oriented Software, Guided By Tests. My education in OO and unit testing has been largely theoretical, with no time spent directly learning from experienced OO programmers; my best mentor was a COBOL coder. Books like Design Patterns: Elements of Reusable Object-Oriented Software, Patterns of Enterprise A...more
Software teams often don't fail delivering the first version of a software. They fail ...more
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 ther ...more
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.
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 pract ...more
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 othe ...more
I concur I am not sold on Mocks as a golden hammer to drive the design and building blocks to Test Suites. In my practice - Mocks are something dreadful and better to be avoided by means of simpler tools (e.g. FakeRepository (in-memory database) over _mocked_ Repository).
I particularly liked the _practical bit_ it, e.g. 2/3 of the book materials are acco ...more
Interesting short end chapter about the history of mocking, Jmock, and Hamcrest. I didn't know that the authors of the book are creators of the mentioned tools. Although there are n ...more
I’m giving 4 stars because at the time written was probably the best material on the topic. However, I think that now, there is better material about when to mock, testing schools, trade-offs, etc. I even disagree with some parts, such as starting with the end-to-end tests. I prefer to start to start with the Use Case (Interactors or Appl ...more
Goodreads is hiring!
Learn more »