Test Driven Development methodology applied to GUI development

David Dibben | 12 May 2004 04:25

Picon

Re: [TFUI] testing Qt code

> dammak rafik wrote:
> > table respecting MVC pattern.two for testing GUI how
> > I must do?test 
> > tools for this case?I am developing a kind of unit
> > testing (no with 
> > cppunit) and I like respect this method in GUI
> > development.

We have been using Qt and CppUnit together with out too many problems. 

On Tue, 11 May 2004 15:15:58 -0700 (PDT)
Phlip <phlipcpp@...> wrote:
> Your first question: What is the Qt equivalent of
> gtk_main(), and how to not call it?

I don't think that there is an equivalent in Qt. The main event loop is
generally started by calling the exec() function on QApplication. SInce
this is usually called from main() it is easy not to call in the tests.. 

> The second question: How to optionally call it?

Much of the testing of the interface can be done without using the event
handling mechanisms of Qt. If it is necessary to test the results of
events then QApplication::processEvents()  allows all pending events to be
processed and then returns control to the test. 

Regards

David

(Continue reading)

Phlip | 12 May 2004 07:06

Picon

Re: [TFUI] testing Qt code

dammak rafik wrote:

> table respecting MVC pattern.two for testing GUI
> how
> I must do?test 
> tools for this case?I am developing a kind of
> unit
> testing (no with 
> cppunit) and I like respect this method in GUI
> development.

David Dibben wrote:

> We have been using Qt and CppUnit together with out
> too many problems. 

This helps dammak, so he must reply before we try to
help more.

But David also answered my questions:

> Phlip wrote:

> > What is the Qt equivalent of
> > gtk_main(), and how to not call it?

> I don't think that there is an equivalent in Qt. The
> main event loop is
> generally started by calling the exec() function on
> QApplication. SInce

(Continue reading)

dammak rafik | 12 May 2004 09:32

Picon

Re: [TFUI] testing Qt code

Hi,

My question is about : how I must do to respect the test driven 
development in the case of Qt library for GUI.I have found two test 
tools(not free) :squish (froglogic.com) and Kdexucator(ics.com).I had 
found also Qtunit but it is old version and hadn't be update since two 
years.I am a very newbie in everything related testing and I am 
searching to respect a good policy testing in the same time of 
developing(I am doing a XP process).I will repeat ,I am try to respect 
MVC pattern to separate control to view.
For the previous code sended by david and philip(thanks) how I can 
used it to improve my code and testing in this case.

P.S spigot????

-- In TestFirstUserInterfaces@..., Phlip
<phlipcpp@...> 
wrote:
> dammak rafik wrote:
> 
> > table respecting MVC pattern.two for testing GUI
> > how
> > I must do?test 
> > tools for this case?I am developing a kind of
> > unit
> > testing (no with 
> > cppunit) and I like respect this method in GUI
> > development.
> 
> David Dibben wrote:

(Continue reading)

David Dibben | 12 May 2004 11:43

Picon

Re: [TFUI] testing Qt code

On Wed, 12 May 2004 07:32:33 -0000
"dammak rafik" <medrafik2000@...> wrote:
> My question is about : how I must do to respect the test driven 
> development in the case of Qt library for GUI.I have found two test 
> tools(not free) :squish (froglogic.com) and Kdexucator(ics.com).I had 
> found also Qtunit but it is old version and hadn't be update since two 
> years.

As I understand it Qtunit is basically just a GUI for running CppUnit
tests (plus a few other features.) The current version of CppUnit also
comes with QtTestRunner which is another Qt GUI for running the unit
tests. 

A couple of points about these

1) You don't need to use these to use CppUnit with Qt. I generally use the
text version of the test runner. However, you do need to create a
QApplication object somewhere before using any of the Qt widgets.

2) You can't use QtTestRunner, as it ships, with CppUnit when running GUI
tests.   The problem is that QtTestRunner runs each test in a separate
thread. This makes the test runner GUI nice and responsive during the test
run but if you try to create some of the Qt widgets, such as QListView
which generate events in your test then on windows your tests will crash.
The problem is that Qt widgets must be created in the main thread, so if
they are created in your test which is running in a separate thread then
at best you get undefined/unexpected behaviour (Unix) or it just crashes
(Windows).

The solution is either to use the text test runner which does not use

(Continue reading)

Phlip | 13 May 2004 07:58

Picon

[TFUI] User Input Validation

Imagine if you operate a walled city, and you order
the best elite troops to guard the walls, scout for
approaching enemies, and make a note of each character
entering the city gates. But you dismiss the
constables and investigators who rooted out crime and
corruption on the city streets and inside your palace.
You would not remain in charge for very long.

If your program intercepts any and all bad user input
at the GUI Layer, your sense of security may be false.
All code layers must be able to reject such data, at
the cheapest moment to detect the problem. Then, an
accurate report of the problem must transmit back to
the user; literally translated into their language.

Learn exception handling for your language, and make
certain you understand its pitfalls.

User input may cause any layer to throw an exception.
The exception must cause any intervening layers to
roll their state back to before the input happened.
Keep a single handler in your message pump procedure
itself to catch, log, localize, and present the bad
news. The /Exceptional C++/ books by Herb Sutter cover
these topics in great detail, with scenarios that
should also be studied in other languages.

A Layer is two generalized Fa�ades, one for each other
Layer nearest it. By "Fa�ade Pattern�, we mean the
published modules - the ones other layers call -

(Continue reading)

Phlip | 12 May 2004 10:44

Picon

Re: [TFUI] testing Qt code

dammak rafik wrote:

> My question is about : how I must do to respect the
> test driven 
> development in the case of Qt library for GUI.I have
> found two test 
> tools(not free) :squish (froglogic.com) and
> Kdexucator(ics.com).I had 
> found also Qtunit but it is old version and hadn't
> be update since two 
> years.I am a very newbie in everything related
> testing and I am 
> searching to respect a good policy testing in the
> same time of 
> developing(I am doing a XP process).I will repeat ,I
> am try to respect 
> MVC pattern to separate control to view.
> For the previous code sended by david and
> philip(thanks) how I can 
> used it to improve my code and testing in this case.

If you have a GUI Toolkit, and if it stores objects in
memory before painting them (like most do) then those
test tools will solve a problem that you don't have.

> P.S spigot????

Faucet. 

When you write a debugging trace statement, like this:

(Continue reading)

David Dibben | 12 May 2004 07:49

Picon

Re: [TFUI] testing Qt code

 On Tue, 11 May 2004 22:06:04 -0700 (PDT)
Phlip <phlipcpp@...> wrote:
> > Phlip wrote:
>  - Treat I/O Like a Spigot. When you want to see
>        a window in a specific state, such as just
>        after a test case, you should be able 
>        to raise that window with very little 
>        thinking or tweaking. Given reveal(aWin),
>        what can we put inside reveal that displays
>        _any_ window? For Qt, I might borrow the 
>        source of the exec() method and replicate 
>        it. Or I might marshall aWin into another
>        process space, and feed it to a QApplication
>        in there, if that works.

At a first pass, I tried code below as an  implementation for reveal. All
Qt's windows derive from QWidget, so we can use that as the argument to
reveal.  Calling processEvents() means  that no user interaction with the
window is possible, only viewing.

If user interaction is required then reveal needs to be slightly more
complex.

Regards

David

#include <qdialog.h>
#include <qapplication.h>
#include <iostream>

(Continue reading)

Phlip | 12 May 2004 09:46

Picon

Re: [TFUI] testing Qt code

David Dibben wrote:

> At a first pass, I tried code below as an 
> implementation for reveal. All
> Qt's windows derive from QWidget, so we can use that
> as the argument to
> reveal.  Calling processEvents() means  that no user
> interaction with the
> window is possible, only viewing.

Thanks! This would soon appear, as-is, on its
appropriate Wiki.

All GUI Toolkits are different, but all use a similar
event driver system, huh?

Can you run processEvents in a loop?

> If user interaction is required then reveal needs to
> be slightly more
> complex.

You need it for the next step:

 - Temporary Interactive Test

That means, while the window is revealed, you click on
it and see what happens. Maybe you invoke a breakpoint
or a trace statement.

(Continue reading)

David Dibben | 12 May 2004 11:30

Picon

Re: [TFUI] testing Qt code

On Wed, 12 May 2004 00:46:05 -0700 (PDT)
Phlip <phlipcpp@...> wrote:
> > reveal.  Calling processEvents() means  that no user
> > interaction with the
> > window is possible, only viewing.
> Thanks! This would soon appear, as-is, on its
> appropriate Wiki.

I am afraid that the version I posted only partially works. The
processEvents call only processes events that have already been sent, so
if displaying the window generates other events (which it will) then those
events won't get processed by the call. One solution is to call
processEvents several times in a row in the reveal function.

> Can you run processEvents in a loop?

Yes. In fact this is its main use. The documented reason that 
processEvents exists is so that you can call it periodically during a long
calculation to allow the gui to be refeshed or allow the user to cancel
the calculation without having to resort to running the calculation in a
separate thread. Something like:

  while (stuff_still_to_do) {
      do_some_stuff();
      qApp->processEvents();
  }

>  - Temporary Interactive Test

(Continue reading)

Phlip | 13 May 2004 08:07

Picon

Re: [TFUI] testing Qt code

> > Can you run processEvents in a loop?

David Dibben wrote:

> Yes. In fact this is its main use. The documented
> reason that 
> processEvents exists is so that you can call it
> periodically during a long
> calculation to allow the gui to be refeshed or allow
> the user to cancel
> the calculation without having to resort to running
> the calculation in a
> separate thread. Something like:
> 
>   while (stuff_still_to_do) {
>       do_some_stuff();
>       qApp->processEvents();
>   }

If that generally works it's the best way. You can
still test before, during, and after the loop spins.

You can also put a call to a window capture program in
the loop, assemble serieses of pictures into
animations, toss them onto a file server, and make the
executives review them first before calling.

> OK, a first attempt at this could look something
> like below. This code
> could almost certainly do with some improvement but

(Continue reading)

Return

Return to gmane.comp.programming.test-first-user-interfaces.

Project Web Page

Test Driven Development methodology applied to GUI development

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane