Use multiple functions of the SUT in one Unit Test

[Daissy538]

Hey everyone,

@valentinacupac.
I have a question that came to my mind, when watching the mob https://www.youtube.com/watch?v=kyG_ljVF3cA&ab_channel=TechExcellence

I thought that testing business logic in isolation/unit meant that you only use one function of the SUT in that Unit Test. 
However, in the example, Take() was called multiple times as an arrange, followed by the ACT GetCurrentPlayer(). (https://youtu.be/kyG_ljVF3cA?t=3498)
In this case, does isolation/unit mean a set of actions that reassemble a business flow?

Can an ACT be more than testing one function, that has a busness flow behind it?
And if true, should the individual functions also be tested separately?

Greetings!

[marciovmartins]

Hi @Daissy538 , there is not one unique way to do it. Every way has positive things and drawbacks.

If you want to have one call to the SUT per test method, there will be the need to setup the system to the point where it is possible to test what you want.

To learn and get used to TDD, this is the best approach.

[Daissy538]

Thanks for the reaction @marciovmartins! I understand that there are multiple approaches to it. The thing is, I don't have many examples of experienced programmers around me. So I sometimes feel a bit lost. At the moment, I'm trying out the following approach:

Arrange - With a mocked repository and a setup return value
Act - The SUT function I want to test
Assert - Check the return value of the SUT and/or check if the mocked repository is called.

But I understand that other setups/situations need a different approach. I'm interested in different approaches, so I can learn from it.

[marciovmartins]

What I meant is that you're going to choose the best way for the project and situation that you have. There is no silver bullet or best approach.

Using the approach you mentioned and answering the comment below from @nikoheikkila works very well for not so complex domain. The drawback is that the tests are more coupled with the implementation and you are going to need to implement more tests, more setups, more assertions.

If you decide to refactor your classes for any reason or your domain evolves, you would need to touch those tests again. So, basically your test is not protected against infrastructure changes. This is one of the flaws of the mockist way to do test. But like I said, its very suitable for less complex domains or domains that don´t change/evolve often. I saw a few times projects with that were a simple change like adding a new property to some class would make several tests to break and need to be touched/fixed.

See @valentinacupac answer: #40

For complex domain and if you are using the Hexagonal or Onion Architecture, I split my tests in two layers, the domain/application unit tests and the infrastructure integration tests.

Unit tests for the domain/use cases are more suitable, here you're going to test all the use cases (and by consequence your domain) with validations and different workflows. The infrastructure, like the repository, are going to be replaced by some test double, I use more often the Fakes because the implementation are simple and in memory.

And for the infrastructure layer, like the repository, the integration test would be used to validate against a real database with all the foreign keys, migrations etc.

And the controller would have a integration test mocking the use cases (or services), because the goal here is to validate the 2xx, 4xx and 5xx responses.

For CRUDs, since usually they are very simple, just an integration test is enough going from the controller to the database.

[nikoheikkila]

I have been using an approach where I prepare, e.g. an object repository to hold relevant data before calling the method under test.

// Arrange
service.repository.insert([
    // ...what you need
]);

// Act
const result = service.workOnIt();

// Assert
expect(result).toBe(/* ... */);

This makes testing more convenient as I don't have to bloat the Arrange part of the test body and I have already satisfyingly covered the other methods that I would have used there.

[Daissy538]

Hey @nikoheikkila. That sounds similar to my approach.But I mock the repository.
It's difficult for me not to blow up the arrange part when testing the update business logic.
Most of the time, the arrange section becomes very large and difficult to reed.

I'm used to the Layerd Architecture. I do have a feeling an Onion Archicture setup can make a big difference.
Below is an approach I'm trying out in a small private project:

    private IUnitOfWork _unitOfWork;

    public GroupServiceTest()
    {
        userRepositoryMock = new Mock<IUserRepository>();
        groupRepositoryMock = new Mock<IGroupRepository>();
        subscriptionRepositoryMock = new Mock<ISubscriptionRepository>();
        colorRepositoryMock = new Mock<IColorRepository>();
        iconRepositoryMock = new Mock<IIconRepository>();

        var dbContextMock = new Mock<TaskItDbContext>();
        this._unitOfWork = new UnitOfWork(dbContextMock.Object, userRepositoryMock.Object, groupRepositoryMock.Object, subscriptionRepositoryMock.Object, colorRepositoryMock.Object, iconRepositoryMock.Object);

    }
         [Fact]
    public async Task Update_Group()
    {
     
        //Arrange
        var userId = 1;

        GroupService groupService = new GroupService(this._unitOfWork);
        Color color = new ColorBuilder()
                            .WithID(1)
                            .Build();

        Icon icon = new IconBuilder()
                    .WithID(1)
                    .Build();

        Group existingGroup = new GroupBuilder()
                                    .WithColorId(color.ID)
                                    .WithIconId(icon.ID)
                                    .WithId(1)
                                    .Build();

        groupRepositoryMock.Setup(u => u.FindGroupOfUserAsync(existingGroup.ID, userId)).ReturnsAsync(existingGroup);

        Group updateGroup = new GroupBuilder()
                                    .WithColorId(color.ID)
                                    .WithIconId(icon.ID)
                                    .WithId(existingGroup.ID)
                                    .WithDescription("New")
                                    .Build();
        //ACT
        Group result = await groupService.UpdateAsync(updateGroup, userId);

        //ASSERT
        Assert.NotNull(result);
        Assert.Equal(updateGroup.Name, result.Name);
        Assert.Equal(updateGroup.Description, result.Description);
    }

[nikoheikkila]

It's difficult for me not to blow up the arrange part when testing the update business logic. Most of the time, the arrange section becomes very large and difficult to reed.

This is not always bad, but consider it an opportunity to listen to your tests. They are trying to tell you something about complexity and coupling.

For example, can you replace some arguments to your dependencies with null or omit them entirely? At the very least, can you abstract some common setups to a particular setup method or a fixture (depending on the test runner used)?

[Daissy538]

Thanks @nikoheikkila and @marciovmartins,

My next learning step will be to learn more about different architectures and then try them out within a new branch of my own project. I understand that Unit Testing and architecture are influencing each other more than I realized. Thanks for pointing it out in my code!