Writing S.O.L.I.D. code doesn’t only apply to your domain model, UI code etc.. – but in fact also your test code!
In xUnit writing tests usually includes writing a bunch of methods with the attribute [Fact]. Yet when one wants to test the same Fact (or test) on a set of data, it can get messy… And thus, during my travels through automated testing I used to create a test and within the test a foreach loop over a given set of data, but that was before I discovered [Theories] in xUnit!
Facts are tests which are always true. They test invariant conditions.
Theories are tests which are only true for a particular set of data.
I was confused by those definitions at first. But, to me, it boils down to this: one can group a certain set of data and run it through the same test.
So where’s the benefit then, as I used to to do it with an inline foreach loop… Ok, so, theories have the added benefit that you can upfront declare, reuse and extend that data – and when the tests run, the testrunner will explicitely show results for each data item that was run through the test. This makes it easy to track which “case” (data) made the test fail – in stead of relying on an inline foreach-loop inside your traditional [Fact] test. Which results in (re)usable tests and reusable parts of code in your tests and easier trackability as mentioned before.
Last but not least, you can load the data inline, from Excel, from a Member (e.g. a method or property)…
For a more in depth overview, check this blogpost by Pankaj K: http://ikeptwalking.com/writing-data-driven-tests-using-xunit/.