JUnit Test

[Generic1]

Hallo,

bei und wird das Testen eher vernachlässigt und daher kennt sich in unserem Team auch niemand do richtig aus. Daher versuche ich jetzt mit den Tests nachzuziehen.
Meine Frage wäre, wie teste ich eine Datenbankverbindung, da bekomme ich ja z.B.: ein ResultSet, ein Connection- Object usw. zurück.
teste ich da ob ich ein bestimmtes Objekt zurückbekomme oder teste ich einfach die resuldate aus der Datenbank, da dann sowieso alles klappen muss, um die Daten aus der DB zu bekommen?

 

[Foermchen82]

du machst deinen Test so granular wie möglich um später sagen können was gekracht hat.

Also
1. Verbindung
2. Statement
3. Daten

und das alles mit verschiedenen Parametern

 

[maki]

ResultSet testen?
Connection?
Naja, eigentlich reichen da doch die Daten, oder?

DBunit + Back door setup wäre eine Möglichkeit: Back Door Manipulation at XUnitPatterns.com

 

[kama]

Hallo,

bei und wird das Testen eher vernachlässigt und daher kennt sich in unserem Team auch niemand do richtig aus. Daher versuche ich jetzt mit den Tests nachzuziehen.

Der Klassiker...Tests werden hinterher geschrieben....nicht krum nehmen höre ich immer wieder...

Meine Frage wäre, wie teste ich eine Datenbankverbindung, da bekomme ich ja z.B.: ein ResultSet, ein Connection- Object usw. zurück.

Möchtest Du tatsächlich die Datenbankverbindung Testen oder ob die Parameter zur Verbindung korrekt sind (also username, password, url)...?

teste ich da ob ich ein bestimmtes Objekt zurückbekomme oder teste ich einfach die resuldate aus der Datenbank, da dann sowieso alles klappen muss, um die Daten aus der DB zu bekommen?

Ich würde einen bestimmten Datenbestand in die Datenbank einfüllen (dbUnit ?) und dann in einem Test die Daten einfach zu lesen...

Wenn das klappt hast Du zwei Dinge. 1. Die Verbindung ist in Ordnung und das Datenholen funktioniert...

Die Frage ist wie die Applikation strukturiert ist? (DAO, Service Schicht etc. ?)

MfG
Karl Heinz Marbaise

 

[fastjack]

Mocking wäre auch zu empfehlen, z.B. EasyMock

 

[bygones]

Der Klassiker...Tests werden hinterher geschrieben....nicht krum nehmen höre ich immer wieder...

das war auch mein erster Gedanke ;-)

imo ist es toedlich wenn man sich mit Testing nicht sehr auskennt, dann tests nachzuziehen, da diese zu grosser Wahrscheinlichkeit a) schwer zu implementieren sind, b) extrem bruechig und c) nicht testen was die Implementierung tun soll, sondern was sie tut.
Ergebnis ist dass der Sinn und der Vorteil von Testing aufgrund erhoehten Frustration sich nicht zeigt und man dass dann lieber wieder sein laesst.

Sozusagen - testen von legacy code ist einfach ne besch*** Sache fuer jeden Entwickler ;-)

Ansonsten wie die meisten hier schon sagten: Das wichtigste ist rauszubekommen, WAS will man testen. DbVerbindungen oder Serverconnections zaehlen def. nicht dazu