In a previous post, I discussed static abstracts in interfaces, and while it is quite a nice feature, it falls short in some corner cases – particularly in implicit type-conversions. I’m not sure if it should, but… it’s complicated. As an example, I will consider the concept of interchangeable units. Wouldn’t it be neat, if … Read more
In a previous post, we looked the newly introduced Assert.Multiple in the XUnit 2.4.2 assertion library. In this post, we will dive deeper into different ways of expressing tests and especially, test input. Facts are the simplest possible test-case in XUnit. They are self contained in that they contain the arrangement, act ,and assertion, but … Read more
Multiple asserts in test-cases are considered bad practice. The usual reason for this, is that if one assert fails, you will never se the result of the rest. And probably true, having a single assertion, improves defect localization and simplifies the tests. But sometimes… sometimes you wish you could have multiple conditions; and that it would be ok.
In xUnit test cases can be parameterized using the attribute [InlineData] much like [Datarow] in MsTest. That is, instead of stating a [Fact], you can create a [Theory] and parameterize it, much like this example: Here we created four testcases using a general parameterized theory. This allows you to rapidly gain coverage without the boilerplate … Read more