Autumn 2026 revision

[mmesiti]

Main issue for the preparation of the Autumn 2026 edition. Done with @Vinye , but if I wrote something nasty is only me being nasty.

General things:

• "Testing" is not just "automated testing". There's manual testing, and also testing automated at different levels. When we say/type "tests" in the lesson, it's typically "Automated Tests", and when we say "automated tests" we typically mean fully automated, i.e., in CI or actions. This might need to be clarified a bit.

Sub-issues:

• The main page https://coderefinery.github.io/testing/ seems to delve in to the motivations much more than done in other lessons, for example: https://coderefinery.github.io/git-intro/. We could move most of the content there into the Motivation episode https://coderefinery.github.io/testing/motivation/

• in Motivation https://coderefinery.github.io/testing/motivation/: there's quite a lot in the main page, which could fit here.

  • Untested software can be compared to uncalibrated detectors

    the "uncalibrated detectors" analogy is quite specific and might apply to a small subset of scientists. Perhaps "Untested software is akin to uncalibrated measurement devices" or something like that. But in gneeral, I feel this should be a bullet point/sub item in a list of things, that mentions too that bugs in software lead to wrong scientific results in general.

  • In software tests, expected results are compared with observed results in order to establish accuracy.

    This is only the most common/basic way of testing. There are also behavior tests (functions does not fail, or function fails when it should). There are also properties that can be tested (not to go into metamorphic testing).
    Edit: It's fine here, it's just an intro/motivation

  • Why are we not comparing directly all digits with the expected result?:

    although important topic, this should not go here, it's treated in the "testing locally" episode with an exercise.

  • This fits here: https://coderefinery.github.io/testing/motivation/#what-can-tests-help-you-do
    maybe change from a bullet point list to a table (problem, people having the problem -> solution)

  • "Discussion: What’s easy and hard to test?"

    • this should go in the conclusions, after people have seen what is possible/easy to do with the current frameworks
    • the verb "test" here means "test automatically", or "write an automated test for".

  • Testing vocabulary could have its own page, like in the other episodes, and the terms could be introduced along the way.b See glossary https://coderefinery.github.io/git-intro/reference/ for example

  • "where to start" is repeated in conclusions https://coderefinery.github.io/testing/conclusions/ and probably belongs there more than here. Same, to an extent, can be said about the "What should you do?" bit

2. in https://coderefinery.github.io/testing/locally/:

   • "Exercise" is very generic https://coderefinery.github.io/testing/locally/#exercise
     There could be two sections:
     • "setting up your first automated test"
     • "dealing with numerical tolerance" (or something similar), and use here the fahenheit_to_celsius test instead of just the add function (which seems a bit artificial, and the "add" implementation is obviously correct).

3. in https://coderefinery.github.io/testing/conclusions/:

• It's a list of bullet points. Simple, useful for the teacher, but visually not really enticing

• The practice of testing is actually not that simple. So this chapter should at least hint at typical problems that arise in more complex situations Edit: maybe we can talk about this in the 'test design' episode instead, where it would be better grounded

• Maybe show the "testing pyramid"? Edit: Mentioned it without adding a picture, easily findable with any search engine
  

• what is test coverage? How to test the tests? Now I have the tests that assure that if I change the code I catch bugs, but what if I want to change the tests? Edit: coverage is mentioned. Mutation testing might be out of scope...

• If you make your code easier to test, it becomes more modular

  • I think you typically make code modular in order to test it, and making code more testable is (to me) the main reason for making it modular. Edit: addressed with a simple "vice-versa", I think

• Ways to get started could become a table: situation/problem -> solution

to be continued

[mmesiti]

Reviewing the issue to understand what still could be done (I think that most of these things are done now)