Collecting ideas: Integration tests in web

[kulmann]

Regarding tests we are currently using

• @vue/test-utils and jest for unit tests
• @testing-library/vue and jest for integration tests
• playwright and cucumber for end2end tests

For unit tests and end2end tests we are quite happy with the results and tooling. The blunt reality when writing tests is, that writing and/or debugging integration tests are a completely different world than doing the same for unit tests. While it feels ok-ish to write integration tests the way they are currently written (abstraction level feels good), the tooling for debugging failing tests is not good (or not well understood). It seems to be not even possible to log the HTML of the system under test. In any case it would be nice to reduce the set of technologies, so a hot candidate for integration tests would naturally be playwright - but we didn't have a chance to look into whether or not playwright is a good fit for our integration tests.

E.g. for end2end tests we are able to record traces and utilize them for debugging why the specific test run failed. That is awesome.

We are looking for a replacement for the integration tests. Any opinion and/or research is much appreciated! ❤️

[phil-davis]

Can someone write what integration tests are supposed to do. For example:

• unit tests: verify that each publicly-accessed method (function, whatever it is called) in a class (usually a "file of code" if it is not strictly OOP code with "classes") returns the expected result for various combinations of inputs
• integration tests: verify that multiple "unit test classes" can be instantiated (technical words here may be different if not OOP) and objects of each "class/unit" can be "passed around" between each other in sequences that test internal data flows that would typically happen in reality
• end-to-end tests: the whole system is started as close as possible/reasonable/practical to how a production system would run. The tests make inputs as a "user" would do, and check results that a "user" expects. "user" can be simulating a real person typing/clicking in a webUI, a sync client "doing its thing" on behalf of a "user" on a client system (Windows, *nix, Android, iOS..), or a "user" doing API requests (pretending that a "nerd user" is sitting there doing curl requests as a poor-mans client)

[fschade]

closed via #6863