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 [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 friends. Regards, Philip [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-list 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