<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: 23.06.2008 Writing Unit Tests with GLib</title>
	<atom:link href="http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/</link>
	<description>Technical ramblings by Tim Janik</description>
	<pubDate>Thu, 20 Nov 2008 09:46:57 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: shark_yang</title>
		<link>http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-189</link>
		<dc:creator>shark_yang</dc:creator>
		<pubDate>Tue, 08 Jul 2008 08:37:10 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-189</guid>
		<description>hi Tim:

I use glib's testunit in visual studio 2002.But when compling the code, i find warnings. 

The code:
...
g_assert_cmpint(3, ==, 2);
...

The warnings:
warning C4244: conversion from '__int64' to 'long double', possible loss of data

In glib's source code(gtestutils.h):
#define g_assert_cmpint(n1, cmp, n2) \
		do { gint64 __n1 = (n1), __n2 = (n2); \
                if (__n1 cmp __n2) ; else \
                _assertion_message_cmpnum (G_LOG_DOMAIN, __FILE__, __LINE__, G_STRFUNC, \
                #n1 " " #cmp " " #n2, __n1, #cmp, __n2, 'i'); } while (0)
 

May be correct:
#define g_assert_cmpint(n1, cmp, n2) \
		do { gint64 __n1 = (n1), __n2 = (n2); \
                if (__n1 cmp __n2) ; else \
                _assertion_message_cmpnum (G_LOG_DOMAIN, __FILE__, __LINE__, G_STRFUNC, \
                #n1 " " #cmp " " #n2, (long double)__n1, #cmp, (long double)__n2, 'i'); } while (0)</description>
		<content:encoded><![CDATA[<p>hi Tim:</p>
<p>I use glib&#8217;s testunit in visual studio 2002.But when compling the code, i find warnings. </p>
<p>The code:<br />
&#8230;<br />
g_assert_cmpint(3, ==, 2);<br />
&#8230;</p>
<p>The warnings:<br />
warning C4244: conversion from &#8216;__int64&#8242; to &#8216;long double&#8217;, possible loss of data</p>
<p>In glib&#8217;s source code(gtestutils.h):<br />
#define g_assert_cmpint(n1, cmp, n2) \<br />
		do { gint64 __n1 = (n1), __n2 = (n2); \<br />
                if (__n1 cmp __n2) ; else \<br />
                _assertion_message_cmpnum (G_LOG_DOMAIN, __FILE__, __LINE__, G_STRFUNC, \<br />
                #n1 &#8221; &#8221; #cmp &#8221; &#8221; #n2, __n1, #cmp, __n2, &#8216;i&#8217;); } while (0)</p>
<p>May be correct:<br />
#define g_assert_cmpint(n1, cmp, n2) \<br />
		do { gint64 __n1 = (n1), __n2 = (n2); \<br />
                if (__n1 cmp __n2) ; else \<br />
                _assertion_message_cmpnum (G_LOG_DOMAIN, __FILE__, __LINE__, G_STRFUNC, \<br />
                #n1 &#8221; &#8221; #cmp &#8221; &#8221; #n2, (long double)__n1, #cmp, (long double)__n2, &#8216;i&#8217;); } while (0)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: shark_yang</title>
		<link>http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-187</link>
		<dc:creator>shark_yang</dc:creator>
		<pubDate>Thu, 26 Jun 2008 02:23:13 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-187</guid>
		<description>Tim Janik:

I use glib's main event loop and iochannel, but why glib's main event loop and iochannel don't support epoll/kqueue/(/dev/poll)?

The poll/select func's efficiency is very poor.

The libevent(http://monkey.org/~provos/libevent/) use epoll/kqueue. Why glib not?

thanks</description>
		<content:encoded><![CDATA[<p>Tim Janik:</p>
<p>I use glib&#8217;s main event loop and iochannel, but why glib&#8217;s main event loop and iochannel don&#8217;t support epoll/kqueue/(/dev/poll)?</p>
<p>The poll/select func&#8217;s efficiency is very poor.</p>
<p>The libevent(http://monkey.org/~provos/libevent/) use epoll/kqueue. Why glib not?</p>
<p>thanks</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tim Janik</title>
		<link>http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-186</link>
		<dc:creator>Tim Janik</dc:creator>
		<pubDate>Wed, 25 Jun 2008 10:33:31 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-186</guid>
		<description>liberforce, feel free to start a unit test tutorial page on live.gnome.org or to submit it as a patch against GLib for inclusion in library.gnome.org. The main tutorial contents are here:
  http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00181.html
And this is also related:
  http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00286.html
We appreciate various sorts of contributions, of course also documentation.</description>
		<content:encoded><![CDATA[<p>liberforce, feel free to start a unit test tutorial page on live.gnome.org or to submit it as a patch against GLib for inclusion in library.gnome.org. The main tutorial contents are here:<br />
  <a href="http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00181.html" rel="nofollow">http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00181.html</a><br />
And this is also related:<br />
  <a href="http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00286.html" rel="nofollow">http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00286.html</a><br />
We appreciate various sorts of contributions, of course also documentation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: liberforce</title>
		<link>http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-185</link>
		<dc:creator>liberforce</dc:creator>
		<pubDate>Wed, 25 Jun 2008 10:21:06 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-185</guid>
		<description>Wouldn't it be better if this blog post was converted into a live.gnome.org tutorial ?</description>
		<content:encoded><![CDATA[<p>Wouldn&#8217;t it be better if this blog post was converted into a live.gnome.org tutorial ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tim Janik</title>
		<link>http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-184</link>
		<dc:creator>Tim Janik</dc:creator>
		<pubDate>Wed, 25 Jun 2008 09:49:40 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-184</guid>
		<description>shark_yang, G_STMT_START/G_STMT_END is essentially a lengthier way to write do{...}while(0).
As for CUnit, that has been considered but didn't meet the requirements:
http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg00000.html
http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00039.html</description>
		<content:encoded><![CDATA[<p>shark_yang, G_STMT_START/G_STMT_END is essentially a lengthier way to write do{&#8230;}while(0).<br />
As for CUnit, that has been considered but didn&#8217;t meet the requirements:<br />
<a href="http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg00000.html" rel="nofollow">http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg00000.html</a><br />
<a href="http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00039.html" rel="nofollow">http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00039.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: shark_yang</title>
		<link>http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-183</link>
		<dc:creator>shark_yang</dc:creator>
		<pubDate>Wed, 25 Jun 2008 09:23:51 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-183</guid>
		<description>1) Glib testing contains a lot of dirty ocde. 
For example: 
#define XXXXXX do {xxx}while(0)
glib's code style is: #define XXXXXX G_STMT_END{}G_STMT_END

May be you should consult the cunit's code (http://cunit.sourceforge.net/).

2)I use glib's Testing, but documentation is missing. There was no guide for how to set up your own project to use the glib testing framework or higher level overview of setup/teardown, available asserts, running, parameters, etc.</description>
		<content:encoded><![CDATA[<p>1) Glib testing contains a lot of dirty ocde.<br />
For example:<br />
#define XXXXXX do {xxx}while(0)<br />
glib&#8217;s code style is: #define XXXXXX G_STMT_END{}G_STMT_END</p>
<p>May be you should consult the cunit&#8217;s code (http://cunit.sourceforge.net/).</p>
<p>2)I use glib&#8217;s Testing, but documentation is missing. There was no guide for how to set up your own project to use the glib testing framework or higher level overview of setup/teardown, available asserts, running, parameters, etc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rogz</title>
		<link>http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-182</link>
		<dc:creator>Rogz</dc:creator>
		<pubDate>Wed, 25 Jun 2008 05:26:01 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-182</guid>
		<description>One feature at least I would find useful is an option to instrument the code with a test vector and include the test coverage result in the test reports.

From experience I know that hard facts, code coverage percentage for example, encourages developers (or testers) to write complete test cases (feature wise) and eliminate unneeded or dead code.</description>
		<content:encoded><![CDATA[<p>One feature at least I would find useful is an option to instrument the code with a test vector and include the test coverage result in the test reports.</p>
<p>From experience I know that hard facts, code coverage percentage for example, encourages developers (or testers) to write complete test cases (feature wise) and eliminate unneeded or dead code.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ovitters</title>
		<link>http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-181</link>
		<dc:creator>ovitters</dc:creator>
		<pubDate>Tue, 24 Jun 2008 22:18:49 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/#comment-181</guid>
		<description>Not sure if you know, but Google gave a few machines and our intention is to use these as build machines. Shipping those is taking much longer than intended.. so they're not online yet. If you want specifics, ask vuntz.</description>
		<content:encoded><![CDATA[<p>Not sure if you know, but Google gave a few machines and our intention is to use these as build machines. Shipping those is taking much longer than intended.. so they&#8217;re not online yet. If you want specifics, ask vuntz.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
