Re: GLib Testframework API

[Tim Janik <timj imendio com>]

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