docs/index.html

<!doctype html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

        <title>UnitTests</title>
        <link rel="stylesheet" href="./css/reveal.css">
        <link rel="stylesheet" href="./css/theme/solarized.css" id="theme">
        <link rel="stylesheet" href="./css/highlight/solarized-light.css">
        <link rel="stylesheet" href="./css/print/paper.css" type="text/css" media="print">
          <link rel="stylesheet" href="./_assets/custom.css">


    </head>
    <body>

        <div class="reveal">
            <div class="slides"><section  data-markdown><script type="text/template">

# Unit-Tests

</script></section><section ><section data-markdown><script type="text/template">
## Warum testen wir?

</script></section><section data-markdown><script type="text/template">
### Ein Auto auf dem Rollenprüfstand
<ul>
<li class="fragment" data-fragment-index="1">Tuner: die Leistung seines Fahrzeugs feststellen</li>
<li class="fragment" data-fragment-index="2">TÜV: Feststellen der Farbe des Aufklebers für die Windschutzscheibe</li>
<li class="fragment" data-fragment-index="3">Hersteller: sicherstellen das die vom Kraftfahrbundesamt/der EU vorgegebenen Spezifikationen eingehalten werden</li>
</ul>

</script></section><section data-markdown><script type="text/template">
### Warum testen wir?
<ol>
<li class="fragment" data-fragment-index="1">Systematische Ermittlung der Fähigkeiten eines Testgegenstandes</li>
<li class="fragment" data-fragment-index="2">Übereinstimmung des Testgegenstandes mit einer Spezifikation sicherstellen</li>
</ol>

</script></section><section data-markdown><script type="text/template">
### Wie wird getestet?

<div id="left">

Definieren von:
<ul>
  <li>Rahmenbedingungen</li>
  <li>Eingangswerte</li>
  <li>erwartete Ausgangswerte</li>
</ul>

</div>

<div id="right">

<img src='https://g.gravizo.com/svg?@startuml;left to right direction;;node "component\nto be tested" as sut;card a;card b;card c;;a --> sut;b --> sut;sut --> c;@enduml'/>

</div>

</script></section><section data-markdown><script type="text/template">
### Unit-Tests

* Testgegenstand ist eine Methode, Klasse oder Komponente (Verbund von Klassen)
* definieren unterschiedliche Testfälle
  * können fachlich vorgegeben sein
  * je Testfall Erwartungswert
  * je Testfall Rahmenbedingungen (über korrekte Initialisierung)
* stellen sicher, dass Erwartungswerte mit realen Werten übereinstimmen

</script></section><section data-markdown><script type="text/template">
### Beispiel für UnitTest
```java
class ArrayListTest {
  @Test
  void testArrayListContains() {
    // Eingangswerte und Erwartungswert definieren
    List<String> in = Arrays.asList("Auto", "Brot", "Fuß")
    final boolean expected = true;

    // Rahmenbedingungen definieren und Test durchführen
    final List<String> sut = new ArrayList<>(in);
    final boolean containsBrot = sut.contains("Brot");

    // Spezifikation sicherstellen
    assertEquals(expected, containsBrot);
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Beispiel für UnitTest
```java
class ArrayListTest {
  @Test
  void testArrayListContains() {
    final List<String> sut = new ArrayList<>(
            Arrays.asList("Auto", "Brot", "Fuß"));
    assertTrue(sut.contains("Brot"));
  }
  @Test
  void testArrayListDoesNotContain() {
    final List<String> sut = new ArrayList<>(
            Arrays.asList("Auto", "Brot", "Fuß"));
    assertFalse(sut.contains("Blumen"));
  }
}
```

</script></section><section data-markdown><script type="text/template">
### 1. Übung - schreiben einfacher Tests

* [https://github.com/gaerfield/2019-02_utws.git](https://github.com/gaerfield/2019-02_utws.git)
* 20min
  * Ziel: Projekt aufsetzen und mit UnitTests vertraut machen
  * gradle-Projekt in IDE importieren
* Projekt "1_Toaster"
  * Klasse ArrayListTest suchen und ausführen
  * Klasse ToasterTest suchen und Tests implementieren

</script></section></section><section ><section data-markdown><script type="text/template">
## Testpyramide

</script></section><section data-markdown><script type="text/template">
### Warum testen wir?

* Übereinstimmung des Testgegenstandes mit einer Spezifikation sicherstellen
* ist ausgeliefert & wurde irgendwie getestet, warum dafür extra einen UnitTest entwickeln
* häufige Modifikationen an Software  <!-- .element: class="fragment" data-fragment-index="2" -->
  * durch Pflege, Anforderungsänderungen, Korrektur
  * UnitTests ermöglichen Wiederholung der bereits validen Testfällen
  * Sicherstellung, dass Änderungen keine neuen Fehler verursachen (Regressionen)

</script></section><section data-markdown><script type="text/template">
<!-- .slide: data-background="https://media.giphy.com/media/vvLWidwZNYH5e/giphy.gif"-->


</script></section><section data-markdown><script type="text/template">
### UnitTests allein reichen nicht

* UnitTest testet einzelne Einheit und kann nicht alle Fehler aufdecken
* **Integrationstests**: testen Zusammenspiel zwischen verschiedenen Programmen oder Programmteilen
* **Usability-Tests**: testet Gebrauchstauglichkeit einer Software
* **Behavior Driven Development / Systemtest**: Entsprechung der Software gegenüber den funktionalen und nicht-funktionalen Anforderungen sicherstellen.

</script></section><section data-markdown><script type="text/template">
### Testpyramide

<div id="left">
<ul>
<li>Metapher für optimale Balance der Softwaretests</li>
<li>UnitTests haben darin den größten Anteil</li>
<li>Service-Layer beinhaltet: Api-, Integrations- und Komponententests</li>
<li>UI sind automatisierte Klicktests</li>
</ul>
</div>

<div id="right">

  ![](https://martinfowler.com/bliki/images/testPyramid/test-pyramid.png)

  [Martin Fowler - TestPyramid](https://martinfowler.com/bliki/TestPyramid.html)

</div>

</script></section><section data-markdown><script type="text/template">
### Testpyramide

* UnitTests haben den größten Anteil, weil:
  * geringer Entwicklungsaufwand
  * einfach zu automatisieren
  * schnell durchzuführen
  * testen nur kleine Einheiten von Software (Fokus)
  * in der Regel keine externe Abhängigkeiten
* sind dadurch stabiler gegenüber Änderungen als Integrations oder UI-Tests

<!--### Integrationstest-->
<!--SucheMoeglicheEmpfaengerTest-->

</script></section><section data-markdown><script type="text/template">
## 2. Übung - Tennis

* Ziel: Refactoring existierenden Codes
* Experiment:
  * Gruppe **A**: refactoren ohne Tests
  * Gruppe **B** nutzt existierende Tests: refactoren, Tests laufen lassen
  * IntelliJ/Eclipse
    * Strg-Umschalt-Alt-T/Umschalt-Alt-T: Refactor
    * Strg-Shift-T/Strg-R: Zum Test springen
    * Alt-Shift-F10/Alt-Shift-X + T: (Test ausführen)
    * Strg-F5/Strg-F11: Test wiederholen

</script></section></section><section ><section data-markdown><script type="text/template">
## Lesbarkeit von Tests

</script></section><section data-markdown><script type="text/template">
### Dirty Tests

* sind schwer wartbar
* macht Produktiv-Code umso schwerer wartbar, denn Tests müssen zusammen mit diesem gepflegt werden
* typisches Symptome:
  * viele gleiche Tests mit nur subtilen Änderungen
  * ein Refactoring verursacht viele fehlschlagende Tests

</script></section><section data-markdown><script type="text/template">
### Test-Code ist wichtiger als Produktivcode

* Produtktivcode lässt sich aus Tests wieder herstellen
* umgekehrt aber Testcode nicht aus dem Produktivcode
* dokumentieren unser System
* verifizieren Korrektheit des Codes
* unterstützen das Design
* geben Sicherheit für Refactoring und fachl. Änderungen

</script></section><section data-markdown><script type="text/template">
### Halte deine Tests sauber

* folgl. für Tests gelten dieselben Code-Standards wie für Produktivcode:
  * lesbar
  * verständlich
  * flexibel
  * **keine** Duplikationen
* QualityDataServiceImplUnitTest

</script></section><section data-markdown><script type="text/template">
### Nutze statische Imports

```java
public ChildTest {
  @Test
  public void testChild(){
    Assert.assertTrue(new Child().giveLolly().isHappy());
  }
}
```

```java
import static org.junit.jupiter.api.Assertions.*;

public ChildTest {
  @Test
  public void testChild(){
    assertTrue(new Child().giveLolly().isHappy());
  }
}
```
<!-- .element: class="fragment" data-fragment-index="2" -->

</script></section><section data-markdown><script type="text/template">
### Vertausche nicht expected und actual
```java
List<String> limos = new ArrayList<String>("Bionade");
assertEquals(limos.get(0), "Apfelschorle");
```
```
org.opentest4j.AssertionFailedError:
Expected :Bionade
Actual   :Apfelschorle
```
<!-- .element: class="fragment" data-fragment-index="2" -->

</script></section><section data-markdown><script type="text/template">
### Nutze prägnante Testnamen

![](img/jenkins.png)

</script></section><section data-markdown><script type="text/template">
### Nutze prägnante Testnamen

* Bezeichner des Behavior-Driven-Design (BDD)
  * Given-When-Then/Should
  * in der Regel genutzt um natürlichsprachliche fachliche Testfälle zu definieren
  * aber unterstützen Verständlichkeit der Testnamen

</script></section><section data-markdown><script type="text/template">
### Nutze prägnante Testnamen
```java
public ChildTest {
  @Test
  public void testLolly(){
    Child child = new Child();   // given
    child.giveLolly();           // when
    assertTrue(child.isHappy()); // then should be happy
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Nutze prägnante Testnamen
```java
public ChildTest {
  @Test
  public void givenAChildWhenGettingALollyThenItShouldBeHappy(){
    assertTrue(new Child().giveLolly().isHappy());
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Nutze prägnante Testnamen
```java
public ChildTest {
  @Test
  public void testGettingLollyShouldBeHappy(){
    assertTrue(new Child().giveLolly().isHappy());
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Nutze prägnante Testnamen
```java
public KindTest {
  @Test
  public void testBekommtSchokoladeUndIstGluecklich(){
    assertTrue(new Kind().gibSchokolade().istGluecklich());
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Fange keine Exceptions im Test

```java
@Test
public void testFailEnsureNoSchema() throws Exception
{
  for (Object[] testData : getFailEnsureNoSchemaTestData())
  {
    String query = (String) testData[0];
    try
    {
      SqlQueryPatternAuthorizer.ensureNoSchema(query, SCHEMAS);
      assertTrue(query, false);
    }
    catch (IllegalSqlQueryExecutorException isqee)
    {
        // Test erfolgreich
    }
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Fange keine Exceptions im Test
 JUnit4:
```java
@Parameterized("getFailEnsureNoSchemaTestData")
@Test(expected = IllegalSqlQueryExecutorException.class)
public void testFailEnsureNoSchema(String query) throws Exception
{
  SqlQueryPatternAuthorizer.ensureNoSchema(query, SCHEMAS);
}
```
Junit5:
```java
@Parameterized("getFailEnsureNoSchemaTestData")
public void testFailEnsureNoSchema(String query) throws Exception
{
  assertThrows (
    IllegalSqlQueryExecutorException.class,
    () -> SqlQueryPatternAuthorizer.ensureNoSchema(query, SCHEMAS),
    "ExceptionMessage"
  )
}
```

</script></section><section data-markdown><script type="text/template">
### Initialisiere Tests möglichst lokal
```java
class Child {
  private Lolly lolly;

  @Before
  void init(){ this.lolly = new Lolly("Strawberry"); }

  @Test
  void testChildGetsLolly(){
    new Child().giveLolly(this.lolly);
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Initialisiere Tests möglichst lokal
```java
class Child {
  private LollyDb lollydb;

  @Before
  void init(){
    this.lollydb = new LollyDb("Strawberry");
    lollydb.insert("Strawberry", "Cherry", "Nut");
  }

  @Test
  void testChildGetsLolly(){
    Child child = new Child();
    child.giveLolly(lollydb.remove("Strawberry"));
    assertFalse(lollyDb.contains("Strawberry"));
    assertTrue(child.isHappy());
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Definiere mehrere Testklassen für eine Produktivklasse

```java
public class ChildGirlTest { /* ... */ }
public class ChildBoyTest { /* ... */ }
```

</script></section><section data-markdown><script type="text/template">
### Nutze nur eine Assertion je Test

```java
class Child {
  private LollyDb lollydb;

  @Before
  void init(){
    this.lollydb = new LollyDb("Strawberry");
    lollydb.insert("Strawberry", "Cherry", "Nut");
  }

  @Test
  void testChildGetsLollyShouldBeHappy (){
    Child child = new Child();
    child.setGender(Gender.GIRL);
    child.giveLolly(lollydb.remove("Strawberry"));
    assertFalse(lollyDb.contains("Strawberry"));
    assertTrue(child.isHappy());
    assertEquals(Gender.GIRL, child.getGender());
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Nutze nur eine Assertion je Test: Ausnahmen bestätigen die Regel

* Nutze mehrere Assertions nur dann, wenn die Parameter voneinander abhängig sind

```java
@Test
void testChildGetsGenderChangingLollyMakesItHappy(){
  Child child = new Child();
  child.setGender(Gender.GIRL);
  child.giveLolly(lollydb.remove("GenderChangingLolly"));
  assertAll(
    () -> assertTrue(child.isHappy()),
    () -> assertEquals(Gender.BOY, child.getGender())
  )
}
```

MarketValuesParserTest 0a548207ed13

</script></section><section data-markdown><script type="text/template">
### Nutze Parametrisierung von Tests

```java
class ParametrizedTest
{
  static Stream<Arguments> provideParseValues() {
    return Stream.of(
        Arguments.of("5", 5),
        Arguments.of("-5", -5),
        Arguments.of("0", 1)
    );
  }

  @DisplayName("tests parsing of Integers")
  @ParameterizedTest(name = "Test #{index}: {0} should be {1}")
  @MethodSource("provideParseValues")
  void testValue(String in, int expected){
    assertEquals(expected, Integer.parseInt(in));
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Bilde fachliche Anforderungen als Test ab

> Für Kunden vom Typ privat soll im Fall, dass keine Anrede zur Verfügung steht, das Mapping ohne Anrede und mit Sortname im Nachnamen erstellt werden

```java
@Test
void testPrivatkundeOhneAnredeNutztSortnameAlsMapping() {
  /*...*/
}
```

[PersonenMappingTest](https://confluence.eudemonia-solutions.de/pages/viewpage.action?pageId=70453289)

</script></section><section data-markdown><script type="text/template">
### 3. Übung - GildedRose

<small>

* Ziel: verfasse entsprechend der fachlichen Anforderungen UnitTests
* Item = SellIn: Ablaufdatum, Quality: Wertigkeit
* Mit jedem Tag wird verringert sich der Wert
* Nach Ablaufdatum verringert sich die Qualität doppelt so schnell
* die Qualität ist nie negativ
* "Aged Brie" erhöht seine Qualität je älter er wird
* die Qualität ist nie über 50
* "Sulfuras" ist ein Legendary-Item, muss nie verkauft werden und verringert nie seine Qualität
* "Backstage passes", steigt in seiner Qualität, je näher es dem Ablaufdatum kommt:
    * Qualität steigt innerhalb der letzten 10 Tage um das Doppelte
    * Qualität steigt innerhalb der letzten 5 Tage um das 3-fache
    * Qualität ist sofort nach dem Konzert 0

</small>

</script></section></section><section ><section data-markdown><script type="text/template">
## Testisolierung

</script></section><section data-markdown><script type="text/template">
### Isolation ist hart

* in der Praxis haben fast alle Klassen Abhängigkeiten
* Abhängigkeiten im Original zu gewährleisten:
  * verursacht unerwartete Seiteneffekte
  * potenziert Testfälle
  * ist zum Teil unmöglich
* Abhängigkeiten für den Test "simulieren": <!-- .element: class="fragment" data-fragment-index="2" -->
  * isoliert das SUT
  * ermöglicht Konzentration auf die für das SUT notwendigen Testfälle

</script></section><section data-markdown><script type="text/template">
### Mocks und Spies

* Mocks:
  * simuliert eine Instanz eines Objekts
  * Rückgabewerte für Methodenaufrufe können definiert werden
  * Aufrufe von Methoden können verfiziert werden
* Spy:
  * kapselt eine existierende Instanz eines Objekts
  * kann Methodenaufrufe "abfangen" und definierte Werte zurückliefern
  * Aufrufe von Methoden können verfiziert werden

</script></section><section data-markdown><script type="text/template">
### Mockframeworks

* JMock
  * nur Interfaces können gemockt werden
  * alle Methodenaufrufe und Verifikationen müssen vorher definiert werden
  * vereinzelt in älteren UnitTests verwendet
* Mockito
  * kann Klassen mocken
  * liefert sinnvolle Defaults (null, Optional.absent())
  * nutzt inuitivere Flow-Syntax
  * trennt Mock-Verhalten und Verifikation
  * wird bevorzugt eingesetzt

</script></section><section data-markdown><script type="text/template">
### Mockframeworks

* PowerMockito
  * erlaubt zusätzlich des Mocken von:
    * Konstruktoren
    * privater und statischer Methoden
  * nur einsetzen, falls tatsächlich notwendig

</script></section><section data-markdown><script type="text/template">
### JMock

```java
public class PublisherTest extends TestCase {
  Mockery context = new Mockery();

  public void testOneSubscriberReceivesAMessage() {
    final Subscriber subscriber =
      context.mock(Subscriber.class);
    Publisher publisher = new Publisher();
    publisher.add(subscriber);

    final String message = "message";

    context.checking(new Expectations() {{
        oneOf (subscriber).receive(message);
    }});

    publisher.publish(message);

    context.assertIsSatisfied();
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Mockito

```java
public class PublisherTest extends TestCase {
  public void testOneSubscriberReceivesAMessage() {
    final Subscriber subscriber = mock(Subscriber.class);
    Publisher publisher = new Publisher();
    publisher.add(subscriber);

    final String message = "message";
    publisher.publish(message);

    verify(subscriber, times(1)).receive(message);
  }
}
```

</script></section><section data-markdown><script type="text/template">
### PowerMockito

```java
@RunWith(PowerMockRunner.class)
@PrepareForTest(Subscriber.class)
public class YourTestCase {
  @Test
  public void testMethodThatCallsPrivateMethod() {
    final Subscriber subscriber = mock(Subscriber.class);
    Publisher publisher = new Publisher();
    publisher.add(subscriber);

    final String message = "message";
    publisher.publish(message);

    verifyPrivate(subscriber, times(1))
      .invoke("privateMethodName", message);
  }
}
```

</script></section><section data-markdown><script type="text/template">
### Mock

```java
MyClass test = mock(MyClass.class);
when(test.getUniqueId()).thenReturn(43);
assertEquals(43, test.getUniqueId());
```

### Spy

```java
MyClass test = spy(new MyClass());
doReturn(43).when(test).getUniqueId();
assertEquals(43, test.getUniqueId());
```

</script></section><section data-markdown><script type="text/template">
### zum  Nachdenken

```java
MyClass test = mock(MyClass.class);
assertEquals(??, test.getUniqueId()); // Was kommt hier raus?

MyClass toBeSpiedOn = new MyClass();
MyClass spying = spy(toBeSpiedOn);

when(spying.getUniqueId()).thenReturn(43);

doReturn(43).when(spying).getUniqueId();
assertEquals(??, toBeSpiedOn.getUniqueId());
```

</script></section><section data-markdown><script type="text/template">
<small>
```java
public int makeDebtListKeyFigureColumn(String customerOid, Calendar bookKeepingDate)
{
  dbConversationHandler.ensureValidTransaction();
  int count = 0;

  try
  {
    // Calendar für spätere verwendung hg: truncate wurde schon gemacht
    final Calendar normalizedBookKeepingDate =
            Utils.truncateDate(bookKeepingDate, Calendar.DAY_OF_MONTH);

    // Vormonatsultimo holen
    Calendar pmu = Utils.truncateDate(Utils.getPmu(), Calendar.DAY_OF_MONTH);

    // beide auf 12:00 setzen, weil sonst vorhandene DebtListKeyFigureColumns nicht
    // gefunden werden, da Referenzdatum beim Erzeugen auf 12:00 gesetzt wird, und
    // die nochmal erzeugt werden. (Bug 11951)
    normalizedBookKeepingDate.set(Calendar.HOUR, 12);
    pmu.set(Calendar.HOUR, 12);

    // Kennzahlen nur erzeugen, wenn Buchungsdatum größer gleich
    // dem Vormonatsultimo ist (Bug 9111)
    if (normalizedBookKeepingDate.compareTo(pmu) >= 0)
    {
      // Monat und jahr für späteren vergleich merken
      int pmuMonth = pmu.get(Calendar.MONTH);
      int pmuYear = pmu.get(Calendar.YEAR);

      // Die Kennzahlenspalte sollte anhand des vormonatssultimos holen
      final IGenericDAO<DebtListKeyFigureColumn> debtListKeyFigureColumnDAO =
              this.daoFactory.getGenericDAOFor(DebtListKeyFigureColumn.class);
      DebtListKeyFigureColumn keyFigureColumn =
              debtListKeyFigureColumnDAO.findByAttributes(new String[] {
                      DebtListKeyFigureColumn.ATTR_CUSTOMERID,
                      DebtListKeyFigureColumn.ATTR_REFERENCE_DATE}, new Object[] {
                      customerOid, pmu.getTime()});

      // prüfen, ob wir für den vormonat schon eine spalte haben
      if (keyFigureColumn != null)
      {
        Calendar pmuColumnReferenceDate = Calendar.getInstance();
        pmuColumnReferenceDate.setTime(keyFigureColumn.getReferenceDate());

        int pmuColumnReferenceMonth = normalizedBookKeepingDate.get(Calendar.MONTH);
        int pmuColumnReferenceYear = normalizedBookKeepingDate.get(Calendar.YEAR);

        // Monat und jahr prüfen
        if ((pmuColumnReferenceMonth == pmuMonth)
                && (pmuColumnReferenceYear == pmuYear))
        {
            // die spalte ist bereits aus dem monat, für den wir eine neue
            // erzeugen wollten -> wir können daher abbrechen
            logger.debug("Key figures for customer " + customerOid + " are up to date");
            return count;
        }
      }

      // keine spalte für den vormonat gefunden; versuchen den kunden zu laden
      SingleCustomer singleCustomer = null;
      try
      {
        final IGenericDAO<SingleCustomer> singleCustomerDAO =
                this.daoFactory.getGenericDAOFor(SingleCustomer.class);
        singleCustomer = singleCustomerDAO.findById(customerOid);
      }
      catch (ObjectNotFoundException e)
      {
        logger.debug("Customer with ID " + customerOid + " not found");
        return count;
      }

      // ... und kennzahlenspalten erzeugen
      if (singleCustomer != null)
      {
        logger.debug("Calculating debt list key figures for customer "
                + singleCustomer.getNumber());

        // versuchen die masterbilanz des kunden zu holen
        BalanceDataRow mbRow = null;
        try
        {
            mbRow = this.getMasterBalanceRow(singleCustomer);
        }
        catch (StandardException e)
        {
            // Exception ignorieren; kunde hat keine masterbilanz oder die
            // ID stimmt nicht.
        }

        // Letztes importiertes Bb3ProductUsageData-objekt des kunden holen
        final IGenericDAO<Bb3ProductUsageData> bb3ProductUsageDataDAO = this.daoFactory
                .getGenericDAOFor(Bb3ProductUsageData.class);
        Bb3ProductUsageData pud = bb3ProductUsageDataDAO.findByAttribute(
                Bb3ProductUsageData.ATTR_CUSTOMERID, singleCustomer.getOid());

        // alle vorhandenen kennzahlenspalten des kunden holen
        Collection<DebtListKeyFigureColumn> cols =
                debtListKeyFigureColumnDAO
                .findAllByAttribute(DebtListKeyFigureColumn.ATTR_CUSTOMERID,
                        singleCustomer.getOid());

        // Sonderbehandlung: falls zur neu erzeugten spalte *keine* fünf
        // vormonate
        // existieren, müssen wir diese spalten zuerst erzeugen
        if (cols.size() < 6)
        {
          // DebtListKeyFigureColumn.PREV_MONTH_M2 -> -2
          // DebtListKeyFigureColumn.PREV_MONTH_M6 -> -6
          for (int prevMonthIdx = -6; prevMonthIdx < -1; prevMonthIdx++)
          {
              // Kennzahlenspalte für (vor)vormonate erzeugen
              keyFigureColumn =
                      new DebtListKeyFigureColumn(singleCustomer, mbRow, pud, cols,
                              prevMonthIdx);
              // ...und persistent machen
              debtListKeyFigureColumnDAO.persist(keyFigureColumn);
              cols.add(keyFigureColumn);
              count++;
          }
        }

        // Kennzahlenspalte für den vormonat (ausgehend vom heutigen datum)
        // erzeugen
        keyFigureColumn = new DebtListKeyFigureColumn(singleCustomer, mbRow, pud, cols);

        // ...und persistent machen
        debtListKeyFigureColumnDAO.persist(keyFigureColumn);
        count++;
      }
    }
  }
  catch (Exception e)
  {
      StandardErrorHandler
              .getInstance()
              .handleException(new PersistenceException("Error while trying to make a "
                                       + "DebtListKeyFigureColumn.", e,
                                       "2001_GenericDataManagerError", new String[] {}), true);
  }
  // Anzahl der erzeugten spalten zurückliefern
  return count;
}
```
<!-- .element: max-width: none; -->
</small>

</script></section><section data-markdown><script type="text/template">
### Wie Tests für bestehenden Code entwickeln?

1. Isoliere den zu testenden Teil durch Method-Extraction
2. Setze den zu testenden Teil auf package-private
3. Teste die extrahierte Methode
4. Refactore den nun getesteten Code in eine neue Klasse

</script></section><section data-markdown><script type="text/template">
### 4. Übung

</script></section></section><section ><section data-markdown><script type="text/template">
## Test-Driven-Development (TDD)

</script></section><section data-markdown><script type="text/template">
### Ziel

* klassische Entwicklung eines Systems erreicht nur unzureichende Testabdeckung:
  * Tests werden parallel zum System entwickelt
  * es besteht Zeit-/Kostendruck
  * Testerstellung wird als erstes gestrichen
* TDD durchbricht den Zyklus durch die Bedingung: schreibe erst den Test, dann den Produktivcode

</script></section><section data-markdown><script type="text/template">
### Vorgehensweise

*  parallele Entwicklung Test- und Produktivcode
* in Mikroiterationen: Red-Green-Refactor
  * Red: Definiere einen Test für das neue Verhalten. Dieser Test muss zwangsweise fehlschlagen.
  * Green: Ändere den Produktivcode minimal, sodass der Test durchläuft.
  * Refactor: Entferne Duplikationen, abstrahiere wo nötig, richte ihn nach den verbindlichen Code-Konventionen. Es darf kein neues Verhalten eingeführt werden.
* eine Iteration in der Regel wenige Minuten

</script></section><section data-markdown><script type="text/template">
### Vorgehensweise
![](https://fmansoblog.files.wordpress.com/2016/02/tdd-circle-of-life.png)

</script></section><section data-markdown><script type="text/template">
### Zusatzaufwand

* Hauptaufwand während Sw-Entwicklung liegt bei der Erarbeitung einzelner zu erfüllender Punkte bzw. Fälle (nicht im Tippen vom Code)
* an diesem Punkt, vor der Programmierung, ist der Aufwand zur Erstellung von UnitTests sehr gering
* zusätzlich tendiert Code zur:
  * besseren gedanklichen Strukturierung
  * stärkeren Modularisierung
  * Fokussierung auf Kundennutzenstiftende Funktionalität (YAGNI)
  * höheren Test-Abdeckung

</script></section><section data-markdown><script type="text/template">
### Zusatzaufwand
* je langlebiger das System, desto höher die Ersparnis durch geringeren Wartungsaufwand, da:
  * einzelne Anforderungen nicht aus Code heraus analysiert werden müssen
  * vergleichbare Testabdeckung wie bei TDD nur mit hohem Aufwand möglich

</script></section><section data-markdown><script type="text/template">
### Nachteile

* TDD benötigt:
  * Training
  * Disziplin

</script></section><section data-markdown><script type="text/template">
### 5. Übung - String-Rechner

<small>

1. Ein leerer String liefert 0
2. Eine einzelne Ziffer liefert den eigenen Wert
3. Zwei Ziffern kommasepariert liefern die Summe
4. Zwei Ziffern durch newline getrennt liefern die Summe
5. Drei Ziffern, durch Komma oder newline getrennt, liefern die Summe
6. Negative Ziffern werfen eine Exception
7. Ziffern größer als 1000 werden ignoriert
8. Auf der ersten Zeile kann ein einzelnes Zeichen als 'delimiter' in der Form '//#' für bspw. '#' angegeben werden
9. Auf der ersten Zeile kann eine Zeichenfolge als delimter in eckigen Klammern angegeben werden ('//[###]' bspw. für '###')
10. Auf der ersten Zeile können beliebig viele Zeichen bzw. Zeichenfolgen als delimiter angegeben werden (jedes in eckigen Klammern angegeben)

</small>

</script></section></section></div>
        </div>

        <script src="./lib/js/head.min.js"></script>
        <script src="./js/reveal.js"></script>

        <script>
            function extend() {
              var target = {};
              for (var i = 0; i < arguments.length; i++) {
                var source = arguments[i];
                for (var key in source) {
                  if (source.hasOwnProperty(key)) {
                    target[key] = source[key];
                  }
                }
              }
              return target;
            }

            // Optional libraries used to extend on reveal.js
            var deps = [
              { src: './lib/js/classList.js', condition: function() { return !document.body.classList; } },
              { src: './plugin/markdown/marked.js', condition: function() { return !!document.querySelector('[data-markdown]'); } },
              { src: './plugin/markdown/markdown.js', condition: function() { return !!document.querySelector('[data-markdown]'); } },
              { src: './plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },
              { src: './plugin/zoom-js/zoom.js', async: true },
              { src: './plugin/notes/notes.js', async: true },
              { src: './plugin/math/math.js', async: true }
            ];

            // default options to init reveal.js
            var defaultOptions = {
              controls: true,
              progress: true,
              history: true,
              center: true,
              transition: 'default', // none/fade/slide/convex/concave/zoom
              dependencies: deps
            };

            // options from URL query string
            var queryOptions = Reveal.getQueryHash() || {};

            var options = {"controls":false,"slideNumber":false,"transition":"slide","backgroundTransition":"fade"};
            options = extend(defaultOptions, options, queryOptions);
        </script>


        <script>
          Reveal.initialize(options);
        </script>
    </body>
</html>