MVP Passive View -> Dependency Injection -> Factory Pattern -> Is testing behaviour whilst ignoring state enough?

Question

I am writing an application using the Model/View/Presenter passive view pattern.

I have view that contains multiple items in a list. My model is of type AudioDrama. For filtering that list I have classes that implement the interface IAudioDramaFilter.

public interface IAudioDramaFilter
{
    EAudioDramaFilterMode FilterMode { get; }
    IEnumerable<AudioDrama> Filter(IEnumerable<AudioDrama> audioDramas);
}

As you might see from the enum FilterMode I have several implementations of that filter interface.

public enum EAudioDramaFilterMode
{
    All,
    MainsOnly,
    FavoritesOnly,
    UnheardOnly,
    SpecialsOnly
}

My passive view has multiple events that raise as soon as the user requests/clicks a new filter. I.e. the user might click the favorites button and then the event FavoritesOnlyClicked is raised.

My presenter for that view subscribes to that kind of events:

_audioDramaListView.FavoritesOnlyClicked += OnFilterChanged(EAudioDramaFilterMode.FavoritesOnly);

In that OnFilterChanged method I set the filter field in my presenter to the correct filter by creating a new filter via the factory that is given as dependency to my presenter.

private EventHandler OnFilterChanged(EAudioDramaFilterMode filterMode)
    {
        return (sender, args) =>
        {
            _audioDramaFilter = _audioDramaFilterFactory.Create(filterMode);
            UpdateView();
        };
    }

Now I want to test all the logic. Since I give the factory to my presenter via dependency injection, I can simply mock it and verify that the correct Create method is called, i.e.:

 _listView.Raise(x => x.FavoritesOnlyClicked += null, this, EventArgs.Empty);

 _filterFactory.Verify(x => x.Create(EAudioDramaFilterMode.FavoritesOnly), Times.Once);

This works great. My problem now is that I only test whether the correct factory method was called. But I never tested whether the value actually was set to the private field _audioDramaFilter.

Should I make the field internal just to test that? Would that not hurt my encapsulation? Is there some design flaw I don't see? Because that would always be the case as soon as I use a factory instead of a static dependency. But I want to be able to change the implementation dynamically...

I write the question because it now happened another time: I implemented a sorter with a SorterFactory...

Thanks in advance for any help/ideas!

Answer 1

Should I make the field internal just to test that?

No.

The usual approach is to concentrate on observable behaviors, rather than implementation details.

In this case, how would you know that the filter had been assigned? Probably because changing the filter would also change the observable list of AudioDrama. That is, after all the thing you really care about -- the fact that you used a factory to create the dependency rather than doing it within the class itself isn't usually interesting.

It may help to think of your system under test as a function, that takes an unfiltered list and a filterMode as arguments, and returns a filtered list. Then figure out the implementation of that function, which will be some orchestration of the filter, the factory, and whatever other bits and pieces contribute to the math.