These are chat archives for Snaipe/Criterion

7th
Jun 2016
Dominik
@kaidowei
Jun 07 2016 11:09
@Snaipe a colleague just pointed out, that it is hard to debug ParameterizedTest because the Assertions don't tell, which parameter failed.
Is there a quick solution, like echoing the array index?
I guess, the better solution would be to provide a tostring function for the array-type. (We already talked about that)
What do you think?
Franklin Mathieu
@Snaipe
Jun 07 2016 11:11
Incidentally this gets fixed on bleeding with the introduction of nested tests
Dominik
@kaidowei
Jun 07 2016 11:11
okay, coo
l
Franklin Mathieu
@Snaipe
Jun 07 2016 11:12
because a parameterized test iteration of index i gets reported as suite::test::i
Dominik
@kaidowei
Jun 07 2016 11:12
but not on 2.2.1 right?
Franklin Mathieu
@Snaipe
Jun 07 2016 11:12
but in the meantime, the only thing you can do is print the value manually in the assertion to see which one it is
yeah, not in 2.2.1 yet
Dominik
@kaidowei
Jun 07 2016 11:12
which value?
Franklin Mathieu
@Snaipe
Jun 07 2016 11:12
the parameter you pass
Dominik
@kaidowei
Jun 07 2016 11:13
no quick hack possible?
Franklin Mathieu
@Snaipe
Jun 07 2016 11:14
in a nutshell, you have to pass a format string like "Why the assertion failed: value = {%d, %s, ...}", param->some_int, param->some_string, ...)
Or even sprintf at the begining the value = {%d, %s, ...} in a fixed string (like the tostring you mentioned)
and include it in your format strings
This is just a dirty workaround of course
Dominik
@kaidowei
Jun 07 2016 11:16
yeah, but that feels manual and dirty.
isn't there a hidden global var, that contains the parameter index?
Franklin Mathieu
@Snaipe
Jun 07 2016 11:17
what you could do is maybe do some pointer arithmetic
store your array in a global variable
then do (array - param) / sizeof (struct your_param)
this will give you your index
but you'll still have to include it in every assertion message
so it's equally painful as the first solution
Dominik
@kaidowei
Jun 07 2016 11:18
I see
Franklin Mathieu
@Snaipe
Jun 07 2016 11:20
Hopefully I will be able to work on #118 soon (which is the current major release stopper) and address this issue properly
Dominik
@kaidowei
Jun 07 2016 11:44
I analyzed the code and I guess, it would be possible to extend struct test_single_param to store the index and then provide another parameter for parameterized tests, that holds the index
but as it will be fixed in the next release I'll just tell him to wait
we're you able to have another look at #124?
Franklin Mathieu
@Snaipe
Jun 07 2016 11:51
your PR looks good to me
I'll merge it in when I get home
Dominik
@kaidowei
Jun 07 2016 13:27
cool :)
Dominik
@kaidowei
Jun 07 2016 13:58
well, I found a problem...
the actual parameter is now evaluated twice
Franklin Mathieu
@Snaipe
Jun 07 2016 13:59
oh, right
Dominik
@kaidowei
Jun 07 2016 13:59
therefore this construct leaks memory now: cr_assert_str_eq(result = strrpl("hallo", "", "e"), "hallo");
Dominik
@kaidowei
Jun 07 2016 14:12
what do you suggest?
Franklin Mathieu
@Snaipe
Jun 07 2016 14:13
Wrap the assert in a do { } while (0) and use two temporary variables, maybe
Dominik
@kaidowei
Jun 07 2016 14:32
yeah, that's what I thought. Don't like that, because you could shadow some variables, but it works.
char *__str_actual = (Actual); do you have a better idea for name mangling?
Franklin Mathieu
@Snaipe
Jun 07 2016 14:32
use the cr_ prefix
this prevents collision
Dominik
@kaidowei
Jun 07 2016 14:33
yeah, right... damn I'm tired today, sorry
Dominik
@kaidowei
Jun 07 2016 14:57
maybe now :(
I hate memory management in C
Franklin Mathieu
@Snaipe
Jun 07 2016 15:00
That might just as well become a mantra, in the case of C :P
Dominik
@kaidowei
Jun 07 2016 15:00
unfortunately, yes
well, time to go home xD
Franklin Mathieu
@Snaipe
Jun 07 2016 15:01
Have a nice day
Dominik
@kaidowei
Jun 07 2016 15:01
ditto