Test / Behavior Driven Development

Testautomatisierung für Code, Benutzeroberfläche, Integration und mehr

Richtig eingesetzt, erzwingen Tests guten und verifizierbaren Code zu schreiben. Guter Code ist die Grundlage sauberer Architektur – gleich von Anfang an. Das Risiko, durch Veränderungen am Code Fehler zu verursachen, wird fortlaufend und schnell reduziert, z. B. durch automatisierte Oberflächentests. Der Einsatz von Behavior-Driven Design (BDD) macht Tests aussagekräftiger und spezifischer für die fachliche Domäne. Fachabteilungen können Tests bzw. Spezifikationen interpretieren ohne eine Programmiersprache verstehen zu müssen.

Ein praktisches BDD-Tool ist das Framework Machine.Specifications (MSpec) für .NET. MSpec ist Open Source, per NuGet verfügbar und in ReSharper integrierbar. Cucumber ist ein plattformübergreifendes Open-Source-Tool das „Gherkin“ als domänenspezifische Sprache für Spezifikationen einsetzt und mit allen gängigen Programmiersprachen integrierbar ist. Außerdem erlauben viele Testing-Frameworks, wie z. B. Jest und RSpec, Unit-Tests im BDD-Style zu schreiben.

Einführung ins Testen / Unit Testing

Typen von Softwaretests
- Unit Tests
- Akzeptanztests
- UI-Tests
- Integrationstests
- Datenbanktests
- Performancetests
Die Testpyramide nach Martin Fowler
Vorgehensweisen
- Blackbox-Testing
- Whitebox-Testing
Tests als Investition in die Zukunft einer Software
Tests als Verifikation der Spezifikation
Verbesserung der Kommunikation mit der Fachabteilung

Vom Test zum Produktivcode

Was ist ein Unit Test und wie verhält sich dieser im Test Driven Development
Unterschiede zwischen Test-First und testgetriebener Softwareentwicklung
Tests als Treiber für gutes Softwaredesign
Outside-In und Inside-Out als zwei Ansätze, Funktionalität zu entwickeln
Muss man alles testgetrieben entwickeln
XP-Techniken wie Pair Programming und deren Einsatz bei testgetriebener Softwareentwicklung
Mocks und andere Arten von Test Doubles
Testen zeitkritischer Funktionalität
Wann sind Abstraktionen für Dateisystemzugriff oder externe Ressourcen sinnvoll
Wie das Testen die „Definition of Done“ in der agilen Softwareentwicklung beeinflusst
Metriken und deren Kosten / Nutzen: Code Coverage, Coupling, Dependency Matrix
Was testet man und wie intensiv sollte getestet werden
Tests als Qualitätssicherungsmaßnahme

Brownfield-Softwareentwicklung und „minimalinvasives“ Testen

Wie bekommt man bestehenden Code „under test“
Aufbrechen von Komponenten
Testbasierte Unterstützung von Refactoring
Patterns für das Refactoring und Modularisierung von Tests
Umgang mit Testdaten
- Object Mother, Builder Pattern
- Named Test Data Sets (Personas)
Bezugnahme auf User Stories und die Erstellung von Spezifikationen und Szenarios
Langfristiger Nutzen von Tests für Qualität und Architektur

Behavior Driven Development (BDD)

Ist BDD nur „Test Driven Development (TDD) done right“
Abgrenzung zu Domain Driven Design
Vorteile von BDD in Bezug auf die Kommunikation im Team und zwischen Team und Stakeholdern
Die Stile Context / Specification und Given-When-Then
Frameworks für BDD

Oberflächentests und Weiteres

Test-Frameworks für Java, JavaScript und Ruby
Frameworks für das Testen von Oberflächen im Web und auf dem Client
Tests mit und in PowerShell

Nach oben

Schulung, Training, Seminar, Kurs auf einen Blick

Name: Test / Behavior Driven Development

Kurz-URL: grossweber.com/tests

Die empfohlene Dauer der Schulung ist 3 Tage.

Schulung, Training, Seminar, Kurs. Dahinter steckt ein kluger Kopf.

Alexander Groß

Ich will, dass Entwickler auf ihre Software stolz sein können.

Kurzbiographie: grossweber.com/kk/#alexander-gross

Kunden zur Schulung bzw. Training

It was a very interesting course that refreshed some things, challenged others and brought out new ideas. Really great!
Maxence Vetter, Teamleiter, adesso Schweiz

It was really cool to see Alex and Sergey working together as a team.
Bettina Wolko, Senior Software Engineer, adesso Schweiz

Wenn man glaubt, vieles zu Unit Tests zu wissen und plötzlich ‚BDD‘ sieht, fragt man sich, warum man eigentlich bisher Tests so kompliziert geschrieben hat.
Alexander Tank, Softwareentwickler, SoftwareONE AG, Softwarelösungen wie CMS und Portale, u. a. für Deutsche Post DHL (Interview), Interview: youtu.be/FNWwLW2KcPo

Beispiel eines BDD-Unit Tests

Mit MSpec sind Tests für die Fachabteilung und den Softwareentwickler prägnant.

public class When_transferring_
             between_from_account_
             and_to_account
{
  static Account fromAccount,
                 toAccount;

  Because of =
    () => fromAccount
          .Transfer(1m, toAccount);

  It should_debit_the_from_account_
     by_the_amount_transferred =
       () => fromAccount.Balance
             .ShouldEqual(0m);
}

Eine vergleichbare Spezifikation kann in Cucumbers „Gherkin“-Sprache so aussehen.

Feature: Transfer

Scenario: Transfer between two accounts
  When transferring amount 1 between From account and To account
  Then it should debit the From account by amount 1

Und mit dem JavaScript-Framework Jest kann man das Gleiche im BDD-Style so abbilden.

describe("Transfer between two accounts", () => {
  let fromAccount, toAccount;
  // ...
  fromAccount.transfer(1, toAccount);

  it("should debit the from account by the amount transferred", () => {
    expect(fromAccount.balance).toEqual(0);
  });
});

Machine.Specifications

Das Framework Machine.Specifications ist Open Source und wurde von GROSSWEBER-Mitbegründer Alexander Groß betreut. Er realisierte die Integration in ReSharper und führte die Entwicklung der Bibliothek fort.