There are some advantages to how GTest does value parametrization, but the amount of boilerplate to get even the most simple parametrization going means that we have ton of basically duplicated tests.
With Catch2 these 12 tests I am looking at would've been 1, because the barrier to go from 1 concrete test to a value parametrized test is tiny.
@malwareminigun The advantage of for loop is that it is dead simple. But it is opaque to the test framework, so if you write test like that and want to investigate failure for specific input, you have to edit the sources.
With value param., you can filter down to the failing input just from the runner. This means that, e.g. if you know that test foo, input #23 fails on ARM and that's ok, you can specify this in your CI script, without having to hardcode the detection into the test itself.
@malwareminigun A further advantage of GTest's approach here is that it is also very simple to run the different inputs in parallel:
```
$ ctest -j 16
Start 1017: {test}/50
Start 1012: {test}/45
Start 1008: {test}/41
Start 1015: {test}/48
Start 1019: {test}/52
Start 1014: {test}/47
Start 994: {test}/27
Start 1013: {test}/46
Start 1009: {test}/42
Start 999: {test}/32
```
just look at it go :-D
@malwareminigun Catch2's advantage is that it is much simpler to start writing parametrized tests and that the value parametrization models input stream -- you don't need to know how many elements there are ahead of time, it does not even have to be deterministic.
Do you want to run 2 inputs to check for previous regression and then spend 100ms sending random ones? No problem. If the 6th generated input failed,
./SelfTest --rng-seed 2302301031 -g '7' 'my test'
and start debugging.
Xarn
Billy O'Neal