Comments by "George Helyar" (@georgehelyar) on "Are You Chicago Or London When It Comes To TDD?" video.

  1. ​ @robocodeboy  You're not willing to pay the price of having a good design? It's kind of the point of TDD. When your code is difficult to test, it means your design is bad, so TDD done properly leads you towards a good design. This isn't overengineering, or layers of unnecessary abstraction, it's just basic design principals, following things like SOLID. I'm not suggesting leaky abstractions, I'm suggesting the exact opposite of that. Keep the implementation hidden away, and don't expose it through your abstractions. How you query your data matters, but the abstraction is the point where you hide that away, so that the caller only cares about the business logic, not the queries it took to implement it. Your abstraction may have domain concepts like "add inventory" to a warehouse, while the implementation deals in details like "execute stored procedure" or "update ORM" or "publish event to message broker" or "call external web service". That particular implementation might not take a lot of code to write, but the translation from domain logic to a particular implementation is what matters. If your abstraction is dealing in individual queries with no translation to domain logic, and the caller sometimes has to execute multiple queries to get things done, that's when your implementation is leaking into your abstraction.
    2
  2. Imagine that you want to change the implementation of how you persist your data. For example, you want to switch from a RDBMS to NoSQL. Write an abstraction that does not expose the underlying implementation, so the caller does not know or care how it is stored at all. This is now a useful part of the design, and not just an artificial mocking point for the sake of not hitting a database in a test. The abstraction should only expose concepts from the domain, not concepts of the storage. From the video, the Warehouse class could be an example of this. Now you can choose whether to mock out that abstraction when testing the caller. You can still test the real calls against the database, but these are integration tests that you can perform at a higher level. The database is not really any different to an external web service, for example, so you can test it in the same way.
    1