Unit tests are not "unit" tests if they test things other than the System Under Test (SUT).

WEBINAR:

On-Demand

Getting Sample Data

Next, you know that the presentation model must get the data somewhere, and you've established it uses the repository object for that. Therefore, you must provide your StubRepository object with some sample data. Add the following lines of code to that stub class:

Nothing special going on there: the SetFakeData method lets you feed some data into the repository so it can give the data to the presentation model when requested. Remember that this is used only by your unit tests; normally the repository is likely to get that data from a database or something similar.

But wait, you have not implemented any querying methods on your StubRepository, so you must do that too:

As you can see, the querying methods are trivial: GetAllVideos simply returns the list you'll send to SetFakeData, and GetAllVideosOfType will return items that match the given criteria. You write as little code as possible.

With those changes in place, you can adjust the FixtureSetup in your new test class as follows:

It'd be great to be able to create fake objects dynamically as you need them, and that's where a mock framework comes in handy.

Listing 1 contains the parts of VideosListPresentationModel that are relevant to the last three tests you've just created. I've hooked up the event handler for the VideoListRequested event in the class's constructor. The handler updates the CurrentVideoTypeFilter property, and calls either GetAllVideos or GetAllVideosOfType methods on the repository, depending on whether the user specified a filter; in either case, the code returned results in the VideosList property.

Considerations on Static Fake Objects

For the six tests you've written so far, you've created two static fake classes: StubView and StubRepository. You should recall that for the first three tests (the ones validating the initial state behavior of the presentation model), you created the fake classes with the bare minimum implementation. However, for the second set of tests (the ones that validate the list retrieval behavior) you've had to make changes to those fake classes, to fit the context for the tests.

What if the changes you've made to support the second set of tests had broken the first set of tests? That wouldn't be good. And what if, in order to write the remaining tests for this presentation model, you have to make even more changes to the fake classes? You could end up adding if blocks, switch blocks, or more things of that sort to support the different contexts for different tests. That would turn your fake classes into a big mess, and you don't want that.

Another possibility would be to create one set of fake classes for each specific context required by your tests, which could also turn into a maintenance nightmare.

Wouldn't it be nice to just use some sort of framework where when you can simply request an object that implements an interface, and specify the results to return for any specific method? In other words, it'd be great to be able to create fake objects dynamically as you need them. That's where a mock framework comes in handy.