Re: [Tasktlogger-devel] unit tests

[Roland W. <wal...@gm...>]

=84Jedenfalls sollte sich ein Test nicht darauf verlassen, dass gewisse
ben=F6tigte Daten in der Datenbank vorhanden sind=93 genau das meinte =
ich.

=20

Reihenfolge ist mir klar. Du meinst dass dann ein testDeleteDeveloper() =
im
setUP() zuerst einen Developer anlegt (soweit so klar).=20

Wenn jetzt die L=F6schfunktionalit=E4t nicht funktioniert, wie sollte =
dann die
Datenbank bereinigt werden? (Kann ihn ja nicht mit der gleichen Logik im
tearDown() l=F6schen -> hat ja einen Fehler)

=20

Lg=20

Roland

=20

  _____ =20

Von: tas...@li...
[mailto:tas...@li...] Im Auftrag von
Pratter Thomas
Gesendet: Freitag, 13. Oktober 2006 11:15
An: tas...@li...
Betreff: [Tasktlogger-devel] unit tests

=20

hallo,

unit tests werden in der reihenfolge ausgef=FChrt in der sie definiert =
sind.
Wenn es eine JUnit Klasse DeveloperDAOTest gibt, in der die Methoden in
folgender Reihenfolge vorkommen:

testCreateDeveloper()

testReadDeveloper()

testDeleteDeveloper()

hat sich das Problem erledigt.

Weiters k=F6nnen in jeder JUnit Klasse die Methoden setUp() und =
tearDown()
=FCberschrieben werden, welche vor bzw nach dem ausf=FChren der =
Testmethoden
ausgef=FChrt werden.

Jedenfalls sollte sich ein Test nicht darauf verlassen, dass gewisse
ben=F6tigte Daten in der Datenbank vorhanden sind, sondern sich seine
Testdaten vor dem Ausf=FChren der Tests anlegen und die Datenbank nach
Beendigung der Tests wieder bereinigen.

lg, thomas


-----Original Message-----
From: tas...@li... on behalf of =
Roland
WALTER
Sent: Fri 13.10.2006 10:00
To: tas...@li...
Subject: [Tasktlogger-devel] Unit Tests

Hallo,

ich habe eine Frage zum Thema Unit Tests.
Wie wird sichergestellt, dass vor Testbeginn ein konsistenter Datensatnd =
in
der DB besteht auf den der Test zur=FCckgreifen kann.
z.B: Delete Developer -> Es sollte vor dem Test bereits sichergestellt =
sein
dass ein bestimmter Entwickler in der Datenbank vorhanden ist.

Da alle Testf=E4lle in einer Testsuite durchlaufen werden, m=FCsste =
eigentlich
vor jedem Test die Datenbank in dem Zustand sein, welchen sich der Test
erwartet.

Anders Beispiel getAllDevelopers() -> hier wird der Test =FCberpr=FCfen =
ob die
Anzahl er zur=FCckgelieferten Developer Objekte der erwarteten Anzahl
entsprechen.

Gibts er hierzu Erfahrungen, Vorschl=E4ge, Anregungen?

Lg
Roland=20