I think people use automation tests that hit the API in stg/dev envs to cover this problem
1 Like
Ah yeah that makes sense.
In a Rails app I now own, previous developers incorporated an npm package called canned to mock out APIs. It actually works pretty well, especially if you need to mock APIs called from the JS side of a Rails app. The previous developers also wrote a script to record mocks, kind of like VCR, but it’s broken at the moment.
I’m not sure if it’s in active development, but I still like the idea. Does anyone know of something similar?
being someone who used to do a 1 hour train commute every day, our test suite has been able to run without wifi since day 1 
1 Like
All tests pass with wifi off.
About 10% of our tests fail when switching the internet off. Some of these are for testing our integrations with external services so will need to spend some time creating some better tests around those.
Ran this against one of my newer projects, thinking that we had been careful in the test writing. 1 test failed, and it turned out to be one of the slower tests in the suite. Mocked the API test, everything green, and for some reason the test runs faster now. What a surprise!
It also makes you realise how kind some of the frameworks are. This is a Laravel codebase; it was one line of code in the tests to get the tests green again.
1 Like
All still quick and green on this project, but I ran it on another project that was running slow tests and switching off the wifi pointed out a test that did not have the service call stubbed. Thanks for the good tip!
All green, thanks to VCR. However, my VCR usage is not great. Some cassettes just can’t be deleted and re-recorded, the tests depend a certain state in the external API that isn’t trivial to get. Thinking about it now, most of them would be possible to get that external state by running a teardown method after each test.
Executed it locally and all tests passed 
Fortunately our test suite turns out to be fully functional even when run offline. I decided to tackle a TODO in our tests instead.
It’s also a mess when you need to record a VCR for a service that is (temporarily) offline. We worked around with a local installation of http-server and good old-fashioned manipulation of /etc/hosts.
Ahhhh yep. There’s a partner API that has turned off their sandbox API temporarily - but it’s been off for a few months now.
Smoke tests will help you, continuously running in your server
All green! 
Although I found one spec broken hehe but not internet related
Tests passed! But great to be reminded of doing this!
Turns out we already are running our specs while offline. The decision to add a custom script to wrap a wifi toggle around the bundle exec rspec command dates a few years back, when we accidentally nuked our staging environment.
I don’t remember the exact details but we assumed it would feel much safer to always go offline when running code that wipes a (hello rails_helper’s TRUNCATE 
), even if said database is supposed to be your local test one 
2 Likes
My co-worker and I each ran one of our Rails backend repos with wifi disabled in under a minute. For the main app on the other hand…
1 Like
All green, we use VCR in my job project, I’m still looking for articles with good practices to organize VCRs in the project.
disaster fire dispair
Oh I used the wrong path
Great success