[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Gtk+ unit tests (brainstorming)
From:       Tim Janik <timj () imendio ! com>
Date:       2006-11-16 10:30:33
Message-ID: Pine.LNX.4.62.0611161111020.12414 () master ! birnet ! private
[Download RAW message or body]

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
> corner
> cases - should be promoted as much as possible to make life easier for
> language
> binding writers, property editors and such ?

yes, that is exactly what i was trying to say. sorry if it was hard to
understand.
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
around.

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
> think.

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:
   http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00077.html
i'd hope that also covers what you're looking for.

> Cheers,
>                                 -Tristan

---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]