Test-Design

This is a series of posts, following a talk I gave (twice - at Pycon-US 2023 and Pycon-IL 2024), about testing best (and not-so-best) practices. The talk shares 10 practices that I had bad experience with, along with ways of avoiding them. The main objective of the post series is to help you write tests that have a better ROI. I’ll discuss different practices, different ways that we can work. These practices affect us by changing the properties of our tests: ...

This mini-post is part of a series about good testing practices, which I also presented at a couple of conferences. Here it is in PyCon US 2023 Sometimes, in a test, we switch a part of the system, a dependency, with an alternative implementation. These are called test doubles. Things like stubs, mocks and fakes. A few of the central reasons for doing this are: Performance - if the real thing is too slow to run a lot of tests, we switch it with a fast test double. Control - it might be difficult or impossible to set up the real thing in a certain state or make it behave in a certain way. Maybe it’s non-deterministic, maybe it has side effects that are not acceptable in tests. But tests doubles are under our full control and won’t create side effects we don’t want. The problem with test doubles Test doubles can be useful, but they are a re-implementation. They know the implementation details of the thing they’re replacing. Different types of test doubles do it differently, but this is what they do. ...

This mini-post is part of a series about good testing practices, which I also presented at a couple of conferences. Here it is in PyCon US 2023 The root cause of many testing problems is improper test scope, i.e. that their boundaries aren’t appropriate. Test a cohesive whole - complete story My approach here is that a test should verify a cohesive whole, a “complete story”. It can be a large story like an e2e test or a small story that’s part of a bigger story, like a custom sorting function that something else uses. As long as it’s something self-contained - something whole, it might be worth testing. ...

This mini-post is part of a series about good testing practices, which I also presented at a couple of conferences. Here it is in PyCon US 2023 Just like with product code, if we put too many things in the same place we get a mess. ...

This mini-post is part of a series about good testing practices, which I also presented at a couple of conferences. Here it is in PyCon US 2023 One testing problem that doesn’t get enough attention in my opinion is tests that don’t have locality of behavior. By that I mean cases where a test is broken down into different parts in a way that makes understanding more difficult. This is important in every type of code, and tests are no exception. ...

This mini-post is part of a series about good testing practices, which I also presented at a couple of conferences. Here it is in PyCon US 2023 Writing tests that are not isolated is a sure way to create unnecessary work for ourselves. By “tests that are not isolated”, I mean tests that sometimes have a different outcome (failing / passing) if we run only a subset of them, if we run them in a different order or if we run them in parallel. ...