Wie Testet Man Guis
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

RobertCMartin schrieb am 17.Juni 2002 in news:comp.software.extreme-programming

Checking the visual appearance is only one very small part of GUI
testing; and it is the only part that doesn't yeild to Junit testing.
Everything else can be tested automatically without any additional
tools of effort.

For the visual appearance, it is possible to buy tools like WinRunner,
but I don't recommend this unless you are planning on shipping
hundreds of thousands of shrink-wraps.  Visual inspection of the
appearance is probably adequate, and can be done at strategic moments
during the release.

Everything else can be tested automatically.  The strategy is actually
quite simple, though some find it counter-intuitive.  It works like
this:

1. You put the GUI code into a module called the View.  You keep the
View very thin.  You don't want *any* intelligence inside it.  Rather
you put this very thin View behind an interface and control it from a
non-GUI module called the "Presenter".

2. The Presenter does not make any GUI calls.  It controls the GUI
through the View.  If it wants an item in a listbox to be selected, it
calls the appropriate method on the view.  If it wants to grey out a
button, it calls the appropriate method of the View.  The Presenter
manages all the intelligence of the GUI, without actually knowing
anything about the GUI API.  The View presents an abstraction of the
GUI that the Presenter can manipulate.

3. You write tests for the Presenter.  This is trivial since the
Presenter is a pure computational module.

4. The tests you write for the View do not check the way the GUI
looks.  Rather they test the "wiring" of the GUI.  For example, the
tests check to see that the main window contains a set of radio
buttons.  It tests to see that the radio buttons are named correctly.
It tests that each group of radio buttons shows mutually exclusive
behavior.  It mimics mouse and keyboard events and tests that the
correct callback functions are called (using a MockObject interface or
a Self Shunt.)

That's it.  The only thing remaining is to actually look at the screen
and play with the interface.  And that can be done at the end of the
iteration.

(kompletter Thread bei Google Groups)

Diskussion

Das klingt sehr interessant. Gibt es irgendwo ein Beispiel dazu? -- MatthiasBohlen

Nicht, dass ich wüsste... :-( -- IljaPreuß

Ist das denn nicht genau das MVC-Design-Pattern (Model-View-Control)? Der Presenter, gekoppelt mit dem View, erinnert mich stark an die Control-Komponente vom MVC. Liest sich alles in Bezug auf MVC IMHO sehr ähnlich. --BerndSchiffer

Für den Unterschied siehe http://www.object-arts.com/EducationCentre/Overviews/MVC.htm

---

Ich verstehe das so:

MyPresenter? benutzt das Interface MyView?. Dann habe ich MyViewImpl?, welches das Interface erfüllt.

Was mir noch unklar ist: Wie wird der Persenter benachrichtigt?

--- StefanRoock


Siehe


KategorieTesten
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 11. Januar 2003 16:51 (diff))
Suchbegriff: gesucht wird
im Titel
im Text