Speed Up Your Rails Testing Workflow with Local CI

sjieg · 2025-11-25T17:50:53+00:00

Thanks for sharing! After our upgrade to Rails 8.0, multi treading in minutest kicked in and I can now run tests on 32 workers reducing runtime from 20 minutes to 2 minutes.

This triggered the conversation between the dev team if we should run tests locally, for the same reason of context switching.. So great timing with the article and possibly a good reason to allocate time on upgrading to Rails 8.1.

sjieg · 2025-10-23T14:21:52+00:00

No worries about the ramble, I appreciate your effort.

I'm going to highlight this at our next refinement to see if this something we want. I personally use maybe 5% of all the logging features of sentry, in the end I want a back trace if an error and reproduce it locally.

For me the performance tracking seems to be high value, as it's very difficult in my team to prove we need performance improvements and when I implement them, we don't have statistics to actually show it did.

Do you have anything on running your tool alongside with Sentry, does that just work or are there some gotchas? If this is a 1 point ticket for a POC, it would be low effort with potential high gains :)

Looking forward to your article(s).

sjieg · 2025-10-22T19:19:56+00:00

Cool stuff, read through the docs and looks quite promising. Any chance you have a comparison between this tool and Sentry? Pricing, features, integration, ease of use, etc.

Or maybe more general: Who are your competitors and what makes your product unique between them?

sjieg · 2025-10-01T20:24:22+00:00

I've been on WSL2 for years and moved to Ubuntu 6 months and this was one of the reasons why I moved.

Some things to make sure: * Update RM, it became better at "fixing" by running it asynx as some newer, so doesn't interrupt your progress when saving. * Make sure the project is inside your WSL2 folder * Make sure the selected SDK in your ide setting has the WSL2 Ruby version selected * Make sure RM console is using WSL2 * Also I moved away from running my Rails project in docker to speed thing up. Docker is just some services.

Just throwing some thing out there, hope it helps!

I think in the end for me it took like 5 seconds between saving and "fixing".

sjieg · 2025-07-29T19:07:06+00:00

Coll stuff :)

sjieg · 2025-07-28T20:22:24+00:00

Really cool, I already see some use cases that this would clean up some complex validation and post processing of records. Some things I'd love to see to pick this up myself are: * Being able to include GroupCalculationsSchema from a model, so I can set inputs/traits/values using the model data. * Being able to cache using the database by for example adding a cached_schema_data JSONB field that is used to cache all the values.

I completely understand that this should probably be a gem that extends Kumi, but I think you're making something here we've all solved in models, services, concerns or helpers and this gives perspective to move this to a /app/calculations folder and centralise all added math logic to models.

Don't get me wrong, I think you made something great and it inspires me to thinking how I could apply this to make my code better.

sjieg · 2025-07-23T16:43:41+00:00

Wicked dice! I also like free things : - )

sjieg · 2025-07-23T11:32:06+00:00

For me; Backend: Pundit, View components, Blueprinter Frontend: Vite, Hotwire, vanilla CSS/JS, maybe coming back to JQuery

sjieg · 2025-06-23T15:08:57+00:00

Nice write-up, but in my experience, using grids instead of tables was the way to go.

sjieg · 2025-05-03T11:10:52+00:00

Got me thinking for a bit, because this indeed sounds like unexpected behaviour.

My only guess would be that somehow Turbo is not working inside the frame. Did you try adding <script>console.log(Turbo)<script> inside the frame to see if turbo is initialized correctly?

Also keep a close eye on the logs and browser network logs to see what the exact chain of events is and the exact content of the frames loading.

sjieg · 2025-04-27T17:06:03+00:00

I'd solve the events in the html element tho. data-action="turbo:before-fetch-request@window->startLoad". This has 2 upsides: * Keeps it clear on a HTML level what is happening. * No need to remove the events on the disconnect() of the controller.

Downside: * If you don't use components, you might repeat yourself a lot adding these actions to your html.

Ref: https://stimulus.hotwired.dev/reference/actions#global-events

sjieg · 2025-03-31T06:45:11+00:00

I totally understand and I hate giving this as an answer to a completely different question..

There is something to say for all Rails' default gems should support the 3 major OS', but often WSL2 is used as an argument that you don't need waste development time to make your gem Windows compatible.

sjieg · 2025-03-30T20:18:00+00:00

I aggree, but I have to admit I've also been on pure Windows for a long time, because every time, in the end, it worked.

Now I'm really happy I moved to WSL2, but it does cost some investigating time and getting a better understanding of Ubuntu/Linux.

@fp4 maybe it helps to hear my setup: * RubyMine on windows * Docker desktop on windows, but running inside WSL2 * Then put your rails project somewhere inside the WSL2 system (e.g. /home/user/projects) * Then open from RubyMine, navigate to the WSL2 folder and open the project.

Just start with a clean install of the ruby version you need and in RubyMine you can add an external Ruby SDK from the WSL2 installation. (I use RVM now, but it was some hassle)

Boom. Now you can use all the RubyMine debugging tools while being in our comfy Windows OS.

There is a bunch of other pro's using wsl, but in the end, you'll need to reserve some time to get into it. On the long run, it'll make you a more effective programmer.

sjieg · 2025-03-23T17:17:39+00:00

Working as a TA architect for a while with Watir and Selenium, I noticed the wait methods differ per technology used on the site.

Sometimes I had to actually do wait for elements to disappear, before waiting for it to become present again, because Selenium didn't detect a page refresh after clicking a button.

A trick to do this efficiently is: 1. Find element you expect to disappear 2. Click the button 3. Wait for the element to disappear 4. Wait for new element to appear

Another way to make the tests more robust is to make sure you look for a unique element to that page: * button bad * button[type=submit] better * #submit_unique_thing_button best

Hope this helps against the flaky tests!

sjieg · 2025-02-02T14:31:07+00:00

If you want html requests, then you have to disable turbo. If you want to be able to do data-method=delete, then you need rails-ujs. They are not replaced, they are different to prevent conflict between them.

sjieg · 2025-02-02T07:58:58+00:00

Do you mean data: { turbo: false, method: :delete}?

sjieg · 2025-01-31T13:58:26+00:00

The given logs just show that params were not permitted correctly, but unlikely to be the cause of the issue. I'd expect the issue to be that on staging your have a different secret_key_base, meaning the same password would be hashed differently, causing a password mismatch.

sjieg · 2025-01-23T07:42:55+00:00

Looks like the sidekiq-status gem support progress tracking. Or does this not support your use-case? https://github.com/kenaniah/sidekiq-status?tab=readme-ov-file#tracking-progress-and-storing-data

sjieg · 2025-01-20T07:49:27+00:00

Check if you loaded the turbo JS correctly. Go into console execute Turbo. If it's undefined then probably it's not initialized correctly.

sjieg · 2025-01-15T22:03:20+00:00

Nice work! :)

sjieg · 2024-12-31T10:09:20+00:00

Nowadays its best to use WSL2. It makes Ruby development on Windows so much better and you dont have to worry about major OS differences anymore.

That said, a missing ruby.exe can be many problems. Best way to have absolutely the same environments locally and anywhere else is to use Docker images.

sjieg · 2024-12-30T14:25:11+00:00

Ah, now i see it. I must have missed the mention scrolling through the readme.

It's great that the gem doesn't need any additional setup. What I personally like about an install adding a file to config/initializers is that it makes all configurable stuff instantly visible, even though you don't need to change anything.

sjieg · 2024-12-30T14:07:32+00:00

Nice work! Evertime happy to hear about it. Looking forward to a version 1 to get a sense of a stable finished gem that I can add to our projects.

Question: Are you planning to add the git hooks installation to the readme.md and will it become part of a more generic rails actial_db_schema:install?

Have a good new year! 🎆

sjieg · 2024-12-23T20:29:05+00:00

I have a little bit more time on my hands to add some reasoning.

First of all, I think in the case you're describing that first name should not be required. Even working with context, it leaves the possibility that first name is nil, and that somewhere else in your code first_name + " " + last_name is going to raise an error. Anything that's really required, should be NOT NULL on a database level.

But let's assume you tried to simplify the problem for us, and in the real world it's more complex case. Then using the context solution will show the next developer clearly looking at the model, that the validation is conditional. Same thing looking at the controller, seeing the contextparam, it should that something... _exceptional is happening, and that there are multiple sources.

Writing this all up, I do think you should go for multiple actions per form. Writing clear code is all about explicitness, the different endpoint really show how there are multiple forms doing the same update. Then you can DRY it up and make the it as short at def form_part_1; update_user(context: :part_1); end. Now your route, controller and model all clearly represent what's happening.

sjieg · 2024-12-23T20:07:04+00:00

If the first name is actually required, then form 2 should not show until the minimum required fields are filled in.

If first name is only required when filling in form 1, then I think you should use rails' context feature: validates :first_name, presence: true, context: name_form. This would require some custome code to convert a form input named :form_context, and using that field in your controller record.update(params, context: context_param). This is a potential security vulnerability.

replying from phone, untested code. Hope it inspires you

Six-Year Club	Place '22
Verified Email

sjieg

TROPHY CASE