Komponententests

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Komponententests

    Hi zusammen,
    ich hätte mal ne frage zum Komponententest, nehmen wir an wir haben so eine Klasse
    Im Konstruktor oder irgendeiner anderen Methode wird eine Methode aufgerufen die Variablen veränderen.

    Quellcode

    1. public class X{
    2. int a;
    3. string b;
    4. List c
    6. public X(){
    8. }
    10. public X(int x){
    11. a = x;
    12. init();
    13. }
    15. public init(){
    16. b = "abc";
    17. c = new List(1,2,3,4);
    18. }
    20. }
    Alles anzeigen


    wie würdet ihr den Unittest erstellen?
    beim Aufruf der 2. Kontruktors würdet ihr nur den wert von a prüfen und den anderen Testcase für die methode init machen oder würdet ihr gleich alle 3 werte(a,b,c) nach dem erzeugen des objektes prüfen?
    was wäre für euch ein Unit in diesem Fall?
    MfG ShureG

    There are 10 kinds of people. Those who understand binary notation, and those who do not.

  • Najaaaaa...
    Wenn das Beispiel so einfach wäre, würde ich natürlich sagen. Man braucht keinen Unit Test für Zahlen die im Konstruktor hinterlegt sind. Das ist einfach nur Codedopplung.

    Ansonsten gehört init() vermutlich eher private und damit fällt die Wahl auf den Konstruktor Test.

    Andererseits finde ich komplexe Konstruktoren ziemlich hässlich!
    Objekte sollten nicht kompliziert sein. Wenn du einen komplexen Ablauf abbilden willst, dann nimm doch lieber eine statische Methode, die eine Instanz von X erzeugt und diverse Parameter setzt.

    Die kannst du dann als "Unit" testen :)

  • na ja so einfach das in wirklichkeit nicht.
    wir entwickeln in PL/SQL und alles umzugestalten kann ich nicht :)
    muss aber unit-test schreiben :huh: und da die konstrukte da relativ komplex sind, überleg ich wie ich es in kleine häpchen zerlege

    stimmt aber die methode gehört private. muss wohl gesamt betrachten
    MfG ShureG

    There are 10 kinds of people. Those who understand binary notation, and those who do not.

  • Das Beispiel ist ziemlich unglücklich gewählt. Mit Unit-Tests testet man die nach außen angebotene Schnittstelle / Funktionalität einer Methode / Klasse, oder ums mal anders zu sagen: ob sie ihren Vertrag erfüllt. Und von der eigentlichen Funktionalität der Klasse ist in deinem Beispiel nichts zu sehen. Private Methoden und Attribute sind daher kein Gegenstand von Unit-Tests, auch Trivialfunktionalitäten wie Getter und Setter im Normalfall nicht, da sie durch das Testen der Methoden indirekt mitgetestet werden.

  • Hi,

    also wie im Post über mir beschrieben testet man damit methoden.
    Dabei ist zu beachten das man die einen junit test dann richtig schreibt wenn man ihn schreibt bevor man mit dem entwickeln des programmes beginnt.
    Dies setzt voraus das du weist was du in die auszuführende Methode hineinstopfst und das du auch weist was am ende rauskommen soll.
    Einfach irgendwas reinstopfen und dann mal schaun was am ende herausfällt ist nicht der richtige Weg.

    In deinem Fall nehme ich an das es sich um pl/sql packages handelt die du testen willst.
    Hier würdest du:
    1: Test vorbereiten, dh. die Datenbank in einen definierten zustand bringen in dem du weist welche relationen vom packages angepackt werden, wie sie vorher aussahen und wie sie nachher aussehen sollen.
    2: Der Test selbst, hier rufst du dann lediglich das packages mit ein paar parametern auf, und prüfst nach dem durchlaufen ob die Datenbank sich in dem erwartetem zustand befindet.
    3: Aufräumen, hier stellst du den ursprünglichen zustand wieder her, damit du den test nochmal laufen lassen kannst.

    In einem Beispiel:
    Du hast eine tabelle in der sich email nachrichten befinden. Dabei gibt es eine Spalte "GELOESCHT", wenn der kenner 1 ist soll bei einem nächtlichen aufräumlauf die files (Attachements) sofern vorhanden gelöscht werden und der Eintrag aus der Tabelle entfernt werden. Dabei hast du dann noch einen TDA Trigger auf der Spalte der Die Einträge in eine andere Tabelle sichert.
    Das Package nightly_cleanup macht dabei die aufräum arbeit.

    In einem Beispiel würden die Steps dann folgendermassen aussehen.
    1: Ein paar Datenbank einträge hinzufügen bei denen der Kenner gelöscht auf 1 ist, und bei einem eintrag ein attachement anhängen und das file auf die erwartete stelle auf der festplatte kopieren.
    2: Das package anstoßen, nach dem durchlauf prüfen ob die in Schrit 1 gemachten einträge weg sind, prüfen ob das file gelöscht wurde und prüfen Ob der Trigger die einträge in die backuptabelle geschrieben hat.
    3: Den ursprungszustand wiederherstellen, zb. die EInträge des triggers löschen.


    Dieses einfache Beispiel kann man beliebig erweitern. Wenn das Packages zb eine http seite generiert. könntest du deren vorhandensein testen, darin eine Stringsuche durchführen um ein element zu suchen. Du könntest die Seite auch ganz parsen und alles bis ins kleinste detail auswerten.
    Aber das Schema bleibt immer das oben beschriebene