Unable to get AutoFixture, FakeDb and NUnit3 combination to work

Question

Has anyone been able to get the combination of AutoFixure, FakeDb and NUnit3 to work?

I am unable to retrieve an item I have added to the database (using example from FakeDb AutoFixture wiki page); the test does not pass:

<package id="Sitecore.FakeDb" version="1.7.4" targetFramework="net472" />
<package id="Sitecore.FakeDb.AutoFixture" version="1.7.4" targetFramework="net472" />
<package id="AutoFixture" version="3.51.0" targetFramework="net472" />
<package id="AutoFixture.NUnit3" version="3.51.0" targetFramework="net472" />
<package id="NUnit" version="3.11.0" targetFramework="net472" />

---

[Test]
[AutoDbData]
public void AddContentDbItem(Db db, DbItem item)
{
    db.Add(item);
    var newItem = db.GetItem(item.ID);

    newItem.Should().NotBe(null);
}

However, if I bypass the NUnit attribute integration with AutoFixure, the test passes (but this loses a lot of the benefits I wanted when using AutoFixture):

[Test]
public void AddContentDbItem()
{
    var fixture = new Fixture()
        .Customize(new AutoDbCustomization())
        .Customize(new AutoContentItemCustomization());

    var item = fixture.Create<DbItem>();
    var db = fixture.Create<Db>();

    db.Add(item);
    var newItem = db.GetItem(item.ID);

    newItem.Should().NotBe(null);
}

This suggest to me that the issue is with the interaction between Sitecore.FakeDb and Autofixture.NUnit3 (rather then NUnit itself).

Also, if I change the testing framework to XUnit, the test will pass:

<package id="AutoFixture.Xunit2" version="3.51.0" targetFramework="net472" />
<package id="xunit.core" version="2.4.1" targetFramework="net472" />

---

[Theory]
[AutoDbData]
public void AddContentDbItem(Db db, DbItem item)
{
    db.Add(item);
    var newItem = db.GetItem(item.ID);

    newItem.Should().NotBe(null);
}

Has anyone been able to get the combination of AutoFixure, FakeDb and NUnit3 to work? NUnit has been the preferred testing framework in my company for years and there is reluctance to change just to solve this issue.

Answer 1

I will start my answer with a question, why do you need to use FakeDB?

Even though the idea of FakeDB is great in theory, it inevitably causes more issues than it solves, in my opinion, when testing units in your code, it's another story when you are carrying out integration tests, but then the argument would be why not manipulate a real Sitecore database.

What I would suggest that you consider is not test Sitecore is doing its job and only test business logic you are writing. You could use a pattern like Template Method to help write logic that does not know about Sitecore. You would completely control and mock these classes and then create implementations that can talk to Sitecore. These abstract classes would only use POCOs to build up functionality using TDD, mocking to your heart’s content, and then all the implementation does is map Sitecore items to those POCOs.

Unit testing aims to test a unit, or as I think of it test a single logical pathway through your code, the best way to do this is using contrived implementations of contracts. As soon as you introduce FakeDB you no longer have a single logical pathway, as really Sitecore code is being executed to carry out your test along with FakeDb code, effectively making the unit part of the unit testing moot. If you believe that Sitecore is not functioning as expected open up a support request as testing Sitecore is not your responsibility and only increases the about of testing code you must maintain.

I feel that when tightly coupling your business logic code to Sitecore you end up with code that is less maintainable and reusable. Be careful with trusting unit testing as it can quickly become a false economy if you are creating tests just to get 100% coverage. The coverage metric that is important is, am I testing all logical pathways? Oh and never change unit tests just to satisfy the compiler, this makes your tests rot. Your test are the most important part of a solution so treat them as such.

Sorry for the long answer, I did not think I had that much to say and think I will blog about this with an example of the approach I am describing.