TDD (dt. testgetriebene Entwicklung)


versucht jede Softwarekomponente durch automatisiert ausgeführte Komponententests (Unit-Tests) zu testen. Zweck ist hierbei, unbemerkt auftretende Seiteneffekte bei Änderungen (Refactoring) oder Erweiterungen zu vermeiden. Das erhöht die Qualität der Software und die Produktivität des Entwicklers.


Bei testgetriebener Entwicklung wird versucht, zuerst den Test zu schreiben und dann die entsprechende Funktionalität zu implementieren. Das bewirkt, dass man sich zuerst über das erwartete Verhalten der Methode Klarheit verschafft und im Sinne möglichst vollständiger Testabdeckung kein Test „vergessen“ wird.


Testgetriebene Entwicklung


Abb. 1: Testgetriebene Entwicklung



Demoprogramm


  1. /* zu testende Klasse
  2. * */
  3.  
  4. using System;
  5.  
  6. namespace testDemoTDD
  7. {
  8.     public class Bruch
  9.     {
  10.         private double zaehler;
  11.         private double nenner;
  12.  
  13.         public Bruch(double z, double n)
  14.         {
  15.             zaehler = z;
  16.             nenner = n;
  17.         }
  18.         public double quotient()
  19.         {
  20.             if (nenner == 0)
  21.                 throw new DivideByZeroException();
  22.             return zaehler / nenner;
  23.         }
  24.     }
  25. }

Listung 1: Datei Bruch.css mit der zu testenden Klasse


  1. /* Testklasse (jede zu testende Klasse erhält eine eigene Testklasse)
  2. * */
  3. using System;
  4. using Microsoft.VisualStudio.TestTools.UnitTesting;
  5.  
  6. namespace testDemoTDD
  7. {
  8.     [TestClass]
  9.     public class testBruch
  10.     {
  11.         [TestMethod]
  12.         public void testQuotient1()
  13.         {
  14.             Bruch b1 = new Bruch(1,2);
  15.             Assert.AreEqual(0.5, b1.quotient());
  16.         }
  17.         [TestMethod]
  18.         [ExpectedException(typeof(DivideByZeroException))]
  19.         public void testQuotient2()
  20.         {
  21.             Bruch b1 = new Bruch(1, 0);
  22.             b1.quotient();
  23.         }
  24.     }
  25. }

Listung 2: Die dazugehörige Testklasse in der Datei BruchTest.cs


Oberfläche des Demoprogramms

Abb. 2: Oberfläche des Testprogramms


Oberfläche und Logikschicht müssen sauber getrennt werden, damit die Unittest die Logik vollständig abdecken können:

Trennung von Logikschicht und UI

Abb. 3: Trennung von Logikschicht und UI

Last modified: Thursday, 23 August 2018, 8:25 PM