Max Goldstein
Max Goldstein
> based on outdated knowledge ("Fuzz.andThen tests hang when not written carefully") I went back to every `Fuzz.andThen` issue and I think the current behavior (0.18.12 runner) is acceptable. #62:...
This is a really neat idea, and I think my objections are (1) it would make the already-complicated fuzzer code more so, and (2) we don't know what the performance...
@gampleman You have a type with a small, finite number of possibilities. If you want to test each value directly, as opposed to a list of them or something, I...
I don't think using a unit test for easily-enumerated, non-nested cases is a perf optimization. I think it's semantically correct. Fuzz tests should only be used when you can't possibly...
Apology accepted. The problem with automatically making fuzz tests smart is that it's hard to do. #167 is basically rolling back a perf optimization that had mixed results at best,...
Is this fixed by #183?
Current behavior: ``` ↓ Example ✗ #160 This test failed because it threw an exception: "Error: Ran into a `Debug.crash` in module `Fuzz.Internal` This was caused by the `case` expression...
Is this an issue with elm-test itself or the node runner?
> the individual test runs get flattened before execution I'm not sure this is true, otherwise the #127 bug wouldn't have happened, right? We do some deduplicating of results and...
> If print-based debugging is something we want to be able to do, that is. I suspect it is not. If you have to use print statements to debug your...