The goal of unit testing is not to test all possibilities of input versus output.
The goal of unit testing is to test each and every business rule, and within the scope of each business rule, all the potentially problematic cases. (Also known as "edge cases".)
So, basically, if your user gives a specific, known-in-advance piece of input, (which has been hard-coded into the test,) does your code yield a specific, known-in-advance piece of output (also hard-coded into the test) ?
And, if your user gives an empty string, does your code behave?
And, if your requirements say that your user must be able to type up to 10,000 characters, does your code in fact handle 10,000 characters? And does it fail gracefully (with a proper exception, which would later be translated to an error message to the user) if the user supplies 10,001 characters?
Also, code coverage is a measurement of how good your unit testing is, not in the sense that if you have 100% code coverage then you are good to go, but in the sense that if you have significantly less than 100% code coverage then it is possible that you have missed something. So, use a code coverage tool to see what parts of your code are not covered by your tests, and if any of them is crucial, then construct a test case in such a way that this piece of code will be covered.