On 09/11/2007, Tim Janik [EMAIL PROTECTED] wrote:
On Thu, 8 Nov 2007, Mikkel Kamstrup Erlandsen wrote:
On 07/11/2007, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED]
wrote:
How about token concatenation[1]?
i have to use that already for the current implementation,
see my recent header:
On Nov 9, 2007, at 4:16 AM, Mikkel Kamstrup Erlandsen wrote:
That is certainly another possibility. However a design goal of my
code was to only expose one public symbol per simple type and let
the rest of the public methods be implemented in macros wrapping
these symbols. I am not
On Wed, 7 Nov 2007, Morten Welinder wrote:
nobody has to use this syntax. you can stick to the ever simple:
g_assert (foo bar);
however if you want the value of 'foo' and 'bar' be printed out, instead
of just the value of (foo bar) which would be 0 or 1, then there are
no other means
Matthias Clasen matthias clasen gmail com, Tue, 6 Nov 2007 13:12:02
-0500
On 11/1/07, Tim Janik timj imendio com wrote:
- we provide an extended set of assertions for strings, ints and floats
that allow printing of assertion arguments upon failures to reduce
the need for
On Wed, 2007-11-07 at 09:15 -0500, Morten Welinder wrote:
Note, that the filter should preserve line numbers, i.e., never remove and
never insert newlines. Otherwise error messages with line numbers would
drive you crazy.
It could also just use #line pre-processor directives:
nobody has to use this syntax. you can stick to the ever simple:
g_assert (foo bar);
however if you want the value of 'foo' and 'bar' be printed out, instead
of just the value of (foo bar) which would be 0 or 1, then there are
no other means than using something simialr to:
On 11/1/07, Tim Janik [EMAIL PROTECTED] wrote:
I don't have much in terms of comments. My general reaction to
grandiose test frameworks is that fixtures, setup/teardown,
hierarchical test suites are too much overhead for me. Maybe this
approach to testing works for people who are move
disciplined
On Tue, 6 Nov 2007, Matthias Clasen wrote:
On 11/1/07, Tim Janik [EMAIL PROTECTED] wrote:
One thing I find pretty useful, that has not been mentioned so far (or
I missed it) is regression tests for bugs. For these it is very useful
to have some standardized way to refer to the bug they are
On Nov 6, 2007 2:19 PM, Tim Janik [EMAIL PROTECTED] wrote:
On Tue, 6 Nov 2007, Matthias Clasen wrote:
On 11/1/07, Tim Janik [EMAIL PROTECTED] wrote:
One thing I find pretty useful, that has not been mentioned so far (or
I missed it) is regression tests for bugs. For these it is very
On Tue, 6 Nov 2007, Matthias Clasen wrote:
On Nov 6, 2007 2:19 PM, Tim Janik [EMAIL PROTECTED] wrote:
On Tue, 6 Nov 2007, Matthias Clasen wrote:
On 11/1/07, Tim Janik [EMAIL PROTECTED] wrote:
One thing I find pretty useful, that has not been mentioned so far (or
I missed it) is regression
On Nov 6, 2007, at 2:40 PM, Matthias Clasen wrote:
On Nov 6, 2007 2:19 PM, Tim Janik [EMAIL PROTECTED] wrote:
however if you want the value of 'foo' and 'bar' be printed out,
instead
of just the value of (foo bar) which would be 0 or 1, then there
are
no other means than using
Hej,
wouldn't it make sense to move setting the bug-tracker url to spme
normal g_lib module, like where g_(g|s)et_application_name() is. he
g_option stuff could display the link when running app --help.
We would need two urls: one template to get a report by id and one to
file a bug.
Hi Tim,
Tim Janik schrieb:
On Thu, 1 Nov 2007, Stefan Kost wrote:
Hi Tim,
Now some comments about the API
g_test_create_case - g_test_case_create
g_test_create_suite - g_test_suite_create
i think this is a bit of a philosophy issue. i'd like to think about
the new testing framework
On Thu, 1 Nov 2007, Stefan Kost wrote:
Hi Tim,
Now some comments about the API
g_test_create_case - g_test_case_create
g_test_create_suite - g_test_suite_create
i think this is a bit of a philosophy issue. i'd like to think about
the new testing framework as one integrated thing, and that
hi All.
with lots of help from Sven Herzberg and others, i've designed a unit test
framework for GLib, which Sven and i plan to implement in the following weeks.
i'll post about testing framework/utilities for Gtk+ at a later point.
feedback is greatly appreciated.
QUICK READERS: two short
Hi Tim,
Thanks for the nice writeup.
In cairo land we've got some new requirements for our test suite over
time. I try to summarize our current infrastructure and requirements.
Most of these was mentioned in the thread last year, but I repeat so you
can double-check your model if you wish.
Hi Tim,
thanks for the work you put into this already!
First some comment regarding check. We use check in gstreamer and I use that in
buzztard too. I can understand that some people see an issue with having this as
a dependency. Besides also the api is a bit chaotic (no namespace prefix).
Hello Tim,
I have found that a good way to write tests, is to write them in
Python. Almost all libraries (and certainly all in the GNOME platform)
has Python bindings, so it doesn't matter if you use C or Python to
write your tests. In fact, writing the tests in Python should be
beneficial
On Thu, 2007-11-01 at 18:24 -0400, BJörn Lindqvist wrote:
Hello Tim,
I have found that a good way to write tests, is to write them in
Python. Almost all libraries (and certainly all in the GNOME platform)
has Python bindings, so it doesn't matter if you use C or Python to
write your tests.
19 matches
Mail list logo
