
Ask HN: How do you come up with a set of test cases for your code? - gashaw
I&#x27;m interested to know what methods software developers and testers are using in practice.
How confident are you in your tests?
======
tcbasche
\- 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])

\- 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).

\- However in most cases, I cover off the typical use cases and I find, as
another commenter says, it's "good enough".

[1]
[https://hypothesis.readthedocs.io/en/latest/](https://hypothesis.readthedocs.io/en/latest/)
[2] [https://medium.com/@thomas.basche/testing-with-
hypothesis-26...](https://medium.com/@thomas.basche/testing-with-
hypothesis-26cd2b1a72fe)

------
mrburton
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.

In terms of the latter, you can boil it down to two aspects.

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?

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.

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. ;)

------
viraptor
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"

~~~
gashaw
What about cases where "good enough" is not enough? code that handles money
comes to mind.

~~~
viraptor
When you need to handle money correctly, you have more budget for testing to
do this correctly ;-)

