I'm not convinced I understand your question, but I think I get part of it.  I think approaches where you munge the input to make it fit your expectations are almost always wrong.  They tend to lead to subtle problems and overcomplication.  Consider HTML in the early days compared to more recent developments in that area.  Back in the late 90s and early 2000s browsers were being made that just magically accepted invalid HTML and silently interpreted it in whatever ways the authors felt like.  Things aren't perfect now, but I think it's been getting better by having the implementations be pickier about malformed input.

As for building extensive data tests, I'm not sure what you mean here.  I would have to see examples.  Often if you have a solid parser that throws detailed errors on invalid input then you're good to go right?  And of course, you don't want to let garbage into your program.  That's going to lead to headaches.

 

Jason