When writing tests, we often start with what we think will be typical use cases for our code. It’s common to begin with the happy path, where we expect a certain outcome from our modules being used in a particular way (e.g. calling a method with a specific input should produce a known output). We might add tests for unhappy paths too; we explore ideas of how things might go wrong, checking for error handling and corrective measures. Doing this might prompt us to include further tests to catch edge cases. And then we might want to run them with multiple datasets to check that expected results don’t come by chance.
Share this post
3 Ways to Organise and Tidy Your C# Unit Test…
Share this post
When writing tests, we often start with what we think will be typical use cases for our code. It’s common to begin with the happy path, where we expect a certain outcome from our modules being used in a particular way (e.g. calling a method with a specific input should produce a known output). We might add tests for unhappy paths too; we explore ideas of how things might go wrong, checking for error handling and corrective measures. Doing this might prompt us to include further tests to catch edge cases. And then we might want to run them with multiple datasets to check that expected results don’t come by chance.