Add explanation of mocking and stubbing

Author: connoraird

testing/README.md

@@ -38,8 +38,39 @@ Compilers tested: *A list of compilers we have tried with these tests*
 | Feature | Implemented natively | Implemented manually |
 |---------|----------------------|----------------------|
 | Can run individual tests | Yes or No (explanation) | Yes or No (explanation) |
-| Mocking | Yes or No (explanation) | Yes or No (explanation) |
-| Stubbing | Yes or No (explanation) | Yes or No (explanation) |
+| Mocking/Stubbing | Yes or No (explanation) | Yes or No (explanation) |
 | Data driven tests | Yes or No (explanation) | Yes or No (explanation) |
 | Coverage report | Yes or No (explanation) | Yes or No (explanation) |
 | Skip tests | Yes or No (explanation) | Yes or No (explanation) |
+
+### Explanations 
+
+**Mocking**
+
+There are many good explanations of what mocking is, [here is one](https://www.hypertest.co/unit-testing/unit-test-mocking) (this is summarised below)
+
+**What is Mocking?**
+
+Mocking is a technique used in unit testing to replace real objects with mock objects. These mock objects simulate the behaviour of real objects, allowing the test to focus on the functionality of the unit being tested. Mocking is particularly useful when the real objects are complex, slow, or have undesirable side effects (e.g., making network requests, accessing a database, or depending on external services).
+
+**Why Use Mocking?**
+
+- *Isolation:* By mocking dependencies, you can test units in isolation without interference from other parts of the system.
+
+- *Speed:* Mocking eliminates the need for slow operations such as database access or network calls, making tests faster.
+
+- *Control:* Mock objects can be configured to return specific values or throw exceptions, allowing you to test different scenarios and edge cases.
+
+- *Reliability:* Tests become more predictable as they don't depend on external systems that might be unreliable or unavailable.
+
+**Stubbing**
+
+Stubbing is very similar to mocking. The concept of stubbing is to have well-defined responses to procedure calls within a test which do not require calls to actual src code. For example, if we are want to test `functionAB` which relies on some data which is usually returned from `functionA` which is compute intensive, we can essentially hard-code the response from `functionA` to speed up the test.
+```f90
+call stubbedFunctionA(data)    ! retrieve the hard coded data values from a stub
+call functionB(data, output)  ! Use these hard coded values in out procedure being tested 
+! Verify out output
+```
+This may seem overkill in the above example, but it becomes more important if we pass `functionA` into `functionB` and wanted to ensure this was stubbed.
+
+The difference compared to mocking is that stubbing will not track calls to the mocked procedure/function/object whereas mocking will.

testing/pFUnit/README.md

@@ -18,8 +18,7 @@ Compilers tested: GNU Fortran (Homebrew GCC 14.2.0_1)
 | Feature | Implemented natively | Implemented manually |
 |---------|----------------------|----------------------|
 | Can run individual tests | Yes (by directly calling the test executable, not ctest, we can pass `-f` to filter tests by name) | N/A |
-| Mocking | No | No |
-| Stubbing | No | No |
+| Mocking/Stubbing | No | No |
 | Data driven tests | Yes (see [test_calculate_mesh_parameters.pf](./test_calculate_mesh_parameters.pf)) | N/A |
 | Coverage report | Yes or No (explanation) | Yes or No (explanation) |
 | Skip tests | Partially, but there is no logging of skipped tests (add required pre-compile flag e.g. `@Test(#ifdef NO_SKIP)`) | Partially (comment `@Test` annotation) |

testing/test-drive/README.md

@@ -30,8 +30,7 @@ Compilers tested: GNU Fortran (Homebrew GCC 14.2.0_1)
 | Feature | Implemented natively | Implemented manually |
 |---------|----------------------|----------------------|
 | Can run individual tests | No | Yes, see [main.f90](./main.f90). However, this requires running the test executable directly without ctest. |
-| Mocking | No | Not implemented |
-| Stubbing | No | Not implemented |
+| Mocking/Stubbing | No | Not implemented |
 | Data driven tests | No | Yes, but this is very cumbersome. See `verify_calculate_mesh_parameters` and `verify_calculate_mesh` in [test_mesh_generator.f90](./test_mesh_generator.f90)
 | Coverage report | Yes, with fpm | N/A |
 | Skip tests | Yes, see `test_skip_example` in [test_mesh_generator.f90](./test_mesh_generator.f90) | N/A |

testing/veggies/README.md

@@ -16,8 +16,7 @@ Compilers tested: GNU Fortran (Homebrew GCC 14.2.0_1)
 | Feature | Implemented natively | Implemented manually |
 |---------|----------------------|----------------------|
 | Can run individual tests | Yes ( fpm test *"fpm test name"* [-- -f *"regex for test description"*] ) | N/A |
-| Mocking | No | No |
-| Stubbing | No | No |
+| Mocking/Stubbing | No | No |
 | Data driven tests | Yes (via defining custom types which extend `input_t` type) | N/A |
 | Coverage report | No | No |
 | Skip tests | No | Sort of (return a generic pass with a description indicating test was skipped) |