3 ms·
I feel like any time I've run into a situation like this, the function body is either a trivial `if` statement, or it's dependent on some complicated state. In
by fwip 2y ago
I feel like any time I've run into a situation like this, the function body is either a trivial `if` statement, or it's dependent on some complicated state.
In the former, truth-table testing doesn't really add much value, and in the latter, I'd reach for hypothesis testing/fuzzing.
That said, writing exhaustive truth-table test doesn't look so bad with table-driven tests, like:
tests = [
#logged_in, green_hair, likes_bananas, msg_shown
(true, true, true, true),
(true, true, false, false),
...
]
for t in tests:
assert(foo(t.0, t.1, t.2) == t.3)
- randomdata 2y ago> I'd reach for hypothesis testing/fuzzing. These tend to be not so great at documenting intent and usage, though, which is the primary goal of your tests. Generally, I'd reach for both – offering a limited number of clearly defined tests to demonstrate common usage to future readers, while letting the fuzzing, etc. sort out the rest.