Re: Gtk+ unit tests (brainstorming)

On Thu, 26 Oct 2006, Tristan Van Berkom wrote:

Tim Janik wrote:

(sometime one property has no
meaning if another one hasnt been setup yet - in which case a
g_return_if_fail() guard would be appropriate).

wrong, some proeprty values are intentionally set up to support
free-order settings. e.g. foo=5; foo-set=true; or foo-set=true; foo=5;
every order restriction or property dependency that is introduced in the
proeprty API makes generic handling of properties harder or sometimes
impossible so should be avoided at all costs.
(examples for generic property handling code are language bindings,
property editors, glade, gtk-doc)

I think thats a little uncooperative - wouldnt you say on the other hand
- that
the independance of property ordering - aside from possible real weird
cases - should be promoted as much as possible to make life easier for
binding writers, property editors and such ?

yes, that is exactly what i was trying to say. sorry if it was hard to
if at all possible any possible ordering should be supported when
setting properties on an object. at least, no restrictions should be
introduced by an object implementation that can reasonably be worked

for unit tests, we can simply do things like pick properties in random
orders and set them to random values. we can then succesively fix gtk
cases that unreasonably rely on proeprty orders, or add rules to the
test cases about non-fixable ordering requirements.
note that *some* ordering support is already present in the GObject
API by flagging properties as CONSTRUCT or CONSTRUCT_ONLY.

Ummm, while I'm here - I'd also like to say that - (I'm not about to
dig up the quote from the original email but) - I think that there
is some value to reporting all the tests that fail - even after one
of the tests has failed, based on the same principals that you'd
want your compiler to tell you everything that went wrong in its
parse (not just the first error),
Sure I'll elaborate, what I mean is - if you dont want to pollute
the developers console with alot of errors from every failing test,
you can redirect them to some log file and only say
"at least one test failed" - maybe depict which one was the first
failure - and then point to the log.

Your arguments against collecting all the failures seem to
apply fine to gcc output too - and yes you might usually end up just
fixing the first error and recompiling, yet I manage to still appriciate
this feature of verbosity - delivered at the not too high cost of
wording a makefile a little differently (for unit tests that is) - i'd

ok thanks, i think i get the idea now ;)
i've adressed getting more than a single test failure reported without any
need to modify tests in yesterdays email on this topic:
i'd hope that also covers what you're looking for.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]