In addition to what Alison said about actually having code that will compile...
The important thing is that you test around the boundaries where interesting things are happening - in this case where the conditionals are changing. So in your case look at values of a around 100 and values of b around 1000. In addition there's a couple of cases where a = b might be interesting.
How you write the tests depends on how confident a programmer you are. If you're just starting out in C keep the tests simple:
assert( fun( 50, 50 ) );
where assert is a macro that checks whether a statement is true. It's defined in assert.h - you also need to have DEBUG defined to use it.
If you're a bit more confident then you could try a table driven approach. Define a structure with a value of a, a value of b and the expected value of feeding those values into fun:
struct fun_test
{
int a;
int b;
bool expected_result;
};
Each of these structures defines one test:
struct fun_test test1 = { 50, 50, false };
you can then write a helper to process the test:
void process_fun_test( struct fun_test_definition *to_test )
{
assert( fun( to_test->a, to_test->b ) == to_test->expected_result );
}
The last thing you do is create an array with all the tests you want to carry out in it and then iterate through the lot. This is, however, getting more towards a general unit testing framework and is probably overkill for your needs.
Cheers,
Ash
PS:If you're interested in a different philosophy of unit testing look up Test Driven Development online. With TDD you write tests before you write the code and the tests act as the specification of the code.
PPS: If this is homework for a course make sure you pull the correct buzzwords from your textbook when describing your solution.
PPPS: No idea if this code even works, I haven't checked it on a compiler.
PPPPS: Line removed that showed I didn't read Alison's comment - and to add insult to injury I was spelling her name incorrectly as well. Time for a lie down methinks.