Add Playwright with eslint and example login test

[Piotrk39]

Describe your changes

Adds Playwright E2E automation tool to IBF-system Github repository, that includes:

• E2E test Directory
• E2E example login test
• Page Object Model (POM)
• Eslint for E2E test directory

ToDo:

• Connect with API tests to generate token and reset DB for creating correct state
• Remove Cypress and it's dependencies
• Add Readme
• Add CI/CD configuration to run on every PR

Checklist before requesting a review

• I have performed a self-review of my code
• I have added tests wherever relevant
• I have made sure that all automated checks pass before requesting a review

[gulfaraz]

Can this step be removed? The docker image should have the required libraries from this step.

[jannisvisser]

@gulfaraz good question. It seemed necessary, because the e2e tests are run from the host with 'npm test', and they in turn use some of the API-service files (e.g. utility.helper.ts) to reset the DB, which in turn needs the 'supertest' package. And without this 'npm install' step on the host instead of within the container, this package was not found.

Do you think this setup should be changed?

[gulfaraz]

It shouldn't be that the installation is needed on the host machine while the service is running inside docker.

I will investigate this before I propose a change.

[gulfaraz]

@Piotrk39 is there a benefit to keep the e2e tests in a separate workflow? I would like a setup where a failure of an end-2-end test will block the version bump in the other workflow. As these workflows are currently independent, the version gets bumped regardless of the e2e tests.

FYI @jannisvisser

[Piotrk39]

@gulfaraz We should add new item to fix that

@Piotrk39 is there a benefit to keep the e2e tests in a separate workflow? I would like a setup where a failure of an end-2-end test will block the version bump in the other workflow. As these workflows are currently independent, the version gets bumped regardless of the e2e tests.

FYI @jannisvisser

[jannisvisser]

@gulfaraz could we alternatively block merging to master if not all tests succeed?

[gulfaraz]

Yes, if we can figure out a way to link the other workflow to the version bump step.

It also doesn't make sense to me that we repeat certain steps in both workflows. Github actions has a limit so I think it's wise to use this limited resource efficiently. But if the need is there we can absolutely repeat certain steps, this is why I asked if the decision to have a separate workflow is deliberate.