Add front-end tests for react code

[MyPyDavid]

Rationale / Begründung

From discussion in #649:

Since we use react now, we could also think about adding tests for the front-end. I have no clue about the ecosystem there. This is something for the next year.

Originally posted by @jochenklar in #649 (comment)

I think you can test the frontend code with javascript unit tests, like jest.

And the test the bundled frontend in combination with a django-liveserver you can use selenium, playwright or cypress nowadays.

I wrote a couple of functional tests with selenium for another project. But I think playwright might be taking over.

Refs:

• https://playwright.dev/
• https://github.com/microsoft/playwright-pytest
• https://playwright.dev/docs/codegen-intro
• https://www.selenium.dev/
• https://splinter.readthedocs.io/
• https://jestjs.io/

Originally posted by @afuetterer in #649 (comment)

Affected

Devs

Minimal functionality

• functional tests for front-end
  • multiple browsers, test should just pass
  • Test for mobile, will depend on what is tested
• included in ci actions

Nice-to-have functionality

• tests of JS code with coverage
• 100 % coverage

References / Verweise

• Modernize the RDMO frontend #518

[afuetterer]

I can offer to write a couple of playwright tests in Python, because I wanted to test this for a long time.

These tests would require a webpack bundled frontend and a running live-server pytest-fixture. That is no problem at all.

But it "only" tests the functionality of the frontend, it will not be able to measure coverage of the JS files. For that you might need to write the tests with a JS testing framework (jest, cypress or even playwright js).

What is the priority? High coverage?

Refs:

• https://github.com/microsoft/playwright-pytest
• https://playwright.dev/python/docs/test-runners
• https://github.com/Chris-May/django_playwright_pytest_example

[MyPyDavid]

thank you @afuetterer! Think it would be great if you could make the start with just the functional tests. The coverage part is then for later or nice-to-have.

[MyPyDavid]

ok, i'll suggest here a start for tests on the new "Management Interface (docs)" that uses the React frontend.

Under /management/ each content type is known as an element. In the #sidebar there is the list of links to each element. Opening each link should show the list of items of each element in the #main part. As a test, maybe you could count the number of items (in the #list-group) shown for each element based on the test fixtures.

Some of the elements also have a special "nested" display (eg. /catalogs/1/nested/). As a start, those /nested/ views could be tested just for functionality.

The edit buttons and the edit form for each element can be tested additionally.
Another typical "click-path" would be to create a new item, fill out some data and save it.

Sidebar, Navigation:

• Catalogs
• Sections
• Pages
• Question sets
• Questions
• Attributes
• Option sets
• Options
• Conditions
• Tasks
• Views

Here are the so-called "elements" fetched:

rdmo/rdmo/management/assets/js/actions/elementActions.js

Line 21 in ee6bd48

export function fetchElements(elementType) {

and the nested parts:

rdmo/rdmo/management/assets/js/actions/elementActions.js

Line 113 in ee6bd48

if (elementAction == 'nested') {

2cents

[jochenklar]

Everything @MyPyDavid suggested and, maybe some check that if you click a button (or trigger a redux action) the right API call gets fired to the backend. I don't know how JS testing does that, but to me that would be the biggest benefit of testing the front-end.

[afuetterer]

Thank you, I will give it a try and let you know if I need more info. I will use an admin user for this, which should definitively have the required permissions, right?

@jochenklar I think the playwright tests will test the output, not so much which API call gets fired. But I will let you know.

[afuetterer]

Interim Report: playwright is awesome.

I will submit a PR soon.

I figured out how to use pytest-playwright to request the /management section with a logged in admin user and click on all items in the navigation. Works like a charm.

We need to build the webpack frontend in CI then and install a browser to access the live_server from pytest-django.

I still struggle with using the database in multiple tests. The live_server fixture uses transactions and wipes the database after a test is run. That means the first test can access data in rhe db, the second test finds an empty db. Need to do some more research.

I will define a custom "e2e" pytest marker, that can (de)select test cases.

Should I put these tests in management/tests or in a specific e2e tests folder?

I suggest running CI like now:

• lint etc.
• lots of unit tests
• a few e2e tests

Sounds like a plan?

[afuetterer]

Further discussion in associated PR #769.

[MyPyDavid]

further optimization continued with #803