Expand the contibuting docs about unitverse HOT 4 CLOSED

Could you please elaborate bullet 2?

Bullet 3 is the most important I think.

from unitverse.

So for bullet 2 - my general aim with the extension has not to be really specific about the output that is generated - so, for example, if a new method of deriving a default value for a type is added, I don't care so much that it is done in an exact way. What I care most about is that the code compiles - I feel like it's really important to be able to add tests that compile. Obviously the test generator isn't going to generate tests that pass, except for basic cases. So if the tests compile when they are generated, then the tool is 'getting out of the way' and the developer can immediately think about how they want to go about testing the code they just wrote, instead of having to fix a bunch of broken code.

So there are some tests that check output - in the .Specs project - and they check things like 'has a mock been generated for this dependency' and 'is this basic assert emitted'. But they are not designed to break every time something minor changes.

Does that make sense?

from unitverse.

Oh, I guess one more thing to add - the example generator / build protection - that generates test classes for a bunch of known samples, and then emits markdown that form the 'examples' section in the documentation. It basically runs every build (when the example generator has built, it is called by the msbuild script in the post build actions). So then, if you have changed the output, you see the changes in the example documentation. And you have to check those in. If the example generator runs in the GitHub Actions build and produces output that is different (i.e. there are uncommitted changes in the docs folder) then it will break the build. So if you do change the output, you have to 'accept' that by committing the newly generated markdown docs.

from unitverse.

Added 👍

from unitverse.