Test Driven Development methodology applied to GUI development

David Dibben | 12 May 2004 11:43

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)

headers

Phlip | 13 May 2004 07:58

[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)