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: 
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.
I should point out that unit testing is not just about what results your functions give out; it's also about how they mutate / impact other objects, as well. In a sense, they test what messages are passed between objects.