baylorrae / let.cs

Add convention to your unit tests.

Let.cs

When testing in C# it's not unusual to test instances of a class. The problem we all face is having a place to initialize our objects.

1. Create a field that is initialized and reset on [TearDown]?
2. Create a null field that is initialized during [SetUp]?
3. Duplicate the initialization in every [Test]?

All three of these are valid, and unfortunately, all three can be found in the same project and sometimes the same test!

namespace DoYourTestsLookLikeThis
{
    [TestFixture]
    public class InsertTearsEmoji
    {
        private UnitOfWork _work = new UnitOfWork();
        private Mock<IArticlesService> MockArticlesService { get; set; }

        [SetUp]
        public void BeforeEach()
        {
            MockArticlesService = new Mock<IArticlesService>(_work);
        }

        [TearDown]
        public void AfterEach()
        {
            // 😭😭😭
            _work = new UnitOfWork();
        }

        [Test]
        public void IndexShouldLoadPublishedArticles()
        {
            var controller = new ArticlesController(MockArticlesService.Object);

            controller.Index();
            MockArticlesService.Verify(service => service.Published(), Times.Once);
        }
    }
}

It's dangerous to go alone, take Let.cs with you 🤺

namespace HappyDance
{
    // This allows us to call +Let+ directly
    using static LetTestHelper.LetHelper;

    [TestFixture]
    public class ArticlesControllerTest
    {
        private UnitOfWork Work => Let(() => new UnitOfWork());

        // We can depend on other Lets
        private Mock<IArticlesService> MockArticlesService => Let(() => new Mock<IArticlesService>(Work));

        // It's so easy, why not move it here too
        private ArticlesController Controller => Let(() => new ArticlesController(MockArticlesService.Object);

        [TearDown]
        public void AfterEach()
        {
            // You may cry, but only once (see below 👇)
            LetTestHelper.LetHelper.Flush();
        }

        [Test]
        public void IndexShouldLoadPublishedArticles()
        {
            Controller.Index();
            MockArticlesService.Verify(service => service.Published(), Times.Once);
        }
    }
}

Flush the Cache 🚽

• After each test you will need to manually flush the results. My recommendation is creating a test helper that will flush the cache on tear down.

namespace MyProject.TestHelper
{
    [TestFixture]
    public class TestBase
    {
        [TearDown]
        public void Clean_LetHelper()
        {
            LetTestHelper.LetHelper.Flush();
        }
    }
}

Inspiration

Coming from Ruby I found instance management in C# to be, well, not fun. This is is influenced by RSpec let.

let.cs's Issues

An expression tree may not contain an assignment operator

I like the library! I'm new to C#, and I miss some of the sugar of ruby libraries, especially rspec's let.

I hand-rolled my own version of NBuilder, and was saddened to see that it made things incompatible with this library.

private Client client => Let(() => {
    return clientSeeder.Build().With(
        c => c.ClientName = "Main Client"
    ).Persist();
});

An expression tree may not contain an assignment operator

This isn't an issue, I just wanted to leave it here for the record.

add simple IoC

I find myself creating Let definitions that are dependent on multiple objects throughout the tests. For instance, all service classes may require a DbContext and a CurrentUserContext. These are often times centralized in a parent TestBaseand used throughout all the tests and manually passed into the construction class under test. The benefit is the class under test is explicitly defined and passing dependencies isn't unknown to the programmer albeit tedious.

My initial fear is that it will separate the class definitions and cause run time when executing tests due to the implicit nature of DI and I'm not sure if this would solve real problems since it wouldn't leverage the container defined in the application layer.

On the other hand, I don't like adding dozens of Let definitions to my tests that are used solely for the purpose of being passed into the class under test.

Definition Options

1. either construct classes from other Let definitions automatically
2. use Let() definitions that are explicitly defined for DI
3. injectable classes are configured separate from definitions
4. injectable classes are configured during the definition of the Let definition.