No Need to Be Too Serious on TDD
Architecture the Lost Years It sounds reasonable to have your core business rules in a gem, and rails and database as plugins around it. However, I would argument that it’s possibly the result of evolution of a well design system, not something one starts with from scratch, because people don’t know what they want until they see it. Another interesting point is that one guy from the audience asked for an example of using the advocated architecture, but the presenter has only one, and can’t disclose it.
The feasibility of this ideal architecture is questioned, to some extent, in this presentation as well, Decoupling from Rails. However, decoupling shown in the presentation makes the code less transparent, even though it improved the testing speed. Therefore, I believe the way out for slow testing using rails is to mock rails and database, which is something that could and should be done on the framework level, so that developers could focus on building apps using rails, not worrying the slowness of tests.
In RailsConf 2014 - Keynote_ Writing Software by David Heinemeier Hansson, the presenter argues that readability is more desirable than testability even though the former can’t be objectively measured. Design driven by TDD may render a quite testable system, but its readability is unspecified, and TDD advocates usually ignore its existence. Personally, I mostly agree with the presenter that good design comes from experience, not following magical tips blindly.
In summary, tests are important, for they give developers confidence during refactoring, but that’s all. They are not the panacea, and they can definitely not guarantee a good design. No need to feel guilty of breaking the three rules in TDD.