A new very nice unit test that tests getting headers and counting messages in folders

[Philip Van Hoof <spam pvanhoof be>]

Hackers,

This is the type of unit tests that I would like to see more. So if you
want to help tinymail *a lot*, the best way to start contributing is by
making more unit tests like this.

It's also the best way to learn how to use the framework. Because that
is exactly what a unit test does: it uses the framework extensively.

http://svn.tinymail.org/svn/tinymail/trunk/libtinymail-test/tny-folder-iface-test.c

For example this method first checks whether we succeeded in getting the
folder. If not, it's likely that we are offline (so it doesn't fail the
unit test, but it does warn the user of the unit test in this case).

Look at the code of "tny_folder_iface_test_setup" in file above to
understand how the folder is created as variable "iface". The folder is
a TnyFolder instance for an IMAP folder on the test IMAP account 

You can for new tests of course reuse this piece of code (you don't even
have to copy it, as it's a sharable function you need to pass per unit
test for GUnit).

static void
tny_folder_iface_test_get_headers_sync (void)
{
    	TnyListIface *headers;
	gint length = 0, all_count;

    	if (iface == NULL)
	{
		GUNIT_WARNING ("Test cannot continue (are you online?)");
	    	return;
	}
    
    	headers = tny_list_new ();
	tny_folder_iface_refresh (iface);
	all_count = tny_folder_iface_get_all_count (iface);
    
	tny_folder_iface_get_headers (iface, headers, FALSE);
	length = tny_list_iface_length (headers);
        
	str = g_strdup_printf ("I received %d headers, the folder tells me it has %d messages\n", length, all_count);
	gunit_fail_unless (length == all_count, str);
	g_free (str);
    
	g_object_unref (G_OBJECT (headers));
	tny_folder_iface_uncache (iface);
}


So what we tested here is not only whether refreshing the folder works.
Also whether the get_headers method works and whether get_all_count
works.

Three tests in 20 simple lines of code. It takes almost no time to
create this unit test. And it will save me hours and hours of debugging
and hundreds of needless bugreports each time I or somebody else changed
something that broke the code.

A unit test doesn't have to be difficult or complex. But that doesn't
mean it doesn't have value. Just having the unit tests is extremely
valuable for a developer to test his piece-of-shit code.

.
.
.

Because that is what all untested code IS. It's piece of shit. But using
the tools the God of thunder, torture, destruction and programming has
given us we can turn that into elegant and correct stuff that just works
and does *EXACTLY* what we want it to do (not nearly but exactly).

Informatics and programming (of today) is not like girls. It has only
zeros and ones. There's no gray area in between. A bug is a zero where
it should have been a one or visa verse. You can't have a gray bug or
feature that is more-or-less correct. In informatics and programming
it's right or it's wrong. Pragmatism happens when management decides
that it's okay to keep something wrong. It doesn't make it right.

So. To summarise:

My own tinymail framework code is indeed still mostly piece-of-shit
because not every single line of code has yet been tested by at least
5,000 different tests running on at least 10 different architectures.

But I will get there. You'll see. And you can help me with that. I'm
still waiting for the first contributed unit test. Yet there's plenty of
past contributions in the form of patches.

Unit tests are equally and often more important than the code itself.


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be