Question

Here’s what I have in my test so far:

[TestFixture]
public class IndividualMovieTests
{
    [Test]
    public void WebClient_Should_Download_From_Correct_Endpoint()
    {
        const string correctEndpoint = "http://api.rottentomatoes.com/api/public/v1.0/movies/{movie-id}.json?apikey={your-api-key}";
        ApiEndpoints.Endpoints["IndividualMovie"].ShouldEqual(correctEndpoint);
    }

    [Test]
    public void Movie_Information_Is_Loaded_Correctly()
    {
        Tomato tomato = new Tomato("t4qpkcsek5h6vgbsy8k4etxdd");
        var movie = tomato.FindMovieById(9818);
        movie.Title.ShouldEqual("Gone With The Wind");
    }
}

My FIndMovieById method goes online and fetches a JSON result, and that means it sort of breaks the principle behind unit testing. I have a feeling I have to mock this string response, but I don’t really know how to approach this.

How would you approach this particular unit testing?

Answer 1

In your second [Test], I would suggest not focusing on a specific return value from your FindMovieById method, unless you truly want to test that your given inputs should always result in “Gone With the Wind”. The test that you have seems to be a very specific test case in which a specific input number results in a specific output, which is something that may or may not change when running against your actual database. Also, since you’re not going to be testing against the actual web service, doing this kind of validation is basically self-serving – you’re not really testing anything. Instead, focus on testing how the Tomato class handles validation of the argument (if at all), and that the Tomato class actually invokes the service to get the return value. Rather than testing specific inputs and outputs, test the behavior of the class, so that if someone changes it in the future, the test should break to alert them that they may have broken working functionality.

For example, if you have input validation, you could test that your Tomato class throws an exception if an invalid input is detected.

Assuming that your Tomato class has some sort of web client functionality for requesting and retrieving the results, you could plug in some stub implementations of the actual web code, or mocked implementations to ensure that Tomato is in fact calling the appropriate web client code to request and process the response.