These are chat archives for Snaipe/Criterion

7th
Jun 2016
Dominik
@kaidowei
Jun 07 2016 11:09 UTC
@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 UTC
Incidentally this gets fixed on bleeding with the introduction of nested tests
Dominik
@kaidowei
Jun 07 2016 11:11 UTC
okay, coo
l
Franklin Mathieu
@Snaipe
Jun 07 2016 11:12 UTC
because a parameterized test iteration of index i gets reported as suite::test::i
Dominik
@kaidowei
Jun 07 2016 11:12 UTC
but not on 2.2.1 right?
Franklin Mathieu
@Snaipe
Jun 07 2016 11:12 UTC
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 UTC
which value?
Franklin Mathieu
@Snaipe
Jun 07 2016 11:12 UTC
the parameter you pass
Dominik
@kaidowei
Jun 07 2016 11:13 UTC
no quick hack possible?
Franklin Mathieu
@Snaipe
Jun 07 2016 11:14 UTC
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 UTC
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 UTC
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 UTC
I see
Franklin Mathieu
@Snaipe
Jun 07 2016 11:20 UTC
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 UTC
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 UTC
your PR looks good to me
I'll merge it in when I get home
Dominik
@kaidowei
Jun 07 2016 13:27 UTC
cool :)
Dominik
@kaidowei
Jun 07 2016 13:58 UTC
well, I found a problem...
the actual parameter is now evaluated twice
Franklin Mathieu
@Snaipe
Jun 07 2016 13:59 UTC
oh, right
Dominik
@kaidowei
Jun 07 2016 13:59 UTC
therefore this construct leaks memory now: cr_assert_str_eq(result = strrpl("hallo", "", "e"), "hallo");
Dominik
@kaidowei
Jun 07 2016 14:12 UTC
what do you suggest?
Franklin Mathieu
@Snaipe
Jun 07 2016 14:13 UTC
Wrap the assert in a do { } while (0) and use two temporary variables, maybe
Dominik
@kaidowei
Jun 07 2016 14:32 UTC
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 UTC
use the cr_ prefix
this prevents collision
Dominik
@kaidowei
Jun 07 2016 14:33 UTC
yeah, right... damn I'm tired today, sorry
Dominik
@kaidowei
Jun 07 2016 14:57 UTC
maybe now :(
I hate memory management in C
Franklin Mathieu
@Snaipe
Jun 07 2016 15:00 UTC
That might just as well become a mantra, in the case of C :P
Dominik
@kaidowei
Jun 07 2016 15:00 UTC
unfortunately, yes
well, time to go home xD
Franklin Mathieu
@Snaipe
Jun 07 2016 15:01 UTC
Have a nice day
Dominik
@kaidowei
Jun 07 2016 15:01 UTC
ditto