Hacker News Reader

Comment by s4i | Hacker News Reader

In my last job I encountered my first Ruby/Rails codebase ever (mostly REST APIs but a few server-rendered views as well). Despite the initial chaotic impression of the codebase (it was a startup after all) with all the Rails magic on top, I really fell in love with the framework after a more experienced Rails dev introduced a few key conventions and helpful libraries to the codebase.

Out of those, I’d at least add the RuboCop [1] linter and the BetterSpecs [2] guidelines to this list. Both eliminated bikeshedding in the team and freed up brainpower to solve actual problems: the first one helps you learn intricacies of Ruby bit by bit right in the IDE and the latter one pushes you to write test in a specific style that’s easy to maintain and trust.

[1] https://github.com/rubocop/rubocop

[2] https://www.betterspecs.org/

View on HN

I am blown away by the suggestion to use factories over fixtures.

Factories are almost 100% responsible for excruciatingly slow test runs, since you have to rebuild the world every single test. Fixtures work perfectly fine and only need to be created once at the beginning of your test run.

For that matter, rspec itself is also a thoroughly unnecessary cargo-culted dependency when Ruby and Rails already bundle perfectly-serviceable, simple test frameworks.

Good luck with those very brittle specs. I have fixed so very many utterly broken tests due to poor spec maintenance mainly due to really poor fixtures. The problem with fixtures is that they do not complain when things go sideways whereas factories are built on top of actual living objects and thus can be validated.

You're generally trading speed for correctness in my experience. There is a time and place, of course, for this tradeoff, but we know how to parallelize specs and make test, in general, faster. Correctness is a whole different story.

If this is a problem for you, you can literally write one test which will round-trip your fixtures through a load and validate loop.

If the number of teams developing on your monolith continue to grow, both you and parent will eventually come to the realization that there’s not a good fix for this in Rails. You’ll re-write your monolith into something that scales much better with organizational growth.

Using factories doesn't mean you need to persist everything to the DB on every test.

If you're using FactoryBot for example, you can use `build(:taco)` to instantiate a Taco without persisting it to the DB. If you use `create(:taco)` instead, then yes, the Taco will be saved to the DB, as well as all its associations (if any). This can of course bloat up your test execution time if you're doing this kind of instantiation + persistence on every test.

FactoryBot docs generally use `build` in their examples, as this should be the default build strategy used for most tests, while `create` should only be used on cases where you actually need to interact with the DB.

I love ruby having used it since before Rails, but it seems weirdly susceptible to the "with great power comes great responsibility" issue. Dynamically typed + the "don't disallow stupid things or you'll disallow clever things" mentality, maybe? Early adopters like _why who could actually handle it having a huge influence? Dunno.

I've worked with some devs who were not old battle-scarred greybeards who jumped on EVERY rspec feature because they were there and in a misguided attempt to DRY their test code well beyond reasonable limits.

So I feel you here.

But FactoryBot does allow fixture-like speeds with in-memory .build()'ing. Too few people use it, and too few have succumbed to a preponderance of tests being full-on integration style.

Ruby (and Rails, and rspec) all IMO require a lot more good guidance and wisdom on what NOT to use than other ecosystems I've used.

> For that matter, rspec itself is also a thoroughly unnecessary cargo-culted dependency when Ruby and Rails already bundle perfectly-serviceable, simple test frameworks

I think people developing professionally and working with large code bases, reach pretty fast all the limitations of minitest. IMO, Minitest is great to test small libs, but as soon as you need to refactor a lot of specs or use other stuff like Factories, then rspec is the tool. No cargo-culted. It is just the best and more complete option.

I have worked professionally with Rails since just after 1.0, on applications of every size.

The number of cases where applications sanely used features of rspec that couldn’t have been done equivalently and just as easily (and significantly less confusingly) with minitest-based tests are few and far between. And these are easily outnumbered 20:1 by insanely bad test suites that abuse rspec and thoroughly mock everything in their tests, resulting in tests that a) are so brittle they fail on any non-trivial refactor, and b) couldn’t possibly preemptively catch buggy behavior.

I have quite literally never worked on a Rails application that used minitest and which was forced to abandon it due to unmet needs.

I too now prefer fixtures. Such a joy to work with them.

Reply on news.ycombinator.com