unpopular Ruby/Rails opinions: "better object decomposition" is not necessarily related to test speed. In fact, many test-speed-optimizing design patterns have damaged our ability to write good OO Ruby as a community.
We optimize for test speed because slow tests are measurable, annoying, disruptive to our ability to socialize TDD as a practice, and much easier to fix than engaging with the subjective complexities of object-oriented design.
We conflate test speed and OO to rationalize this.
We conflate test speed and OO to rationalize this.
But optimizing for test speed, *even when you are not using test doubles to do so,* near-inevitably means premature creation of object boundaries to isolate "slow" or "hard to control" things, *even when* the subject under test might logically encompass those.
There's no point in testing ActiveRecord scopes, operations that lean on AR associations, operations that involve database-level validations (including DB-level uniqueness checks), etc without persisting real records -- because the SUT encompasses the database.
The Rails community has decided to throw five million and three new letters into MVC as a way of slicing "responsibilities" off of models. But because we've been prioritizing *test speed* over *clarity* in doing so, we've often picked the wrong responsibilities to slice off.
We create arbitrary rules about what logic is "presentational" or "workflow" or the like so that we can reduce model LoC, and increase the number of tests that can be run purely in-memory. A knee-jerk separation of workflow into "pure functions" is easier than domain modeling.
We call these arbitrary rules "abstraction" and then say that developers who haven't internalized them are "bad at abstraction." But maybe those developers aren't wrong; maybe the rules are bad.
Perhaps because they emerged from test speed optimization rather than domain logic.
Perhaps because they emerged from test speed optimization rather than domain logic.
What does object decomposition that doesn't derive from test speed optimization look like?
I don't know. Yet. I think it involves a lot of leaning on "classical" Ruby, the parts that are unfashionable now.
I'm looking forward to experimenting though. Who's with me?
I don't know. Yet. I think it involves a lot of leaning on "classical" Ruby, the parts that are unfashionable now.
I'm looking forward to experimenting though. Who's with me?
