I'm liking how the #RSpec tests are shaping up overall though.
I'd be really interested to get some review from someone with more experience; I did find a few examples of "request" specs (which is the main layer I've decided to start with) around, but there seem to be several different taste preferences going on.
So far, having a "context" for each combination of HTTP verb + endpoint is working out reasonably, and then separate blocks to test unauthenticated / unauthorised / success
One downside of setting myself the stretch goal of "adding #RSPec tests for all URL routes" is that there are a LOT of them 😅
(`rails routes` says 303)
This is of course making this task take forever (~15 hours' work to improve test coverage from ~40% to ~65%).
But, more also-importantly, it's ruining my "lines of code deleted" metric, I have added over 2000 lines of specs alone 🙈
#RSpec interactive debugging with #Neovim: I tried a lot, I failed a lot.
I got this working for other languages ( #Python and #CSharp) and it was a HUGE help, taking away one of the main things I need to leave my editor for.
But something is blowing up and I'm still relatively new to Neotest, DAP, and the various plumbing between them and the test runners.
I'm liking how the #RSpec tests are shaping up overall though.
I'd be really interested to get some review from someone with more experience; I did find a few examples of "request" specs (which is the main layer I've decided to start with) around, but there seem to be several different taste preferences going on.
So far, having a "context" for each combination of HTTP verb + endpoint is working out reasonably, and then separate blocks to test unauthenticated / unauthorised / success
Some updates from the last few days:
#RSpec interactive debugging with #Neovim: I tried a lot, I failed a lot.
I got this working for other languages ( #Python and #CSharp) and it was a HUGE help, taking away one of the main things I need to leave my editor for.
But something is blowing up and I'm still relatively new to Neotest, DAP, and the various plumbing between them and the test runners.
After that, I want to focus on the #Docker image.
Somehow – despite applying a couple of Dockerfile tricks I've picked up since my last #Levelfly containerisation work back in 2021 – the image has ballooned from 400MB to 1.8GB, and I'd like to get that back down to size.
Part of this will likely involve publishing separate "development" and "production" images, to save new project contributors from a docker build process.
Woohoo, found my first bug thanks to extended #RSpec coverage 🥳
No luck getting #Simplecov to show me a list of uncovered methods yet, though 🤔
Firstly: test coverage. We're currently at around 40% (it's varied up and down about 3% between #Rails / #Ruby versions, which has been interesting!)
I'm not shooting for 100% – I've made the mistake before of making tests too brittle with respect to changes, and at the end of the day 100% lines covered doesn't necessarily mean 100% of functionality covered anyway.
But some of the key models and controllers are very minimally tested, which feels worth improving given the scale of the changes.
First order of business is to see if #RSpec or #SimpleCov can tell me which methods (as opposed to lines) are covered – I'd be happy enough for now if each controller and model method is at least executed.
And, with some fresh inspiration, back to my solo hackathon, Day 8 👷
"If it upgrades, upgrade it. If it doesn't upgrade, release the version constraint" is the "If it moves, salute it, if it doesn't move, pick it up" of #Ruby
(Specifically of debugging third-party packages causing deprecation warnings, praise be to #Rspec's `--backtrace` option and ` config.active_support.deprecation = :raise`)
Having the funniest issue where browser tests only run if I switch to a specific GNOME workspace, then away from it, then back to it again? Otherwise I get an HTTP timeout 🤡
If your application has a `--color` flag, be like #Rspec, also support `--colour` as an alias, absolute praxis imo
Getting basic #RSpec coverage for the key endpoints going as soon as I'd upgraded to Rails 5 was a great move; those tests have already caught all kinds of issues with the new versions.
Part of me regrets not finding a way to test S3 sooner, because file uploads have always been a big source of bugs in Levelfly, and I built up a small version-hell nightmare for myself by not checking any of that until deep into #Rails 6.
But maybe this was an OK plan: by the time I got to it, I had a lot of practice with dealing with gem dependency issues, writing #RSpec, and writing tests that require other services – all of which turned out to be crucial to getting it going.
Most satisfying thing so far has probably been finally understanding RSpec enough to be useful – specifically getting my head further around the difference between fixtures, seeds, and factories.
(And then completely ripping out the fixtures lol)
Getting basic #RSpec coverage for the key endpoints going as soon as I'd upgraded to Rails 5 was a great move; those tests have already caught all kinds of issues with the new versions.