Testing strategy

[j-tirelli]

I've seen it mentioned in a few discussion posts, and I think it stands to reason that automated testing is a great step forward towards ensuring that regressions are kept to a minimum.

There aren't a great many tests currently, it may behoove us to decide on some conventions and technologies.

Personally, I'm partial to jest and playwright, but it looks like playwright support for electron is experimental. WDIO is another option.

[sigaloid]

I think a good preliminary option is testing the backend syncing (no frontend UI testing). We can test the sync server (for example - start syncing, test for collisions, etc) with something like Hurl

[eliandoran]

@sigaloid , yes, for the backend it would be nice to have both unit testing and API testing.

Syncing and other tasks that require multiple clients and a test database need some kind of test harness, which will not be easy to implement but will prove useful.

For unit testing, based on what I see from porting to TypeScript, there is a lot of code to cover. Although I think we should start sooner than later.

[eliandoran]

@j-tirelli , jest sounds good for unit testing. I've used it a bit in the past so it makes transition easier.
For client-side, it would be really nice to do some testing.

@TriliumNext/everyone , who has experience with Puppeteer, Playwright or other client-side testing tools?

[zerebos]

I've never used any real client-side testing myself due to the nature of my other projects, but I'm definitely open to learning them. I've never worked with Jest personally (mostly mocha, chai, and nock) but whatever works is fine with me!