I'm sorry to have to say that I have to disagree with zwon - there are immense benefits to writing test harnesses for existing code - the principal one being the ease by which potential regressions can be caught and fixed before the code goes live - especially in cases where the maintenance is the responsibility of a (virtual) test team and the original developer(s) are no longer available. The sad thing is that, like Configuration Management (CM), most employeres/clients don't/won't see the benefits until the problem has bitten them (frequently, more than once).

You say ...compiled .exe, so they won't be running the test harness at all... - just because your end-user won't run the test harness shouldn't preclude your writing one and running the deliverable against it - testing is an essential part of quality assurance and altho' it won't, indeed can't, demonstrate that there aren't any defects, it should give you the confidence that, assuming you've written good tests, there is a significantly reduced probability of their existence.

From my own POV, I start by identifying and writing tests for...

• corner cases aka boundary/limit conditions
• typical operational/use cases

Just my 10 pen'orth...