On Tue, 18 Dec 2007, Johan Dahlin wrote:
> Sorry for being late in the game for comments, but here we go.
>
> In general this api differs slightly from JUnit/python, which has the
> following (main) methods:
>
> assertEqual
> assertNotEqual
> assertTrue
> assertFalse
> assertRaises
yeah, i've looked at the JUnit API when designig the glib test API, but
didn't find those assertions to be too applicable. e.g. there's not too
much difference in:
g_assert (condition == TRUE);
g_assert_true (condition);
g_assert (condition == FALSE);
g_assert_fail (condition); // suggested by Behdad
if people strongly feel those need to be added we can do that, i just
fail to see a significant benefit.
> Perhaps the term "equals" could be used instead of "cmp".
the existing API uses "cmp" because it implements memcmp(3) result semantics,
i.e. -1,0,+1 instead of eaqulity ('==') semantics.
for int/hex/float, this should obviously make sense, and for strings it
mimicks the most common comparison API, i.e. strcmp().
> I haven't looked in detail at the trap api, but having something similar to
> assertRaises for g_error & friends would be a good thing.
hm, i'd say the closest thing to assertRaises in glib *is* g_error().
maybe you meant GError? that might be useful to have, patches welcome ;)
> g_assert_cmpstr, accepts a comparison operator, while this makes sense for
> comparing floats and integers I don't think it should be included in the api
> for strings.
> Basically, the only thing you want to check if is a string is equal to
> another or not, so perhaps it could be replaced with:
>
> g_assert_equals_str
> g_assert_not_equals_str
>
> Or do you see a use case for using other operators besides == and != ?
sure, if you use strcmp() to sort a list of strings, you'd use
g_assert_cmpstr() to test the invariants. and as i wrote above, offering
'cmp' here instead of 'equals' is what C coders are most used to anyway
(and consistent with the other g_assert_cmp*() variants).
keep in mind that the g_assert_*() family is about convenience anyway,
everyone is free to fallback to g_assert() or if(...)g_error() for his
checks.
a remaining issue i see with g_assert_cmpstr() however is that we should
probably also have g_assert_casecmpstr(), similar to g_strcasecmp().
> Johan
---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
