marco-brandizi
commented
1 year ago To be clear on manual tests, I see the arrangement of them this way
- A wiki page contains a set of tests to be performed manually, in a suitable form like a list with short name/description
- the page has an ID that follows a common pattern and hopefully, it's not too long, eg, ui-tests-core
- A new ticket should link to the page and mention its ID, so that it's easy to later search the test runs
- Initially, the ticked should say something as simple as 'Run the $pageId UI tests' and later be completed/closed with the list of those that haven't passed, those with warnings, or simply 'All passed'.
Even without having the tickets (it's an experiment, it might happen we forget about them over time), having the test lists would be useful in itself, a reference of things to check periodically and upon important checkpoints, such as after the merge of a big branch or before a release.
All of this is still experimental and open to discussion with the team.
Arnedeklerk
We need to add more testing for the KnetMiner frontend code to ensure that it's stable and reliable. We are constantly running into issues where we fix one thing and break another. More specifically, we would like to use Selenium and unit tests to test the functionality of the KnetMiner frontend - combined with a WiKi/ internal guide for best practices, how to run Selenium and how to update/ create new Selenium tests.
For a start, we can define manual test plans (eg, as wiki pages) and create tickets to run them periodically (let's say every 2-4 weeks). These can be tagged with the Label: "UI-testing" - as this one is, too.
Selenium will be used to automate the testing of the user interface, while unit tests will be used to test individual components of the frontend code. As mentioned above, the test documentation should explain how Selenium works and how to write Selenium tests for the KnetMiner frontend.
Ideally, these tests should be integrated into the CI build process, and should flag up different problems as errors and warnings. The Selenium tests should be set up in a way that if a certain test no longer works (probably due to that part of KnetMiner having been updated), it shouldn't break the whole workflow but instead only require that particular piece to be redone.
We believe that by adding more testing to the KnetMiner frontend code, we can improve the stability and reliability of the code, making it easier to maintain and develop.
More info: Selenium is a popular open-source testing framework that is widely used for automating web browsers. You can learn more about Selenium by visiting their official website at https://www.selenium.dev/.
There are also a few alternative testing frameworks that could be considered for testing the KnetMiner frontend code, including:
Cypress: Cypress is another popular open-source testing framework that is designed specifically for testing web applications. It provides a robust and reliable way to test the functionality of web applications and can be integrated with CI/CD pipelines. To learn more about Cypress, you can visit their official website at https://www.cypress.io/.
Puppeteer: Puppeteer is a Node.js library that provides a high-level API for controlling headless Chrome or Chromium browsers. It is another alternative to Selenium and can be used for automated testing of web applications. To learn more about Puppeteer, you can visit their official website at https://pptr.dev/.
More about User Interface testing https://blog.qasource.com/a-complete-guide-to-user-interface-testing
Imperfect tick list of to-do
Later: