I have a theory: Getting started with writing coded tests is harder than it needs to be.
I wanted to make it easier to get started by getting the number of things that need to be installed or learned before it's possible to start writing tests.
The value of writing tests is better appreciated once some have actually been written, so I've made a way to put off the things you can think about later:
- Which test framework to use
- Which Test runners
- What Mocking frameworks
- What Isolation frameworks
- What are Mocks/Stubs/Fakes and when/how should they be used
- How to mark up tests and test classes
- How to indicate success or failure
- What counts as a "unit" test
- How many, and what, different things need to be installed.
That's a lot of things to learn or be a distraction when the aim is to write tests.
My solution requires:
- Only installing a single NuGet package.
- No special markup needed (attributes, naming conventions, etc.)
- Forces tests to be clear about whether they pass or fail.
To use it:
- Have a class that inherits from `SimpleTesting.IContainSimpleTests`.
- Have a parameterless constructor. (One is created by default if you don't add a constructor.)
- Create public methods that return `bool` (or `Task<bool>`)
Those public methods are then "automagically" turned into tests when the code is compiled.
And it generates tests (in a different namespace to the original class) that Test Explorer picks up and can be run from within Visual Studio.
It doesn't do everything that a full test framework does but you can use one in combination with these "simple tests."
I'd love to hear your thoughts on this?
0 comments:
Post a Comment
I get a lot of comment spam :( - moderation may take a while.