526 episode 22 multiple spellings of parametrize

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.
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::
 

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.
 

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

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

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.

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,

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

slides/section_2_ensuring_correctness.md

@@ -97,21 +97,21 @@ Start from this section heading and go to the end of the page.
 <!-- #region slideshow={"slide_type": "slide"} -->
 ## 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
 <!-- #endregion -->
 
 <!-- #region slideshow={"slide_type": "notes"} -->
-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
 <!-- #endregion -->
 
 <!-- #region slideshow={"slide_type": "subslide"} -->
-### 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: