From ae0c77a7c8bbc954f93df40be79cb148cec15ecf Mon Sep 17 00:00:00 2001 From: Douglas Lowe <10961945+douglowe@users.noreply.github.com> Date: Tue, 25 Aug 2026 10:49:22 +0100 Subject: [PATCH 1/5] parametrize spelling standardisation for unit testing lesson --- episodes/22-scaling-up-unit-testing.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/episodes/22-scaling-up-unit-testing.md b/episodes/22-scaling-up-unit-testing.md index 44e76ba85..ca9a3422b 100644 --- a/episodes/22-scaling-up-unit-testing.md +++ b/episodes/22-scaling-up-unit-testing.md @@ -6,7 +6,7 @@ exercises: 5 ::::::::::::::::::::::::::::::::::::::: objectives -- Use parameterisation to automatically run tests over a set of inputs +- Use parametrization to automatically run tests over a set of inputs - Use code coverage to understand how much of our code is being tested using unit tests :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -28,15 +28,15 @@ How can we make our job of writing tests more efficient? And importantly, as the number of tests increases, how can we determine how much of our code base is actually being tested? -## Parameterising Our Unit Tests +## Parametrizing Our Unit Tests So far, we have been writing a single function for every new test we need. But when we simply want to use the same test code but with different data for another test, it would be great to be able to specify multiple sets of data to use with the same test code. -Test **parameterisation** gives us this. +Test **parametrization** gives us this. So instead of writing a separate function for each different test, -we can **parameterise** the tests with multiple test inputs. +we can **parametrize** the tests with multiple test inputs. For example, in `tests/test_models.py` let us rewrite the `test_daily_mean_zeros()` and `test_daily_mean_integers()` into a single test function: @@ -56,15 +56,15 @@ def test_daily_mean(test, expected): ``` Here, we use Pytest's **mark** capability to add metadata to this specific test - -in this case, marking that it is a parameterised test. -`parameterize()` function is actually a +in this case, marking that it is a parametrized test. +`parametrize()` function is actually a [Python **decorator**](https://www.programiz.com/python-programming/decorator). A decorator, when applied to a function, adds some functionality to it when it is called, and here, what we want to do is specify multiple input and expected output test cases so the function is called over each of these inputs automatically when this test is called. -We specify these as arguments to the `parameterize()` decorator, +We specify these as arguments to the `parametrize()` decorator, firstly indicating the names of these arguments that will be passed to the function (`test`, `expected`), and secondly the actual arguments themselves that correspond to each of these names - @@ -83,9 +83,9 @@ and adding more tests scales better as our code becomes more complex. ::::::::::::::::::::::::::::::::::::::: challenge -## Exercise: Write Parameterised Unit Tests +## Exercise: Write Parametrized Unit Tests -Rewrite your test functions for `daily_max()` and `daily_min()` to be parameterised, +Rewrite your test functions for `daily_max()` and `daily_min()` to be parametrized, adding in new test cases for each of them. ::::::::::::::: solution @@ -131,7 +131,7 @@ Let us commit our revised `test_models.py` file and test cases to our `test-suit ```bash $ git add tests/test_models.py -$ git commit -m "Add parameterisation mean, min, max test cases" +$ git commit -m "Add parametrization mean, min, max test cases" ``` ## Code Coverage - How Much of Our Code is Tested? @@ -361,7 +361,7 @@ to learn more about code coverage. :::::::::::::::::::::::::::::::::::::::: keypoints -- We can assign multiple inputs to tests using parametrisation. +- We can assign multiple inputs to tests using parametrization. - it is important to understand the **coverage** of our tests across our code. - Writing unit tests takes time, so apply them where it makes the most sense. From d5b7867c60feee71ac3e96c0b9fad6d4d49e5712 Mon Sep 17 00:00:00 2001 From: Douglas Lowe <10961945+douglowe@users.noreply.github.com> Date: Thu, 3 Sep 2026 15:25:26 +0100 Subject: [PATCH 2/5] parametrization standardised spelling for s2 intro --- episodes/20-section2-intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/episodes/20-section2-intro.md b/episodes/20-section2-intro.md index 40f17bc75..72684e8eb 100644 --- a/episodes/20-section2-intro.md +++ b/episodes/20-section2-intro.md @@ -52,7 +52,7 @@ In this section we will: a free and open source Python library to help us structure and run automated tests. - Design, write and run **unit tests** using Pytest to verify the correct behaviour of code and identify faults, - making use of test **parameterisation** + making use of test **parametrization** to increase the number of different test cases we can run. - Automatically run a set of unit tests using **GitHub Actions** - a **Continuous Integration** infrastructure that allows us to @@ -65,7 +65,7 @@ In this section we will: :::::::::::::::::::::::::::::::::::::::: keypoints - Using testing requires us to change our practice of code development, but saves time in the long run by allowing us to more comprehensively and rapidly find faults in code, as well as giving us greater confidence in the correctness of our code. -- The use of test techniques and infrastructures such as **parameterisation** and **Continuous Integration** can help scale and further automate our testing process. +- The use of test techniques and infrastructures such as **parametrization** and **Continuous Integration** can help scale and further automate our testing process. :::::::::::::::::::::::::::::::::::::::::::::::::: From 6c1f9a7f304883ec3fa2df3b3b6117cea2363bc2 Mon Sep 17 00:00:00 2001 From: Douglas Lowe <10961945+douglowe@users.noreply.github.com> Date: Thu, 3 Sep 2026 15:30:56 +0100 Subject: [PATCH 3/5] parametrization standardisation for section 2.4 --- episodes/24-diagnosing-issues-improving-robustness.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/episodes/24-diagnosing-issues-improving-robustness.md b/episodes/24-diagnosing-issues-improving-robustness.md index 659765aab..a2a557899 100644 --- a/episodes/24-diagnosing-issues-improving-robustness.md +++ b/episodes/24-diagnosing-issues-improving-robustness.md @@ -423,9 +423,9 @@ The debugger has its own commands that you can read about in ## Corner or Edge Cases The test case that we have currently written for `patient_normalise` -is parameterised with a fairly standard data array. +is parametrized with a fairly standard data array. However, when writing your test cases, -it is important to consider parameterising them by unusual or extreme values, +it is important to consider parametrizing them by unusual or extreme values, in order to test all the edge or corner cases that your code could be exposed to in practice. Generally speaking, it is at these extreme cases that you will find your code failing, so it is beneficial to test them beforehand. @@ -454,7 +454,7 @@ so this will clearly break if we are dividing by zero here, resulting in `NaN` values in the normalised array. With all this in mind, -let us add a few edge cases to our parametrisation of `test_patient_normalise`. +let us add a few edge cases to our parametrization of `test_patient_normalise`. We will add two extra tests, corresponding to an input array of all 0, and an input array of all 1. @@ -519,7 +519,7 @@ def patient_normalise(data): ## Exercise: Exploring Tests for Edge Cases Think of some more suitable edge cases to test our `patient_normalise()` function -and add them to the parametrised tests. +and add them to the parametrized tests. After you have finished remember to commit your changes. ::::::::::::::: solution From 7cf5b44d8b7dc8ea4fa65a54abc4cafe55f0dfde Mon Sep 17 00:00:00 2001 From: Douglas Lowe <10961945+douglowe@users.noreply.github.com> Date: Thu, 3 Sep 2026 15:34:46 +0100 Subject: [PATCH 4/5] parametrization standardisation for index, paper and extra lessons --- index.md | 2 +- learners/functional-programming.md | 2 +- learners/object-oriented-programming.md | 2 +- paper.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/index.md b/index.md index 583ac8a08..004a072a9 100644 --- a/index.md +++ b/index.md @@ -79,7 +79,7 @@ After going through this course, participants will be able to: - Set up and use a suitable development environment together with popular source code management infrastructure to develop software collaboratively - Use a test framework to automate the verification of correct behaviour of code, - and employ parameterisation and continuous integration to scale and further automate code testing + and employ parametrization and continuous integration to scale and further automate code testing - Design robust, extensible software through the application of suitable programming paradigms and design techniques - Understand the code review process and employ it to improve the quality of code diff --git a/learners/functional-programming.md b/learners/functional-programming.md index 3fb21a7ed..b41beb110 100644 --- a/learners/functional-programming.md +++ b/learners/functional-programming.md @@ -719,7 +719,7 @@ For example, you may want to define the success criteria for a trial if, say, Finally, we will look at one last aspect of Python where functional programming is coming handy. As we have seen in the -[episode on parametrising our unit tests](../episodes/22-scaling-up-unit-testing.md#parameterising-our-unit-tests), +[episode on parametrizing our unit tests](../episodes/22-scaling-up-unit-testing.md#parametrizing-our-unit-tests), a decorator can take a function, modify/decorate it, then return the resulting function. This is possible because Python treats functions as first-class objects that can be passed around as normal data. diff --git a/learners/object-oriented-programming.md b/learners/object-oriented-programming.md index a2a9c6094..ae8d33393 100644 --- a/learners/object-oriented-programming.md +++ b/learners/object-oriented-programming.md @@ -504,7 +504,7 @@ print(obs) ``` You may recognise the `@` syntax from episodes on -parameterising unit tests and functional programming - +parametrizing unit tests and functional programming - `property` is another example of a **decorator**. In this case the `property` decorator is taking the `last_observation` function and modifying its behaviour, diff --git a/paper.md b/paper.md index c986f6fd2..814993a6e 100644 --- a/paper.md +++ b/paper.md @@ -99,7 +99,7 @@ designing, building, releasing, and maintaining software. After going through this course, participants will be able to: * Set up and use a suitable development environment together with popular source code management infrastructure to develop software collaboratively -* Use a test framework to automate the verification of correct behaviour of code, and employ parameterisation and continuous integration to scale and further automate code testing +* Use a test framework to automate the verification of correct behaviour of code, and employ parametrization and continuous integration to scale and further automate code testing * Design robust, extensible software through the application of suitable programming paradigms and design techniques * Understand the code review process and employ it to improve the quality of code * Prepare and release software for reuse by others From 32be270b743c237e4dcfd37660f8a5235e144112 Mon Sep 17 00:00:00 2001 From: Douglas Lowe <10961945+douglowe@users.noreply.github.com> Date: Thu, 3 Sep 2026 15:36:13 +0100 Subject: [PATCH 5/5] parametrization standardisation for slides --- slides/section_2_ensuring_correctness.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/slides/section_2_ensuring_correctness.md b/slides/section_2_ensuring_correctness.md index 081cbfb34..01631a877 100644 --- a/slides/section_2_ensuring_correctness.md +++ b/slides/section_2_ensuring_correctness.md @@ -97,21 +97,21 @@ Start from this section heading and go to the end of the page. ## Scaling Up Unit Testing -1. Parameterise our tests to reduce repetition +1. Parametrize our tests to reduce repetition 2. Check the test coverage of our code -1. Parameterise our tests +1. Parametrize our tests - from the previous example, you may have noticed that if you want to run a test with the same logic but different input data, you will need to create a new test function that is mostly the same - - there is a convenient way to avoid this in pytest called _parameterisation_, allowing a single test function to run through a variety of test input cases + - there is a convenient way to avoid this in pytest called _parametrization_, allowing a single test function to run through a variety of test input cases - very powerful to improve the coverage of the parameter space that you code might be dealing with 2. Check the test coverage - on a related note, it is important to see how much of our code is "covered" (i.e. verified) by our tests so that we can get at least a relative idea of how the quality of our code is faring overtime, and where we should focus testing efforts -### Breakout Exercise: 🖉 Parameterising Our Unit Tests +### Breakout Exercise: 🖉 Parametrizing Our Unit Tests Go through this page to the end, starting from this section heading. In the last 5-7 minutes, please think about the question: