Identifying Codified Oracles In Automated Test Design

Arguably one of the most important parts of an automated test is the assertion(s). Or the oracle, as I prefer. An oracle is a fallible way to identify a problem, put another way, it alerts us to something it believes might be a problem, but it’s not guaranteed to be a problem. Assertions are a method for implementing an oracle.

The reason why I believe they are one of the most important parts is because it’s these assertions that pass and fail. It’s the passing and failing of automated checks that causes most teams to investigate or confirm their next testing steps. But what if I told you that most of your assertions are probably rather poor, and not actually testing what you think you are testing.

In this workshop we are going to explore some common mistakes people make when designing and implementing automated tests. Explore these mistakes, identify better oracles, and in turn design assertions that are guaranteed to add value to your automated tests, and in turn, your testing.

Note: This workshop is a live only event and will not be recorded.