Hi, 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  > (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, 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 friends. Regards, Philip : 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, Cutter and Check. > > 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 > > >  http://www.mail-archive.com/gtk-devel-l...@gnome.org/msg07185.html >  http://sourceforge.net/apps/trac/embunity/wiki >  http://cutter.sourceforge.net/ >  http://check.sourceforge.net/ > > _______________________________________________ > evolution-hackers mailing list > firstname.lastname@example.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers
Description: This is a digitally signed message part
_______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers