On Mon, 2010-06-07 at 17:31 +0200, Christian Hilberg wrote:
> Hi there,
> while the project setup process is going on, I've had a look again at 
> suitable 
> testframeworks. Unfortunately, many unit test frameworks for the C language 
> appear to be abandoned.
> On Wednesday 26 May 2010 at 12:18:04 you wrote:
> > Hi Christian,
> > On Wed, 2010-05-26 at 11:15 +0200, Christian Hilberg wrote:
> > > We'll check that out with other Gnome projects. It may take some more
> > > research on the project itself before we know how to actually accomplish
> > > the testing stuff. My thoughts atm tend towards cunit/expect and/or the
> > > GLib testing framework.
> >     I think the consensus from 10k feet is something like:
> >     any unit tests are good ! wow, you have unit tests ? cool !
> > :-) so it is unlikely that anyone is going to come and gripe about your
> > unit testing framework per-se; of course people moan about new
> > dependencies - so re-using the gtestutils.[ch] would be good if it's
> > easy, and of course most preferably hooking it all up to 'make check' is
> > best, as Matthew said.
>   Using the GLib framework for testing seemed to be a natural choice, until I 
> dug through the mail archives and found that it
> (a) is neither nice to set up for projects outside GLib/GTK istelf [1]
>     (latest information I found on the issue dates back from 2008)
> (b) nor is it well-documented and finally
> (c) does not seem to be in wide use outside GTK and GLib itself.

I've used the GLib test framework extensively for one of my projects,
libgdata[1], and it's fine to use outside of the GLib/GTK+ trees.
Several GNOME projects make use of it (more than other test frameworks
in my experience).

The GLib test framework can fork() tests using g_test_trap_fork() and


[1]: http://live.gnome.org/libgdata

> Other testframeworks I've checked (like CUnit, cUnit, RCunit, CuTest, 
> Embedded 
> Unit) did not receive project updates since 2006 (some since 2003), so I 
> assume they're dead.
>   Setting aside commercial frameworks, which are no option unless they're 
> explicitly FLOSSed, I'm left with
>       Unity[2], Cutter[3] and Check[4].
>   Cutter depends on GLib >= 2.16, so I assume it uses the GLib testing 
> framework internally and I found references to it in some GTK/GLib context. 
> What's more, Cutter has support for GLib types (just read in the docs, no 
> practical experience as yet), which would be helpful in our case.
>   Check seems to be in wider usage. It fork()s a new process for each unit 
> test it runs, which seems to be a good thing to do to protect the framework's 
> address space from runaway test cases, unless you're so much restricted (as 
> in 
> some embedded environments), that you cannot fork() - but there is no point 
> in 
> running E-D-S in such an environment, anyway.
>   Unity (also) targets embedded contexts and the Sourceforge project is alive 
> (latest release 2009-12-07, current checkins to the SF repo). There does not 
> seem to be much of a documentation online.
> Long story short, as for now I'm down to either Cutter or Check to use. I'd 
> like to know if you prefer one over the other, which I would like to take 
> into 
> account for my proposal to the other project members regarding the 
> testframework to use.
> Best regards and aTdHvAaNnKcSe for any insights,
>       Christian
> [1] http://www.mail-archive.com/gtk-devel-l...@gnome.org/msg07185.html
> [2] http://sourceforge.net/apps/trac/embunity/wiki
> [3] http://cutter.sourceforge.net/
> [4] http://check.sourceforge.net/
> _______________________________________________
> evolution-hackers mailing list
> evolution-hackers@gnome.org
> To change your list options or unsubscribe, visit ...
> http://mail.gnome.org/mailman/listinfo/evolution-hackers

Attachment: signature.asc
Description: This is a digitally signed message part

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to