Whenever you write a program, it is important to construct test problems that exercise as many features of your program as possible. I've personal experience with programs containing errors that were not corrected for several years after their insertion, simply because that portion of the program was never adequately exercised by someone who knew what to expect of it.
I have generated a series of 9 test problems for the programs charvar.f and charvr90.f . Two of them test situations where processing will proceed normally (test.in, test1.in), and 7 test abnormal situations to see if the program is responding as I intended (bad.in, bad1.in, bad2.in, bad3.in, bad4.in, bad5.in, and bad6.in). Testing of response is very important, but frequently neglected. When a code responds clearly to incorrect or ambiguous input, it can save you a lot of time figuring out what went wrong, and keep the users of your program much more contented.
Once you establish a set of test problems for a program, you will want to run them from time to time to make sure that code changes have not destroyed some previous capability. To avoid unneeded typing and problems remembering the names of all your test problems, you should automate the process by writing a script in one of your computer's command languages. On a Unix machine this would be a "shell script" or when available a "Perle" script. I have provided a C-shell script named runit to exercise the above test problems.