- If it's a straight-forward pure function, I tend to use Hypothesis[1] to pile in random inputs. It's a great tool for coming up with cases humans wouldn't normally think of (I also wrote a blog post about this [2])<p>- If there was a show-stopping bug in production, I like to go back and write a test that covers that case (even if it was fixed).<p>- However in most cases, I cover off the typical use cases and I find, as another commenter says, it's "good enough".<p>[1] <a href="https://hypothesis.readthedocs.io/en/latest/" rel="nofollow">https://hypothesis.readthedocs.io/en/latest/</a>
[2] <a href="https://medium.com/@thomas.basche/testing-with-hypothesis-26cd2b1a72fe" rel="nofollow">https://medium.com/@thomas.basche/testing-with-hypothesis-26...</a>
This is exactly what TDD came about. It was designed to help you a) write code that you need and b) tests that validate the code does what it's suppose to do.<p>In terms of the latter, you can boil it down to two aspects.<p>a) Does the code function correctly given positive input?
b) Does the code fail in a deterministic manner? e.g., if an age is a negative number, does it' throw an appropriate error message?<p>In the failure case, it can get more trickier when you start to introduce things like database persistence or API calls. In this case, you should mock out these dependencies and also set up scenarios to make sure your code also fails in a deterministic manner.<p>Keep in mind, what's really important is to make sure your code only doesn't what's required and nothing more. Keep things simple and no simpler. ;)
Usually it's two groups: 1. regular usage as seen now or expected in the future, 2. exercising all existing error paths. I'm pretty confident that it's both a reasonable coverage and that there are going to be some missed patterns. It's "good enough"