To follow on from what pg has mentioned, what you're after is control. You need to build your own data and seed it with results you will expect to see foreach type of test case, postive, negative, and any boundary conditions that may apply. As you know what the data is, you can safely expect to see your it in your output.

After the unit tests are successful (and documented, being careful to retain the data, and making sure all the tests are reproducible) it generally a good idea to grab some production data and perform another series of tests...

From here you can sumbit you system to UAT (User Acceptance Testing) and final QA and signoff by the owners of the process/procedure or whatever.

Depending on youre environment, Unit Testing that is well documented may be enuff, however keep in mind, your goal, is to prove your programming works as advertising. The required level of proof will differ from site to site, however IMO, one should at the very minimum have fully documented test cases at the Unit Test level.

Also having someone test your system who has not been involved in the design/coding is generally a good idea as they bring a fresh set of eyes and ideas that you may not have considered.