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

List:       kde-devel
Subject:    Re: Question on QTest::ignoreMessage / qDebug() operation
From:       Manuel Breugelmans <mbr.nxi () gmail ! com>
Date:       2008-08-20 11:22:39
Message-ID: 200808201322.39570.mbr.nxi () gmail ! com
[Download RAW message or body]

On Wednesday 20 August 2008 11:26:05 Thiago Macieira wrote:
> On Wednesday 20 August 2008 10:38:23 Manuel Breugelmans wrote:
> > On Monday 11 August 2008 13:41:46 Thiago Macieira wrote:
> > > Brad Hards wrote:
> > > >G'day,
> > > >
> > > >I'm trying to use QTest::ignoreMessage to verify some QDebug output.
> > >
> > > Stop. Don't verify qDebug, since those go away in release builds. And
> > > release builds should not have debugging information.
> > >
> > > You can and should verify qWarnings, though.
> > >
> > > (The same goes for the kDebug/kWarning versions)
> >
> > That would be a valuable addition to the QTestLib documentation.
> > Currently it implicitly suggests to verify qDebug.
>
> If you were to have qDebug outputs, yeah, you could verify them.
>
> But applications aren't supposed to have qDebug/kDebug in the first place.
> Those are meant for debugging. They will disappear in release mode. So how
> will you verify them if they are not there?

Yes, all I'm saying is that this would fit nicely as a @note in the 
ignoreMessage documentation.

> > > >Any suggestions?
> > >
> > > There's an extra space: "Wont Work ". It's a side-effect of the
> > > automatic spacing that qDebug does.
> >
> > If you'd ask me I'd say ignoreMessage is flawed. You want your tests to
> > be as robust as possible. 90% of the time they should not be forced to
> > care about capitals, punctuation and even less trailing white-spaces in
> > warning messages. A version with a QRegExp might solve this.
>
> That will not happen.
>
> First of all, QTestLib is a minimalist library. Since it's used to test Qt
> itself, it avoids using most of Qt. Also, many portions of Qt can be
> disabled on certain builds, so QTestLib cannot use anything that can be
> disabled. Therefore using QRegExp in QTestLib is never going to happen.

I see. Well failing that one could have a version that does case & space 
insensitive 'contains' verification.

> Second, if you want to verify a message, you want to verify that the exact
> message is showing up. Any deviation could be problematic. We do test for
> pixel-perfect rendering, so why not text-perfect outputs?

Not sure that I'll convince you but I'll give it a shot anyway. A small use 
case would be:

Jan writes a test for a "Woops, File Not Found!  " warning. During a code 
review,  Anna modifies this warning to "Failed to read from target, file not 
found.". She compiles, runs the test suite and gets a red bar. She is now 
forced to modify the test, recompile and rerun the suite. Utter waste of time.

What we have here is a violation of the principle that unit tests should only 
fail when there's an actual bug in the unit under test. A set of wrong pixels 
in a widget is a bug, a change of wordings in a warning message mostly isn't.


Manuel

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]