Testdaten: Einerseits in der Datenbank, andererseits im Code

[slowfly]

Hallo zusammen

Im Anhang zum Thema, welches ich kürzlich erstellt habe (http://www.tutorials.de/java/393371-testdaten-db-erstellen-daten-fuellen-brauche-eure-meinungen.html), noch eine weitere Frage zum Thema Testdaten.

Ich denke, unabhängig davon, wie ich jetzt eine solche Datenkonserve fülle, habe ich immer das Problem, dass ich die Daten an zwei Orten haben muss, einerseits habe ich sie zum Beispiel in einem setup.sql-script, in einem XML für DbUnit oder wo auch immer. Andererseits habe ich sie bei mir im Code.

Beispiel:
sql:
insert into user (name, password) values ('slowy', 'pw')

code:

testAuthentication(){
  try {
    testClass.authenticate('slowy','pw');
  } catch(AuthException ex){
    fail("Exception caught");
  }  
}
testAuthenticationFailed(){
  try {
    testClass.authenticate('slowy','wrong');
    fail("Auth succeeded, but shouldn't");
  } catch(AuthException ex){
  }  
}

Wenn ich jetzt zum Beispiel die Anforderung habe, dass ein PW immer mind. 3-stellig sein muss, muss ich an zwei Orten das Passwort ändern. Für diesen kleinen Fall wäre das ja in Ordnung, aber wenn ich bei uns gewisse Projekte mit Dutzenden von Testfällen anschaue, welche wiederum mit Dutzenden von Werten arbeiten müssen, wird das sehr unübersichtlich und fehleranfällig.

Seht ihr das Problem auch so wie ich? Oder übertreibe ich hier?
Habt ihr mir irgendwelche Empfehlungen und Richtigungen, wie ich das "unter einen Hut" bekomme?

Besten Dank und Gruss
slowy

 

[socke77]

Hi,

ich glaube du wirfst zwei Dinge durcheinander.

Zum einen brauchst du Testdaten, welche du vor den eigentlichen Tests in die Datenbank populierst. Sozusagen als Ausgangszustand (User, Mandanten, Konten etc.)

Damit könntest du z.B. nach erfolgreichem Build und Deployment deine Applikation benutzen und hast einen Ausgangszustand für deine Integrationstest, Abnahmetests, Seleniumstest etc.

Was du jetzt hier meinst sind Testdaten für den eigentlichen Test, also als TestInput! Nehmen wir deinen Fall von oben, so müssen diese sich sogar unterscheiden, denn du möchtest doch keinen User mit einem Passwort, welches nicht erlaubt ist in der DB haben. Es sei denn für einen Migrationstest... aber das ist wohl ein Sonderfall.

Die reinen Inputdaten für deinen eigentlichen Test, also das was du übergibst würde ich nicht in die DB ablegen. Wozu auch?

Lege diese lieber als resource für deinen Test als csv, xml, dbunit xml oder sonstwas ab und lies das in einem Integration test ein. Diese Daten sind dann nicht identisch mit den Initialdaten die du z.B. per DBUnit beim Build in die DB spielst!
Du kannst auch mal mit Parameterized unit tests ausprobieren, aber ehrlich gesagt halt ich persönlich nicht so viel davon.

Übrigens, du kommst auch nicht daran vorbei an zwei Orten das PW zu ändern, denn das eine File dient als Input für den Test das andere als Initialfüllung.

Wieder Beispiel Initial:
user ('slowly', 'pwx') // 3-stellig in der db

Beispiel testinput daten:
user ('slowly', 'pwx') // input für OK testfall
user ('slowly', 'pw') // input für Fehler testfall

Du MUSST ja explicit den Fehlerfall abtesten, folglich kommst du nicht daran vorbei das explicit zu schreiben.
Kommt nun die Anforderung, dass ab sofort das PW mind. 5-stellig und aus Zahlen und Buchstaben bestehen muss, musst du sowieso den Test anpassen.

Hoffe das war klärend und nicht noch verwirrender

Gruß

 

[slowfly]

Hallo Socke

Danke für deine Antwort

Übrigens, du kommst auch nicht daran vorbei an zwei Orten das PW zu ändern, denn das eine File dient als Input für den Test das andere als Initialfüllung.
Ja, das ist eben das Problem =)
Ich probier's nochmal anders zu erklären, was mir da genau vorschwebt:

populate
insert into account (id,userid,email,pw) values (1,slowy,slow@fly.com,pw)

test
testAuthenticate(){
AuthResponse response = userService.authenticate(slow@fly.com,pw);
assertTrue(response.getSuccessful(), true);
assertEquals(response.getAccount.getId(), 1);
assertEquals(response.getAccount.getUserId(), slowy);
}
(hab mal die code-tags weggelassen, damit man die fett markierte Werte sieht)

Alles was fett markiert ist, hätt ich gern in zentraler Stelle. Ich weiss ja nicht, ob ihr auch einen Sinn drin erkennt, aber ich würde es so rechtfertigen, dass man eben nur an einem Ort Daten ändern, aufnehmen und je nachdem wieder löschen muss. Gleichzeitig müsste es ja übersichtlicher sein,... wie seht ihr das? Würde ich mir da eher ein Bein stellen, wenn man diesen Weg gehen würde?

Danke und Gruss
slowy