Make unit tests public

Public unit tests for framework is win-win both for vendor, and framework consumers. My top 5 reasons for that.

Led by example: Unicorn

Unicorn is popular serialization mechanism with > 1.3M Nuget downloads!

All you need to get started is to download the package and read readme. Custom requirements (f.e. store only specific part of the tree) are simply implemented as test configuration already provides all the samples you may ever need, example:

	<include name="Basic" database="master" path="/sitecore/layout/Simulators">
		<exclude path="/sitecore/layout/Simulators/Android Phone" />
		<exclude path="iPhone" />
		<!-- relative path exclusion based on parent include path -->
		<exclude path="iPhone Apps/1.0" />
		<!-- exclude where name starts with a different include -->
	</include>

Wondering about processing order and dependent configs? Answers are already in configuration dependency tests for you.

Led by example: Sitecore.NSubstituteUtils

Sitecore.NSubstituteUtils allows mocking centric Sitecore objects (Item/Database) and so much more, see Unit testing in Sitecore. The learning curve is just to look at the tests:

        [Theory, InlineAutoData("test field", "test value")]
        public void ItemIndexerByFieldId_AfterAdd_ReturnsAddedValue(string fieldName, string addedFieldValue, ID fieldId)
        {

            var fakeItem = new FakeItem();

            fakeItem.Add(fieldId, fieldName, addedFieldValue);
            Item item = fakeItem;


            var actualFieldValue = item[fieldId];


            actualFieldValue.Should().Be(addedFieldValue);
        }

All features are discovered by looking through test names. What could be better than reading neat test code and have an option to execute in your environment on demand?

Never misleads you

What could be worse than non-existing documentation? The wrong/outdated one.

Since unit tests are tied to build process, they would never outdate. Even better, they include maintenance effort to stay in a healthy state, welcome Living Documentation!

Brings light where you need it

Have you ever wondered how does Sitecore.Pipelines.HttpRequest.ItemResolver work?

Would it honor item display name over name, how does it deal with encode replacements or security access?

The logic must be guarded by vendor to avoid behavior changes, therefore code should have been covered with tests. And yes, should tests be public, you could debug it!

Shortcut for bug reports

A pull request with a failing unit test can reach Product Department the same day you’ve found it! You no longer need to spend ages to hand-pick reproduction steps to make Customer Service happy and raise a bug on your behalf.

Increases product code quality

Code must be in a good shape (f.e. without hidden dependencies) to become a subject for unit testing.

Summary

A framework consumer gets following benefits:

• Simplified learning curve, led by example
• Always accurate documentation
• Ability to verify system parts behaviors based on fed in data

A framework vendor gets in return:

• Accurate code-level bug reporting
• Automated documentation maintenance
• Increased code quality thanks to increasing safety harness