You’ve got a lot of Gall
Latest posts
Debugging flaky browser specs in a Github Action (Flaky Specs part 5)
The most “fun” flaky spec to debug is a flaky browser spec that only fails intermittently in CI. What now? To debug these effectively: Force your Github Action container to stay alive Provide a way to SSH in Provide a way to see the actual browser and interact with it Capybara running over VNC in the Github Action container: The above was setup using my “ci_vnc” scripts that are designed to setup…
Debugging flaky specs in a Github Action (Flaky Specs, Part 4)
Run your spec directly in CI / Github Action If you are unable to reproduce the error locally - try running your spec directly in CI. Github Actions and CI in general aren’t designed to allow you to SSH into them, but you can still do that with a couple of changes: Force it to stay “alive” Allow it to accept incoming connection with upterm or ngrok 1 Upterm Github Action The Upterm Github Action…
Flaky specs (part 3)
Sometimes specs only fail on CI, and pass locally. The first thing to try is running the test suite locally in the same order locally: Look for Randomized with seed 14427 in your CI test run output. Grab the seed and then run the test suite locally with it: bundle exec rspec --seed 14427
How to deal with flaky rspec tests (flaky specs, part 2)
Leaving flaky specs in your tets suite may seem not very harmfull. It just requires developers to sometimes rerun the test suite, so what? The thing is - besides just reducing overall developer productivity, you are also training yourself to ignore or not rely on the tests as much. This can be much more harmful. Instead of letting flaky specs fester, take the following two steps immediately: Mark…
Debugging flaky specs - part 1
Everyone’s favorite topic: flaky specs. There is no one solution because it’s not one problem. But for the most part a flaky spec’s root cause will always come down to something introducing non-determinism. List of some common non-deterministic root causes: Specs can be run in a random order (which is a good thing). When one test leaks state, this can result in subsequent tests failing…
How to not re-record VCR cassettes, part 3
Custom Matchers allow a lot of flexibility. For example for an app that deals with Reddit URLs, this matcher allows any variation of the reddit URL to match as long as the Post ID matches: module VCRHelpers reddit_url= ->(request_1, request_2) { extract_reddit_id(request_1) == extract_reddit_id(request_2) } end (Bonus: Uses the neat Ruby lambda syntax) Then to use it: describe 'my test', vcr: {…
How to not re-record VCR cassettes part 2
More ways to not re-record VCR cassettes when you test changes: Surgically modify the cassette YAML file to match the changes. Not ideal but works in a pinch. When the test includes a series of HTTP requests and only one changed: manually remove that one request: key from the cassette YAML file, change your cassette options to record: :new_episodes and re-run the test. It will only re-record the…
How to not re-record VCR cassettes (part 1)
Sometimes when you make some small changes to a test that uses VCR the existing VCR recording varies just enough so that VCR insists that you re-record the VCR cassette, with the dreaded “VCR does not not know how to handle” error message. If rerecording the cassette requires a lot of setup, it’s useful to have a few workarounds to avoid this. This will be a series of posts, and I’m going to start…
AITAH Player
I did a thing! My wife, son & I like listening to posts from subreddits like r/amitheasshole and r/amiwwrong while we’re in the car, and then discussing and rendering our own judgement. However, the text-to-speech on the reddit app is pretty bad, so I built an app that does it better. It works kind of like a Spotify for reddit advice posts - it reads out the post and the top comments. Install via…