Testing

I’ve released NCheck V4, largely tidy up and removal of legacy code and changed the framework to support net472, net48 and netstandard2.0.

The dictionary/list checking has been reworked as well so we can get per-element reporting e.g. if we look at the list test fixture we can see which elements are not in alignment,

We now get error messages like this…

SampleList.Children
Count: Expected:<3>. Actual:<2>
[1].Id: Expected:<2>. Actual:<4>

Useful when you have more than a couple of items in the list.

NCheck V3, has just been released, not much change but it does now support net35, net452, net462 and netstandard1.5 and above.

One of my current projects is using SpecFlow for testing some complex security logic; there are lots of scenarios so the BDD style of testing is well suited to the problem. I wanted to use the same style of testing for some integration testing where the client is talking to my API but hit a problem of how/where to construct the container as even the client library uses dependency injection to construct itself.

Updated NCheck, my test object comparison helper, to version 2.3 which…

• Introduces a new technique to wire up conventions
• Supports multi-threading e.g. test fixtures using NUnit Parallelizable

Customizing the CheckerFactory

The CheckerFactory has a number conventions which are used to automatically construct Checkers for each class; these conventions can be overridden by the developer if they don’t suit a particular scenario.

We support…

• Type conventions: Applied to all instances of a particular type
• Property conventions: Applied to properties which satisfy a function e.g. matching a particular name
• Comparer conventions: Operates on a type or property convention and changes Value comparison from object.Equals to a specified comparer; useful for values such putting error bound on floating point comparison.

The suggested technique for this is to introduce an extension class to hold the factory methods

Updated NCheck, my test object comparison helper, to version 2.2 which extends ICheckerFactory to support Compare<T> - this allows us to override checkers on a per-test basis which I’ve found useful on some of my current projects.

Customizing the CheckerFactory

The CheckerFactory has a number conventions which are used to automatically construct Checkers for each class; these conventions can be overridden by the developer if they don’t suit a particular scenario.