You stop when you have "enough." Enough is a business decision, not really a technical one. Depending on your managers and the corporate culture, "enough" might be zero because any time spent writing tests is time "wasted" that should have been spent writing features and getting it out the door (because they miscalculated the time it takes to get it done in the first place and wouldn't you know it, stuff is "late" again).
My preference is to write enough to give me confidence that the code works. Usually that is a couple of edge cases and a sanity check or 2. Whenever bugs get reported, I'll write up a test to duplicate the reported bug and add that to the test suite. In the absence of someone telling me otherwise, these tests get named stuff like "TestBug2078A" where 2078 is the bug number in the reporting system and the subsequent letters indicate that there are several tests to cover the bug report. Named this way, it is blindingly obvious to even the most clueless maintainence coder that they better not comment out this test if their "fix" breaks this test. When you've been working out in "the wild" long enough, you will learn that there is no limit to the dumbness that can happen.