Re: Test Framework Mini Tutorial
Hi,
I'm developing Cutter(*) that is an unit testing framework
for C to write tests more easily and simply.
(*): http://cutter.sf.net/
In <[EMAIL PROTECTED]>
"Test Framework Mini Tutorial" on Thu, 13 Dec 2007 18:14:57 +0100 (CET),
Tim Janik <[EMAIL PROTECTED]> wrote:
> The main goals in writing tests are:
> - In example (test) driven development (EDD or TDD), an example or test
>program is written first, and then the newly used API gets implemented.
>This ensures early testability and gives programmers early feedback on
>their implementation.
> - For untested legacy code, new tests are written to get about to be changed
>code portions under automated tests to catch behavior changes as code is
>changed.
> - Most tests are written to ensure basic functionality checks of the code
>area in change. Tests usually cannot perform comprehensive checks, but
>can check for specific known to be tricky corner cases or often test a
>representative subset of an API.
>
> In general, working on code that is sufficiently under automated tests
> makes programmers feel much more confident about their changes and helps
> to spot errors shortly after introduction. So well tested code bases
> tend to increase productivity and fun in working with the code.
I agree with you.
And I think that there is an another important
thing. Writing tests shouldn't bother us. It's better that
we can write tests with fun. If writing tests bothers us, we
will not write tests. :<
> 3) Implement the actual test function, possibly taking a fixture argument.
> Tests should try to avoid duplicating logic or tests and often consist
> of a series of calls and checks to use a component and verify its
> behavior, e.g.:
> string = g_string_new ("first");
> g_assert_cmpstr (string->str, ==, "first");
> g_string_append (string, "last");
> g_assert_cmpstr (string->str, ==, "firstlast");
If this assertion fails, we will get output like the
following:
/teststring: **
** ERROR:(teststring.c:123):test_string: assertion failed (string->str, ==,
"firstlast"): ("first last" == "firstlast")
zsh: abort ./teststring
I think the output '("first last" == "firstlast")' is too
difficult to find difference between an actual result
("first last") and an expected result ("firstlast") by our
eye diff.
In Cutter, the test will be written like the following(*):
string = g_string_new ("first");
cut_assert_equal_string ("first", string->str);
g_string_append (string, "last");
cut_assert_equal_string ("firstlast", string->str);
(*) An expected result is written first because it's
important rather than actual test target code
(string->str). In reading tests, we will be interested
in an expected result. e.g. an expected result is
"first" in the first assertion. An expected result is
"firstlast" after "last" is appended. But an actual test
target code (string->str) isn't changed.
And outputs like the following:
...
1) Failure: test_string
<"firstlast" == string->str>
expected:
but was:
./test-string.c:123: test_string()
...
Cutter formats an expected result and an actual result to
find difference between them. This will help us to debug the
problem. And the problem line is formated with Emacs
friendly format. i.e. FILE_NAME:LINE: OTHER INFO.
> 6) Hook up the test in the test program. The simplest test program is:
> int
> main (int argc,
> char *argv[])
> {
> gtk_test_init (&argc, &argv); // initialize test program
> g_test_add_func ("/TestProgramName/Test Case Name",
> test_case_test_func);
> return g_test_run();
> }
> The g_test_add() function can be used to hook up tests with Fixtures:
> g_test_add ("/scanner/symbols",// test case name
> ScannerFixture,// fixture structure type
> NULL, // unused data argument
> scanner_fixture_setup, // fixture setup
> test_scanner_symbols, // test function
> scanner_fixture_teardown); // fixture teardown
I think self registering tests mechanism will bother us. We
may forget to register new test.
Cutter collects tests automatically. And Cutter can find
fixture setup/teardown function too. Cutter has an example
test for a stack implementation. The example test is used in
Cutter tutorial(*). Here is an complete test:
(*) http://cutter.sourceforge.net/reference/tutorial.html
http://cutter.svn.sourceforge.net/viewvc/cutter/trunk/sample/stack/test/test-stack.c?view=markup
#include
#include
void test_new_stack (void);
void test_push (void);
void test_pop (void);
static Stack *stack;
void
setup (void)
{
stack = NULL;
}
void
teardown (void)
{
if (stack)
stack_free(stack);
}
void
test_new_stack (void)
{
stack = stack_new();
Re: gvfs hal volume monitoring backend
On Dec 14, 2007 7:21 PM, David Zeuthen <[EMAIL PROTECTED]> wrote: > - build fixes since only gio/gio.h can be included now >(btw, should gio.h conditionally include the UNIX specific bits? This > is not the case right now; I manually have to unclude gunixmounts.h) No. We generally leave such platform-specific headers out of the global header. The platform-specific bits are available via a separate pc file, and require explicitly including the relevant header. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] Use the volume monitor correctly and make it act like Nautilus' sidebar
On Fri, 2007-12-14 at 19:25 -0500, David Zeuthen wrote: > I've attached the patch to this mail. Thanks for reviewing it. And here's a patch that fixes a leak. Goes on top of the previous one. Sorry about that. Thanks! David diff --git a/src/gtkfilesystemgvfs.c b/src/gtkfilesystemgvfs.c index 4c0c080..a93e3e7 100644 --- a/src/gtkfilesystemgvfs.c +++ b/src/gtkfilesystemgvfs.c @@ -284,8 +284,8 @@ get_volumes_list (GtkFileSystemGVfs *file_system) * he just unmounted it. */ file_system->volumes = g_slist_prepend (file_system->volumes, g_object_ref (volume)); - g_object_unref (volume); } + g_object_unref (volume); } } else ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[PATCH] Use the volume monitor correctly and make it act like Nautilus' sidebar
Hey Carlos, Here's a patch that makes the GTK+ gvfs file chooser backend correctly use the volume monitor and make it act like the Nautilus places sidebar. Which is how the gnome-vfs GTK+ file chooser backend in libgnomeui currently works. Notably - unmounted media is shown and if you double click, it will be mounted - if a drive isn't polled it is shown and double clicking it will initiate a media scan - the correct icons are used There's a screenshot here http://people.freedesktop.org/~david/gvfs-hal-filechooser.png I've attached the patch to this mail. Thanks for reviewing it. David 0001-Use-the-volume-monitor-correctly-and-make-it-act-lik.patch Description: application/mbox ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs hal volume monitoring backend
On Fri, 2007-12-14 at 03:22 -0500, David Zeuthen wrote: > Hi again, > > Here we go with the patches for the hal volume monitoring backend: > > http://people.freedesktop.org/~david/gio.patch > http://people.freedesktop.org/~david/nautilus.patch > http://people.freedesktop.org/~david/gvfs.patch Here's some updated patches http://people.freedesktop.org/~david/gio-2.patch http://people.freedesktop.org/~david/gvfs-2.patch against trunk. No changes to the nautilus patch; it should still apply. Notable changes - build fixes since only gio/gio.h can be included now (btw, should gio.h conditionally include the UNIX specific bits? This is not the case right now; I manually have to unclude gunixmounts.h) - export gnativevolumemonitor.h in gio (otherwise you can't have native loadable volume monitors) - a few fixes for the hal volume monitor to properly release all resources when the volume monitor is unreffed. I needed this for the file chooser backend work (see my other mail coming up in a jiffy). David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On Dec 14, 2007 3:27 AM, Alexander Larsson <[EMAIL PROTECTED]> wrote: > Anything that has cancellable operations (things like libsoup or > whateveR) should use GCancellable. And GAsyncResult is a very powerful > pattern for doing async operation that all libraries with async > operations should take advantage of. And things like > GInputStream/GOutputStream are obviously useful for other things, like > loading pixbufs from any kind of source by implementing GInputStream. > It would probably be good to emphasize thie generic applicability in the docs and give some examples for the pattern. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
Alexander Larsson wrote: > On Thu, 2007-12-13 at 14:50 +0100, Michael Natterer wrote: > >> Alexander Larsson wrote: >> >>> On Wed, 2007-12-12 at 16:46 +0100, Michael Natterer wrote: >>> Alexander Larsson wrote: > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: > >> Hey everybody, >> >> We've been doing a GIO API review in the last couple of days and >> here is the list of comments and issues we've come up with: >> >> >> General: >> >> >> It seems GIO allows individual files to be included, this should be >> avoided like gobject does it: >> >> #if !defined (__GLIB_GIO_H_INSIDE__) && !defined (GIO_COMPILATION) >> #error "Only can be included directly." >> #endif >> > Why? I know gobject does this, but I never understood why. It seems to > just make build times longer. > Because otherwise you get into the very same typedef and include mess we have in glib and gtk+. It makes it *very* hard to change anything type related in the future. Any addition of a new function that happens to use a new type which was not used in that header before might work fine for the library's build itdelf, but might break the build of applications that include whatever combination of headers. Clear structure of headers and types should never be traded for compile time, we also keep distinct things in distinct .c files. Why would we scatter our typedefs across our libraries, or keep certain includes in headers forever? >>> Ok. I guess this makes sense. I'll do this. >>> >> Thanks :-) >> >> I forgot to mention, gobject has its common header in glib/. I'm not >> quite sure about this decision and I'm also not sure if saying >> >> #include >> >> or >> >> #include >> >> is the more "natural" thing to do... Just for consideration. >> > > I'm for . It seems more inline with all our other libraries. > Only gobject does the thing. > Shouldn't be enough? This would really drop 4 letters that every gio-using developer had to type and which are really redundant. I really don't like this style because it forces developers just to type more than they IMHO should. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: nmake build fixes for glib.
Here you go: http://bugzilla.gnome.org/show_bug.cgi?id=503602 Did you have a chance to look at it? Greets, Lieven van der Heide. On 12/12/07, Cody Russell <[EMAIL PROTECTED]> wrote: > On Wed, 2007-12-12 at 17:43 +0100, Lieven van der Heide wrote: > > Hi, > > > > I made some fixes for the nmake makefiles and the win32-fixup.pl script. > > > > glib, gmodule, gthread and gobject build fine now. gio and tests don't > > build yet, but I don't think that's related to the makefiles. > > > > Also, right now (in svn), it assume that libiconv and gettext are in a > > folder called ../get-text-0.40.10 and ../libiconv-1.7 These versions > > don't seem to be outdated anyway, but instead of changing it to the > > current version, I just changed it to plain ../gettext and > > ../libiconv, because I don't think there's really one specific version > > you want to link to, just as long as it isn't too old (I assume they > > try to stay API and ABI compatible with older version). > > This is really awesome! I'll test it out hopefully later today. In the > mean time, would you mind opening a Bugzilla bug for this and attaching > your patches to it? CC me on the bug, or email me the bug# too. > > / Cody > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
Matthias Clasen wrote: > On Dec 13, 2007 1:21 PM, Martyn Russell <[EMAIL PROTECTED]> wrote: > >> I don't really see the need for adding symbols to the library to >> represent 0. If there is only one "flag" in each of these that matters, >> doesn't it make more sense to just have a boolean? >> > > This is not adding any symbols to the library. It merely tells the > compiler to recognize some more names for 0. Thanks, didn't realise that. > And using meaningful > names makes the code a lot more > self-explanatory. *nods* -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
14 dec 2007 kl. 09.27 skrev Alexander Larsson: Hi, > On Thu, 2007-12-13 at 19:19 +0100, Mikael Hallendal wrote: > >> For example, if we plan to never use the GAsync infrastructure for >> anything other than GIO there is a point to put it under the GIO >> namespace as it shows where it belongs and what part of GLib it is >> used for. It also means we can have GFooAsync later without the two >> getting confused with each other. The same for GCancellable and >> similar namespaces. > > Eh, why would we not use these for anything other than GIO. They were > specifically designed to be generic and to be used by other APIs. Please re-read the start of the paragraph you quoted. If this is the case, all the better. > Anything that has cancellable operations (things like libsoup or > whateveR) should use GCancellable. Perfect! >> Without any namespace other than g_ it gives the idea that these >> "frameworks" are used for more than one subsystem (at least to me). > > Which is why they are good names, as this is the intention. Then we agree. >> GAsync, GCancellable, g_push, g_pop, g_loadable, g_simple are >> examples >> of namespaces that would benefit from being under the GIO name spaced >> as they are too generic by themselves. > > A few of these are unnecessary taking up namespace, and I'm working on > fixing these. And here too. :) Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On Thu, 2007-12-13 at 19:19 +0100, Mikael Hallendal wrote: > For example, if we plan to never use the GAsync infrastructure for > anything other than GIO there is a point to put it under the GIO > namespace as it shows where it belongs and what part of GLib it is > used for. It also means we can have GFooAsync later without the two > getting confused with each other. The same for GCancellable and > similar namespaces. Eh, why would we not use these for anything other than GIO. They were specifically designed to be generic and to be used by other APIs. Anything that has cancellable operations (things like libsoup or whateveR) should use GCancellable. And GAsyncResult is a very powerful pattern for doing async operation that all libraries with async operations should take advantage of. And things like GInputStream/GOutputStream are obviously useful for other things, like loading pixbufs from any kind of source by implementing GInputStream. > Without any namespace other than g_ it gives the idea that these > "frameworks" are used for more than one subsystem (at least to me). Which is why they are good names, as this is the intention. > GAsync, GCancellable, g_push, g_pop, g_loadable, g_simple are examples > of namespaces that would benefit from being under the GIO name spaced > as they are too generic by themselves. A few of these are unnecessary taking up namespace, and I'm working on fixing these. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gvfs hal volume monitoring backend
Hi again, Here we go with the patches for the hal volume monitoring backend: http://people.freedesktop.org/~david/gio.patch http://people.freedesktop.org/~david/nautilus.patch http://people.freedesktop.org/~david/gvfs.patch First there's a gio patch with some feature additions and fixes for the volume monitor. One fix is to make it handle when the constructor for a GNativeVolumeMonitor fails - this is important to handle as the hal volume monitor will fail if hald isn't running. I'm not happy about how I've implemented it; suggestions welcome. Another fix is to properly unref the child monitors when finalizing. I've also added locking in _g_get_mount_for_mount_path() so native volume monitors don't have to worry about that. It's not clear to me whether _g_get_mount_for_mount_path() is allowed to block; I *think* it is but docs are scarce on this point. There's also a TODO item in that function with some more unanswered questions. Also, the gio patch should bring the GUnixVolumeMonitor to a state where it's feature complete; eject now works. Second, there's a patch for nautilus to take advantage of the new API (mostly that eject() is now on GMount, GVolume and GDrive). Finally, there's a patch against gvfs with updates for the API changes and then the hal backend itself. At the moment it's using dbus-glib-1 in addition to libhal; not clear to me why it shouldn't. Thoughts? Also, there's a ton of new icon names used [1]; here's example icons to test that I've used http://people.freedesktop.org/~david/gvfs-hal-icons.tar.gz which is basically just Tango icons with ugly labels on top. There are necessary as we don't yet have fallback code integrated. Just untar this in ~/.icons and it should work. I need to get this into the icon naming spec too. One icky thing is that we use the same icon for representing a drive and representing unmounted media in that drive. One idea is to append the suffix "-hasmedia" to the drive icon name, e.g. drive-removable-media-usb -> drive-removable-media-usb-hasmedia and icon fallbacks would save us. However, I'm not sure it's worth it. Most people will probably only see the icons for mounted media due to automounting and polling of drives and the fact they probably don't use computer:///. Thoughts? I've not yet hooked up the volume:// stuff; wanted to get this in first. Thanks for reviewing it. David [1] : See [2] for the actual icons. Keep in mind that thanks to icon fallbacks the stock GNOME desktop need not to ship all of these; e.g. the stock icon theme would only ship drive-harddisk and not all of drive-harddisk-ata, drive-harddisk-usb and so forth. Depends on what you want etc. etc. [2] : $ ls ~/.icons drive-harddisk-ata.svg media-optical-audio.svg drive-harddisk-ieee1394.svg media-optical-bd-re.svg drive-harddisk-scsi.svg media-optical-bd-rom.svg drive-harddisk-usb.svg media-optical-bd-r.svg drive-optical-recorder.svg media-optical-cd-rom.svg drive-removable-media-ata.svg media-optical-cd-r.svg drive-removable-media-flash-cf.svg media-optical-cd-rw.svg drive-removable-media-flash-ms.svg media-optical-dvd-dl-r-plus.svg drive-removable-media-flash-sd.svg media-optical-dvd-ram.svg drive-removable-media-flash-sm.svg media-optical-dvd-rom.svg drive-removable-media-floppy.svgmedia-optical-dvd-r-plus.svg drive-removable-media-ieee1394.svg media-optical-dvd-r.svg drive-removable-media-scsi.svg media-optical-dvd-rw-plus.svg drive-removable-media-tape.svg media-optical-dvd-rw.svg drive-removable-media-usb.svg media-optical-hddvd-rom.svg media-flash-cf.svg media-optical-hddvd-r.svg media-flash-ms.svg media-optical-hddvd-rw.svg media-memory-sd.svg media-optical-mo.svg media-memory-sm.svg ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On Thu, 2007-12-13 at 19:45 +0100, Richard Hult wrote: > Mikael Hallendal wrote: > > I just wanted to clarify though that it's not so much for technical > > reasons I suggested that we namespace a bit more carefully. > > > > For example, if we plan to never use the GAsync infrastructure for > > anything other than GIO there is a point to put it under the GIO > > namespace as it shows where it belongs and what part of GLib it is > > used for. It also means we can have GFooAsync later without the two > > getting confused with each other. The same for GCancellable and > > similar namespaces. > > And in this particular example, g_async_*, there is already a clash: we > have g_async_queue_* right now, which is unrelated of course. A slightly > longer name to avoid confusion here would be a fairly low price to pay > in terms of typing. And I don't agree that it would be harder to read > code with slightly longer names, on the contrary, at least when the > added part is reasonably long. If it's clear what subsystem the function > is related to, the developer doesn't have to stop to think. I don't think this is really a conflict. The type name is GAsyncResult, not GAsync. I don't think it is a problem to have different kinds of types that start with GAsync, and its not like they are totally unrelated (they are both about async tings). Its a similar situation to e.g. GtkIconTheme and GtkIconView. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
