This is a log of stuff I did w/ one of my random pet projects, it’s not terribly interesting and is mostly just so I can get into the habit of writing more. You have been warned.
Last time I worked on mealplanner I decided to focus on nutritional analysis. It seemed like something I’d need to be able to really use the app myself, but that’s turning out not to be the case. I can manage calories pretty easily with just the Plated recipes (which all have calorie counts) and I don’t really need a micro nutrient analysis. Not at the moment anyway.
So I thought I’d switch focus. Now that mealplanner is basically usable for me (I have basically been cooking 90% of the time in 2023), I want to fill out the distribution pipeline, firstly, so I’m not running it locally in development mode to use it, and also so others can download and use it (though without being able to download the Plated database I created, they won’t be able to do much).
The first step in creating a pipeline to build the app for different platforms and make the binaries available is filling out my test suite. (Before anything is released I of course want to make sure no regressions get through.)
At the moment there are unit tests for the Vue stores, but nothing else. Unit tests are nice, possibly even essential, but they are very limited in what they test. They very much do not ensure the experience of the end user. For that I needed to add some end to end (e2e) tests. Which is what I did this time.
Introducing webdriverio
webdriverio is a browser automation tool (simulates user behavior in a browser) that I’ve used before, and something
that very easily allows the use of visual regression testing (comparing screenshots of an app to baseline values), so
it was the ideal tool for me to use.
tauri also appeared to have support for it with a custom webdriver. Unfortunately the documentation leaves out a fair amount information, primarily that its support seems to be very limited. Some very useful functionality, like simulating clicks or setting input values didn’t work: they either aren’t implemented or are very broken (all I got was an “unknown error” from trying them).
There’s also an issue in how tauri’s webdriver backend performs capability matching. The matching does not work when
a browserName attribute is supplied in the configuration since it doesn’t really apply to tauri, but webdriverio extensions,
like the image comparison service (which I decided to use) expect it to be there.
Fortunately it was possible to work around all of these problems.
Once everything was set up, writing the actual tests was a pretty simple, and getting them to pass not particularly difficult. And if you’d like to see the baseline screenshots generated, they’re in the repo here: https://gitlab.com/dizzycodes/mealplanner/-/tree/main/tests/baseline/desktop_tauri
Next stop, introducing continuous integration. Something I have not done with rust apps, gitlab or tauri before. So that should be interesting.