Ruby Tests Profiling Toolbox VS packwerk

gem "test-prof" - https://github.com/test-prof/test-prof | Toolkit for inspecting and optimising your test-suite, a must-have.

You might be able to do something with https://test-prof.evilmartians.io, but I'm not sure it has anything specific to fixtures out of the box. Maybe using the event profiler on sql.active_record events would be close enough. In the limit, you could wire together your own ActiveSupport::Notifications.instrument around the relevant blocks + an ActiveSupport::Notifications.subscribe to that event so as to log the relevant information. Docs: https://api.rubyonrails.org/classes/ActiveSupport/Notifications.html

To have a better vision of what objects are created in our spec file we can use test-prof, a powerful gem that provides a collection of different tools to analyse your test suite performance. One of this tool is really useful to identify a factory cascade, let’s introduce factory profiler.

TestProf can be used to get flamegraphs for Ruby test suites.

Rspec has spec_helper.rb.

I also love the test-prof documentation, there's a lot of good ideas on how to improve test performance.

gem "packwerk" - https://github.com/Shopify/packwerk | Allows modularising Ruby code, a must-have for growing projects.

Yep, that article is about very similar concepts but grounded in Spring as the framework.

I like what they do around package imports and it looks a lot like what we do at incident.io, with some rules about which packages can import what.

For people in the Ruby world who want a similar solution, Shopify provide an open-source framework called packwerk that is designed just for this:

https://github.com/Shopify/packwerk

I’d probably go with packwerk before rails engines these days

https://github.com/Shopify/packwerk allows you to make dependencies between components explicit

Packwerk – to enforce boundaries and modularize Rails applications

Take a look at Packwerk from some folks at Shopify - gets you the benefits of naming some components for organizing boundaries in your code, with each component having the usual rails folder structure, but without the hard isolation restrictions of doing so with Engines.

Nothing is stopping you from doing so except you (and maybe packwerk, but you very likely don't have that installed).

For me, the most important aspect of a growing Rails app is handling of complexity and interdependencies and turns out Shopify's packwerk is just what the doctor ordered - it leverages zeitwerk loader to improve on Rails' vanilla file structure, allowing to group files by business concept or sub-domain and control visibility and ownership.

Let's set the stage right quick. You happen to be in a large Rails application that follows along with something like Packwerk to clearly delineate different packages in your Rails monolith. Let's say you have 100 packs, which is not particularly unusual with larger applications.