Also, as a last resort users will tell me if something is off.
Also, as a last resort users will tell me if something is off.
Just because you wrote it doesn't mean it's doing what you think it is.
And users really can not be counted on to report errors. Even if they do, the average bug report reads something like "So I put in your address into the google, but when i got there nothing came up! I tried over and over, but every time I clicked on the google, nothing happened! I asked my brother's boss' kid, who's a real whiz with computers, and he told me I should 'eat my cookies' or something, but I'm lactose intolerant!!"
Also, I'm not a junior programmer that needs someone looking over my shoulder to make sure I've implemented a spec correctly. Saying it doesn't do what I think it is doing is like saying that I may not exist even though I think I exist.
Therefore if you're taking short-cuts, the possibility that your code is doing something other than what you think it is is realistic, not ludicrous. Now it may be appropriate for you to take those shortcuts. But you shouldn't take them without being honest with yourself about the risk.
And what "risk" are you referring to? As I've stated, I decided to side with "more features" than "100% test coverage". Sure there is "risk" that there are bugs, but a) there are bugs regardless of how much testing you do and b) I've decided I'd lose users because I don't have features that stand out above the competition rather than because a minority of those features have minor bugs. So to me, the bigger risk is not developing more features.