Kindle Notes & Highlights
If your spec is failing because of a bug in a dependency, mark it with pending and the ticket ID from their bug tracker; for example, pending ’waiting for a fix for Hitchhiker’s Guide bug #42’. When you later update to a version containing the fix, RSpec will tell you.
If you write your specs before your implementation, you’ll be your own first client. You’ll get a feel for what it’s like to use the interfaces you’re building.
As counterintuitive as it may sound, one of the purposes of writing specs is to cause pain—or rather, to make poorly designed code painful. By surfacing the pain of a design problem early, specs allow you to fix it while it’s cheap and easy to do so.
Finally, driving your design from your specs is fun! Tackling a big problem all at once is hard and tends to give us a bad case of “programmer’s block.” TDD encourages us to break things down into small, achievable steps. It’s almost like a game: First, we come up with an example exposing a behavior the code doesn’t yet implement. Then, we implement the behavior to make the specs pass. It’s a constant stream of satisfaction.
Every behavior you specify in a test is another point of coupling between your tests and your project code. That means you’ll have one more thing you’ll have to fix if you ever need to change your implementation’s behavior.
the ability to refactor your application logic is extremely valuable. End-to-end acceptance specs provide the best refactoring support. Because they only use your code’s public interfaces, they don’t depend on implementation details.
Acceptance specs’ refactoring support comes at a price. They are more difficult to write, more brittle, and slower than other specs. But they provide so much confidence that it’s important to have them—we just write very few of them, focus on the happy path, and don’t use them for exhaustive coverage of conditional
