<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<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>
	<lastBuildDate>Sat, 11 Apr 2009 19:30:15 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: shark_yang</title>
		<link>http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/comment-page-1/#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&#039;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 &#039;__int64&#039; to &#039;long double&#039;, possible loss of data

In glib&#039;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 &quot; &quot; #cmp &quot; &quot; #n2, __n1, #cmp, __n2, &#039;i&#039;); } 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 &quot; &quot; #cmp &quot; &quot; #n2, (long double)__n1, #cmp, (long double)__n2, &#039;i&#039;); } 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-page-1/#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&#039;s main event loop and iochannel, but why glib&#039;s main event loop and iochannel don&#039;t support epoll/kqueue/(/dev/poll)?

The poll/select func&#039;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-page-1/#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-page-1/#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&#039;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-page-1/#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&#039;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-page-1/#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&#039;s code style is: #define XXXXXX G_STMT_END{}G_STMT_END

May be you should consult the cunit&#039;s code (http://cunit.sourceforge.net/).

2)I use glib&#039;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 (<a href="http://cunit.sourceforge.net/)" rel="nofollow">http://cunit.sourceforge.net/)</a>.</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-page-1/#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-page-1/#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&#039;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>
