diff --git a/docs/dev-guide/testing.md b/docs/dev-guide/testing.md index e7da565..05f2bd5 100644 --- a/docs/dev-guide/testing.md +++ b/docs/dev-guide/testing.md @@ -2,31 +2,51 @@ ## Types of Testing +### Code Tests + +![test-pyramid](./images/test_pyramid.webp) + - **Unit Testing:** - - Focuses on testing individual units or components of a software in isolation. - - Validates that each unit of code performs as designed. + - Testing specific isolated functions or classes in your code. + - Inputs are pre-defined and outputs are mocked to verify the code + works as intended. + - Unit tests can be written for the backend (e.g. Pytest) and frontend + (e.g. Vitest). - **Integration Testing:** - Verifies that different units or modules work together as expected. - Identifies issues in interactions between integrated components. - -- **Functional Testing:** - - - Validates that the software functions according to specified requirements. - - Ensures that the system behaves as expected from the end-users' perspective. - -- **Regression Testing:** - - - Ensures that new code changes don't negatively impact existing functionalities. - - Detects unintended side effects caused by modifications. - -- **Acceptance Testing:** - - - Validates that the entire system meets the specified requirements - and is accepted by stakeholders. - - Can include user acceptance testing (UAT) and business acceptance testing. + - For example and endpoint on a web API can be tested for expected + output, which may run various different functions throughout the code. + - Typically backend tests, but can also be written to group together + multiple frontend unit tests (e.g. testing a component state). + +- **User Interface (UI) Testing:** + + - Checking for changes to the user interface functionality can be + automated. + - As of 2024, a great tool to do this is + [Playwright](https://github.com/microsoft/playwright). + - The idea is to navigate to various pages and see if the output is as + expected. + - For example, a screenshot of a page can be taken on a page load, then + compared against a page load in a future test. This will determine if + any unexpected visual regression has occured. + - Page elements can be navigated and interacted with using [various + properties](https://playwright.dev/docs/locators), such as element + names, ids, labels, to lower level CSS and XPath if required. + +- **End-to-End (E2E) Testing:** + + - Similar to integration tests, except the entire expected user + workflow is tested. + - For example, if you expect a user to create a user account --> + create a project --> perform some processing, then these steps will + be tested in order (as if the user was using the software). + +### Other Tests - **Performance Testing:** @@ -39,28 +59,11 @@ - Identifies vulnerabilities and weaknesses in the software's security features. - Ensures that sensitive data is protected and the system is resistant to attacks. -- **Usability Testing:** - - - Assesses the software's user interface, user experience, and overall - user-friendliness. - - Focuses on how easily users can interact with and navigate through the application. - -- **Compatibility Testing:** - - - Ensures that the software functions correctly across different - devices, browsers, and operating systems. - - Verifies compatibility with various configurations. - - **Smoke Testing:** - - A subset of tests to verify basic functionality and ensure the - stability of a new build. - - Quick checks performed before more comprehensive testing. - -- **Exploratory Testing:** - - - Informal testing approach where testers explore the application to find defects. - - Emphasizes discovery and learning during the testing process. + - A test to pretty much see if your application starts up. + - If a smoke test fails, then you application failed to initialise. + - Particularly useful to test if a container runs as expected. - **White Box Testing:** @@ -73,17 +76,13 @@ - Tests the software's functionality without knowing its internal code or logic. - Focuses on inputs and outputs, treating the software as a "black box". -- **Ad-hoc Testing:** - - - Informal and unplanned testing approach. - - Testers explore the application without predefined test cases. - - **Alpha Testing:** - Conducted by a select group of users before the software's public release. - Focuses on identifying major issues before wider deployment. - **Beta Testing:** + - Conducted by a larger group of users in a real-world environment. - Gathers feedback from end-users to improve the software before the final release. diff --git a/docs/images/test_pyramid.webp b/docs/images/test_pyramid.webp new file mode 100644 index 0000000..46ef7e6 Binary files /dev/null and b/docs/images/test_pyramid.webp differ