AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Best Practice: Data Driven Test

Ein Thema von mh166 · begonnen am 9. Sep 2014 · letzter Beitrag vom 9. Sep 2014
Antwort Antwort
Benutzerbild von mh166
mh166

Registriert seit: 14. Nov 2004
Ort: Chemnitz
443 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#1

Best Practice: Data Driven Test

  Alt 9. Sep 2014, 12:11
Hallo,

ich muss mal wieder mit einer Grundsatzfrage stören. Ich habe in meinen Tests eine Funktion, die XML-Daten lädt und diese dann weiter verarbeitet. Jetzt sollen dafür aber verschiedene Inputs getestet werden, um möglichst alle Varianten zu testen.

Mal drei Beispiele:
Code:
1) Falsches Root-Element
========================
<wrongRoot />

2) Nur Eltern-Element enthalten
===============================
<correctRoot />

3) Inklusive Kind-Elemente
==========================
<correctRoot>
  <childOne />
  <childTwo />
</correctRoot>
Das sind jetzt kurz sehr simple Beispiele, die in der Praxis natürlich deutlich umfangreicher gestaltet sind.

Nun die Frage: wie stelle ich das am Besten in meinen Tests dar? Zur Info: ich nutze DUnitX als Test-Framework.

Einerseits könnte ich jetzt allesamt in den Test-Klassen hardcoden. Außerdem gibts das [TestCase(parameters)] Attribut. Doch dort den XML-String rein zu fädeln ist unhübsch.

Am liebsten wäre mir ja eine Möglichkeit die Daten in ein eigenes Verzeichnis zu stecken und dann dynamisch für jede Datei dort die Daten zu laden und den Test auszuführen.

Da ich aber noch ganz am Anfang meiner Unit-Test-"Karriere" stehe, möchte ich gern wieder eure Meinung dazu hören: wie löst mans am sinnvollsten? Oder verfehle ich hier wömöglich mal wieder den Zweck von Unit-Tests? (Ich hoffe nicht... )
Tiefgründige Sätze unserer Zeit:
Zitat von Luckie:
Und diesen Token zur Laufzeit zu modifizieren würde bedeuten, dass du zur laufzeit das Token ändern musst.
  Mit Zitat antworten Zitat
Benutzerbild von JasonDX
JasonDX
(CodeLib-Manager)

Registriert seit: 5. Aug 2004
Ort: München
1.062 Beiträge
 
#2

AW: Best Practice: Data Driven Test

  Alt 9. Sep 2014, 13:05
Normalerweise hat man die Daten, die für Tests benötigt werden, in den Testklassen selbst. Im Endeffekt sind einfache Strings, die als Parameter für die testenden Methoden gelten, auch nix anderes als Testdaten.
Wenn diese Daten zu groß oder umständlich sind, in eine Unit zu stecken (oder wenn sie die Lesbarkeit dieser arg beeinträchtigen) spricht nichts dagegen, diese aus anderen Resourcen, bspw. Dateien zu lesen.

In pseudocode würde dann das bspw. so aussehn:

Code:
const WRONG_ROOT_DATA_FILE = './wrongRoot.xml';
const CORRECT_ROOT_DATA_FILE = './correctRoot.xml';
const CORRECT_ROOT_WITH_CHILDREN_DATA_FILE = './correctRootWithChildren.xml';

[Data] loadXmlDataFromFile(path) { sehr, sehr, sehr einfacher Code zum laden einer Datei }

test_processTree_wrongRoot()
  data = loadXmlDataFromFile(WRONG_ROOT_DATA_FILE);
  // Test mit den daten

test_processTree_correctRoot()
  data = loadXmlDataFromFile(CORRECT_ROOT_DATA_FILE);
  // Test mit den daten

Ich würde aber empfehlen, das Laden und Verarbeiten zu trennen. Zum einen ist es dann einfacher Testbar, zum anderen kannst du dann bspw. das Laden auch woanders verwenden, oder solltest du die Daten mal anders laden wollen, wäre das dann auch kein Problem
Mike
Passion is no replacement for reason
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe
Online

Registriert seit: 20. Jan 2006
Ort: Lübbecke
10.934 Beiträge
 
Delphi 12 Athens
 
#3

AW: Best Practice: Data Driven Test

  Alt 9. Sep 2014, 13:25
Ich habe da mal vor einiger Zeit was dazu geschrieben. Allerdings kann ich nicht sagen, ob das auch unter DUnitX so noch funktioniert.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#4

AW: Best Practice: Data Driven Test

  Alt 9. Sep 2014, 15:14
Streng genommen ist es kein Unittest, wenn I/O verwendet wird. Es ist irgendwas. Und es testet. Aber eben kein Unittest. Einfach deshalb, weil das Verändern der Dateien deinen Test zerschießt.

Es ist vollkommen legitim, die Testdaten im Test selbst als Konstante zu deklarieren.

Ähnliches gilt z.B. auch für stored procedures. Es liegt nahe, in seinem DUnit-Framework auch Tests für die SP zu schreiben. Aber das sollte man nicht tun, weil Systemgrenzen überschrieben werden.
  Mit Zitat antworten Zitat
Benutzerbild von JasonDX
JasonDX
(CodeLib-Manager)

Registriert seit: 5. Aug 2004
Ort: München
1.062 Beiträge
 
#5

AW: Best Practice: Data Driven Test

  Alt 9. Sep 2014, 15:25
Streng genommen ist es kein Unittest, wenn I/O verwendet wird. Es ist irgendwas. Und es testet. Aber eben kein Unittest. Einfach deshalb, weil das Verändern der Dateien deinen Test zerschießt.
Der UnitTest kann gern IO verwenden. Für die zu testende Klasse sollten diese Operationen gemockt werden.
Was das Verändern von Testdaten betrifft: Das zerschießt jeden Test - unabhängig davon, ob das jetzt einkompilierte Dateien, Resourcen oder im Code definierte Konstanten sind.
Mike
Passion is no replacement for reason
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.007 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#6

AW: Best Practice: Data Driven Test

  Alt 9. Sep 2014, 16:31
Es liegt nahe, in seinem DUnit-Framework auch Tests für die SP zu schreiben. Aber das sollte man nicht tun, weil Systemgrenzen überschrieben werden.
Wenn du die Aussage zu "in seinen Unittests sollte man nicht ..." umformulierst, stimme ich dir zu. Ansonsten kann ich nur sagen, DUnit verbietet nicht, damit Integrationtests zu schreiben, es funktioniert sogar hervorragend.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:26 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz