Why We’re Sticking with Ruby on Rails at Gitlab

Re:Why We’re Sticking with Ruby on Rails at Gitlab by piperswe on Monday June 13, 2022 @03:13PM (#31730235)

The idea is that you write one set of fixtures for the whole app that you then use in all tests. You'd have a valid company and a valid user in your fixtures, but that's fine because you probably want to test both the company and user models. In the user model tests, you can ignore the existence of the company fixtures, and vice versa.

Since the inserts only happen once for the whole test suite, the marginal cost of adding more fixtures is minimal, so it makes sense to just make the fixtures as complete as possible.

[ Parent | on HN ]

Re:Why We’re Sticking with Ruby on Rails at Gitlab by itake on Monday June 13, 2022 @03:16PM (#31730301)

interesting. I haven't used fixtures before. Wouldn't this make individual tests slow (like in development?) since all fixtures must be inserted all the time?

[ Parent | on HN ]

Re:Why We’re Sticking with Ruby on Rails at Gitlab by matthew-puku on Monday June 13, 2022 @08:58PM (#31733593)

It doesn't add as much overhead as you might expect because the fixture data is inserted into the database without instantiating any ActiveRecord models. Unless you're loading a truly crazy amount of fixtures (gigabytes?), the database can ingest all the data in single-digit milliseconds.

[ Parent | on HN ]