Testing is one of those topics where it’s easy to get stuck in a rut. You’ve got your unit tests, you’ve got your integration tests, and you’re hitting a decent code coverage number - but you’re still seeing bugs slip into production.
We recently released our Advanced Testing Techniques webinar to showcase some more “advanced” maneuvers.
If you want to stop just testing the “happy path” and start finding the bugs that actually crash your system, here is how you level up your suite.
Property-Based Testing: Testing the Rules, Not Just the Examples
Most of us write example-based tests. We say: “If I cast a Fireball and the roll is a 20, the damage should be 20.” That’s fine, but what about the thousands of other possible inputs?
With Property-Based Testing (we used FsCheck in the demo), you don’t provide the inputs. You provide the properties - the rules that must always be true. For a D&D damage calculation, a property might be: “Damage can never be negative, regardless of the roll or the target’s resistances.”
Why you want Property-Based Testing in your .NET suite
- It finds the “weird” stuff: It generates inputs you’d never think of, like nulls, empty strings, or extreme integers.
- Shrinking: When a test fails, the library “shrinks” the input to the smallest possible value that still causes the failure, making debugging a breeze.
- Better Logic: It forces you to actually understand your business rules rather than just checking a few boxes.
Test Doubles: Mocks, Stubs, and Fakes (Oh My!)
We’ve all seen test suites that are slow and brittle because they’re tied to a live database or a third-party API. That’s where Test Doubles come in.
In the video, we talk about the distinction between Mocks, Stubs, and Fakes. A lot of devs over-rely on mocking frameworks like NSubstitute or Moq.
Why you want to use Test Doubles
- Speed: Your tests run in milliseconds, not seconds.
- Reliability: Your tests don’t fail just because a dev database is down.
- Control: You can easily simulate an API timeout or a database error to see if your code handles it gracefully.
Contract Testing: No More “Integration Hell”
In a microservices world, one team changes an API, and another team’s code breaks. Standard unit tests won’t catch this, and end-to-end tests are often too slow and flaky to be helpful.
Contract Testing (using tools like Pact-Net and NSwag) creates a formal agreement between the consumer and the provider. If the provider tries to push a change that breaks the consumer’s expectations, the build fails before it ever hits production.
Why Contract Testing is a Game Changer
- Decoupled Deployment: You can deploy services independently with total confidence.
- Documentation: The contracts serve as living documentation of how your APIs are actually being used.
- Fast Feedback: It gives you integration-level confidence at the speed of a unit test.
Ready to Level Up Your Testing Game?
If you’re ready to move past the basics and start writing more robust, professional-grade tests in .NET, I want to share the full deep dive with you.
I’ve put together a resource package that includes:
- The full webinar recording where we walk through these concepts in C#.
- The GitHub repository with the D&D demo code so you can see exactly how we implemented FsCheck and NSwag.
- Additional guides for improving your testing skills
Sign up here to get the video link and other supporting links delivered to your inbox.
Don’t just hope your code works - prove it! Let’s build something better!