Understanding unit testing

Question

I'm trying to understand how unit testing works. So far i understand you're testing the output of functions based on what you put in. Ok. Does that mean if your function has the only possibility of returning one datatype you only have to write one test for it? So say i write a function that only has the possibility of returning TRUE or FALSE, does that mean i would just be checking if the response is boolean?

And then also say i have a function that is pulling posts from a blog from a database. Say have the function set to: if number of rows = 0 return FALSE, else return the results. So i now i have the possibility of a function that could return a boolean value or an array. How the heck do you test that? The function now doesn't rely solely on the input, it relies on what's in the database.

Answer 1

You have the gist of it about right. If there are external depecnencies for the unit there are two approaches. creating a Mock class or using some kind of fixture.

Using your DB example if youre testing a class that has to call on a data access class to pull data from the database then you would typically Mock that data access class, making the methods you plan on calling from it return the response you expect.

If on the other hand you were actually testing the data access class itself then you would use a fixture - a test db filled with data you know. And then test that the data access class returned the right data.

Answer 2

A useful function does not return true or false randomly. It returns true under certain circumstances and false under other circumstances.

A unit test would therefore do three things (in that order):

1. Create an environment from which you know whether the function should return true or false (this environment is called the test fixture).
2. Run the function that is to be tested.
3. Compare the result of the function with you expectations.

Obviously this cannot be done with all possible inputs (if it could be done, this would be a proof, not a test), so the art of unit testing is choosing appropriate test fixtures. There are two ways to go about this:

• Black box testing looks at the specification of the function to choose the fixtures: what are the valid input values and how should they influence the output?
• White box testing looks into the function and chooses fixtures such that every statement of the function is executed by at least one fixture.

... if number of rows = 0 return FALSE, else return the results.

If such a function directly sends a query to a database server by calling an API of the DBMS (e.g. mysql_query), the creation of the test fixture would include

1. Setting up a database.
2. Inserting rows into the database (or not, depending on whether the test should check that the results are returned properly or FALSE is returned properly).

If, on the other hand, that function calls a custom function (e.g. provided by an object-relational mapper), then the test fixture should provide a mock implementation of that custom function. Dependency injection helps to ensure lose coupling of caller and callee, so the real implementation can be replaced with the mock implementation at runtime.