Skip to main content
Bastien Chanez
FR

Reading & resources

The books, articles and talks that shape how I code, with my key takeaways.

I list here the resources I read and watch from August 2026 onward, with my own summary. I didn't track my reading before, so I'm making myself re-read and re-watch, and this page grows over time.

  • BookCurrently reading

    Modern C++ Programming with Test-Driven Development

    Jeff Langr · 2013

    My takeaway : Currently reading. How to practise TDD concretely in modern C++: the red-green-refactor rhythm, test-driven design and dependency management in a compiled language. Summary and key points to come once I finish the book.

    • TDD
    • Tests
    • C++
    • Craft
  • BookCurrently reading

    Growing Object-Oriented Software, Guided by Tests

    Steve Freeman & Nat Pryce · 2009

    My takeaway : Currently reading. The reference on “outside-in” TDD and using mocks to let the design emerge: start from end-to-end tests, listen to what the tests tell you about coupling, and grow the object-oriented design cycle after cycle. Summary and key points to come once I finish the book.

    • TDD
    • Tests
    • Mocks
    • Design
    • Craft
  • Video

    TDD, Where Did It All Go Wrong

    Ian Cooper — DevTernity 2017 · 2017 · ~1h

    My takeaway : Test behaviours, not classes. “One test class per production class”, with a mock per dependency, builds a harness that blocks all refactoring — the opposite of what TDD promised. A test is triggered by a requirement, never by creating a class. The answer was already in Kent Beck’s book (2003); we had just misread it.

    Key points

    • The “unit” in unit test is the test’s isolation, not the class: a test can span several classes.
    • RED-GREEN-REFACTOR: go green “dirty” (as fast as possible); refactoring is the non-negotiable step.
    • Never couple tests to classes extracted during refactoring — otherwise any change breaks everything.
    • Over-mocking couples tests to the current design. Test at the “port” (hexagonal), not internal details.
    • TDD
    • Tests
    • Craft
  • Article

    The Little Mocker

    Robert C. Martin (Uncle Bob) · 2014

    My takeaway : A dialogue that finally nails the vocabulary of test doubles. Not everything is a mock: Dummy, Stub, Spy, Mock and Fake are five distinct objects, each built on the previous one. Only the Mock verifies behaviour (it knows what’s expected of it and fails the test itself); the Fake actually has business logic. Knowing which one you use is how you stop over-mocking.

    Key points

    • Dummy: an object passed around but never used, just to fill a parameter list.
    • Stub: returns canned answers to steer the test down a path.
    • Spy: a stub that also records how it was called (how many times, with what).
    • Mock: a spy that knows the expectations and passes/fails the test itself. The Fake, apart, carries real logic (e.g. an in-memory database).
    • Tests
    • Mocks
    • TDD
  • Article

    Solid Relevance

    Robert C. Martin (Uncle Bob) · 2020

    My takeaway : A reply to those who call SOLID “outdated”. The principles are not about a language, a framework, or even objects: they describe how to group functions and data into modules and manage the dependencies between them. As long as we write software that must change without breaking, they stay relevant. Calling them obsolete confuses the principles with some dated implementation.

    Key points

    • SOLID lives at the mid-level of design: the structure of modules, not the syntax.
    • The principles are independent of paradigm and language — they are not OO-only.
    • Software’s real problem — controlling dependencies so change is safe — hasn’t changed.
    • “SOLID is no longer relevant” almost always means confusing the principle with a specific tool or technology.
    • SOLID
    • Design
    • Architecture
  • Article

    NODB

    Robert C. Martin (Uncle Bob) · 2012

    My takeaway : The database is not the heart of your application: it’s a detail, a plugin you plug in late. Business rules must know nothing about SQL, tables or the ORM — they work with objects. Keeping the database “outside” lets you choose it (or swap it) as late as possible, and test the domain without it. The schema is not the architecture.

    Key points

    • The database is an implementation detail, not the centre of the system — defer the decision.
    • The domain depends on abstractions (repository interfaces), never on the DBMS or the ORM.
    • A domain testable without a database: tests run fast, with no I/O.
    • You keep the freedom to swap storage as long as the contract stays stable.
    • Architecture
    • Database
    • Design