How should I be unit testing the search process of a web app

Question

A lot of the examples for unit testing that I see involve testing that numbers add up. For example, Derek Greer demonstrates unit testing a calculator app, making sure that the equals function does what it is supposed to do (http://lostechies.com/derekgreer/2011/03/14/effective-tests-a-unit-test-example/).

I see how you could write a series of unit tests for something that needs to perform accurate calculations. But the application I am working on at the moment is an intranet / content management system and doesn't perform any calculations. The vast majority of transactions involve the user sending a request to the API, which hits the database and returns JSON.

I am not really sure where to start unit testing an app like this. Take the search process. Which bits of the API for searching should I write unit tests for? I've read about mocking and stubs to replace database calls (which confuse me), but I've never really understood why I shouldn't test responses from the database. Why is this?

Answer 1

Unit testing aims to test a single piece of code, which usually provides a single function. Database querying belongs to an API in your case and it is transparent to your app, so you cannot test a database with unit testing in your app. Let's say you would like to sort json results from API search. To test the sorting method you can have,

public SearchResult sortSearchResult(ApiInterface api, Stirng keyword) {
    String result = api.search(keyword);
    // return 
}

You can provide a stub during unit testing with implementation on method search,

public class ApiStub implements ApiInterface {
    @override
    public String search(String query) {
        if (query.equals('order1')) {
            // return result in arbitrary orders
        }
        if (query.equals('malformed')) {
            // return malformed json 
        }

        // return empty result
    }
}

And in unit testing you can use the following formula to see what happens when the API returns different results,

assertEquals(/* expected result */, sortSearchResult(apiStub, /* test queries*/));

The reason of not testing the database results in unit testing is because it increases the size of the test (Google Test Sizes). Large test size falls into other test categories such as end-to-end test and integration test, which introduces other non-deterministic factors and runs slow. In this question you asks about unit testing so we better stay away from other tests first.

Answer 2

You want to have known database, so results are what your test expect. if someone is changing the database, results might not match what your test expect, and tests will fail.

One way is to use mocks and stubs. Another way is to use database with known data which change in controlled manner (and you will have to fix your test if they will break as a results of changes in database). Known data might be as simple as one/few user account(s) for automated testing, and manual testing with unexpected (for your tests) changes will be walled off.