Last year I made a post on GitHub discussions for a proof of concept for automated end-to-end testing. It didn’t go anywhere because at the time I didn’t have any plans, it was mostly just an exercise in comparing two testing frameworks for my day job.
Well, I finally took it a little bit further. It is very technical post mostly just to toot my own horn.
I actually took the time to compose a test suite, some handy boilerplate and conventions so that I don’t have to manually verify my Auto Complete plugin is still working as intended after every change.
- The tests for the plugin are in tests-pw/specs/AutoComplete.
- Common boilerplate is in tests-pw/common.
- I decided to not use TypeScript, though I use
//ts-checkdirectives for improved linting and type checking inside VS Code. Nevertheless all the code is in.jsfiles and runs in vanillanodewithout requiring TS to be installed. I tried real hard to do it with pure JSdoc without the directive but it just wouldn’t work for some cases. - I also added ESLint because I like my code to be clean.
- There are GitHub actions defined for this in .github/workflows/playwright.yml
- And you can see the tests passing in Actions, though I believe the access to details is restricted only to me.
I opted for a mix of using UI and directly referencing TW APIs. The latter is reserved to quickly load fixtures and configure the environment:
// tests-pw/specs/AutoComplete/EditTiddler.spec.js
// These just directly execute JS code in the browser to call `$tw.addTiddler()` a bunch of times
await selectEdition.initByName(edition);
await pluginUtils.initTriggers(fixtures.triggerSearchInTitle);
await twConfig.useFramedEditor(false);
While most of the other actions run off directly by clicking things.
I don’t really have any plans at the moment to propose integrating this in any way into TiddlyWiki. I am not really sure if there is much worth in doing that, primarily because:
- e2e tests are pretty tough to write and read
- It would make TW dependent on external libraries (Playwright is way too large to integrate it the same the unit testing framework is)
- e2e tests take a lot of time and resources to run
That being said, perhaps it would be worth to have it as a separate Github project that could be run on a different cycle or manually before each release.
And that’s it, just wanted to brag a little because I am very happy about this work I’ve done 
.