docs: more detail on types of tests

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.