#5 Unit-Testing mit Sven Günther

7 Antworten

Sven Günther und ich sprechen über Unit-Testing, ein lange ignoriertes Thema unter iOS, das nicht zuletzt durch die Verbesserungen mit Xcode 5 mehr Beachtung finden sollte. Nach einer theoretischen Einführung zu Dingen wie Test-Driven-Development, "Fake it till you make it" oder Triangulation sprechen wir über praktische Erfahrungen, Schwierigkeiten beim Testen und eine ganze Reihe von Tipps und nützlichen Tools.

Alternativ zum Download könnt Ihr UISprech bei iTunes oder mit einem anderen Podcast-Client abonieren.

Shownotes

Hier die Links und Anmerkungen zu dieser Episode:

Logo_MDC_2013-kompakt

Diese Episode wird gesponsort von der Mobile Developer Conference kompakt. Vielen Dank!
Wenn Ihr bei der Anmeldung den Rabatt-Code MDC13HUIS verwendet, bekommt Ihr auf das Kombi-Paket “Konferenz plus Workshop” mehr als 50% Ermäßigung.

Sven Günther

Was ist Unit-Testing?

Wie sieht das in der Praxis aus?

Was sind Mocks?

Wie teste ich bestehende Apps?

Welche Aspekte testest Du?

Wo nervt Unit-Testing?

Welches Tools gibt es?

Wo gibt es weitere Infos?

Kontaktdaten von Sven Günther

Diese und alle anderen Folgen von UISprech sind veröffentlicht unter der CC BY-SA 3.0 Lizenz.

7 Gedanken zu „#5 Unit-Testing mit Sven Günther“

  1. Timo John

    Hallo Heiko,
    ein gutes neues Projekt hast Du hier aufgesetzt!
    Mir als SAP Entwickler bleibt zwar sämtlicher Nutzer der genannten Tools verborgen, aber die Methodiken und Ziele höre ich mir sehr gerne an, auch wenn ich das Gefühl habe das wir mit ABAP in SAP noch gute 10 – 20 Jahre hinterher hängen. Es gibt zwar auch hier Unit Test, aber Nutzungsgrad ist so minimal… und Das Wort “MOCK” habe ich in SAP Projekte auch nur in Verbindung mit Kaffee gehört.

    Um 1:00:00 sprecht ihr über OCHamcrest und Assertions. Für mich wäre eine Folge interessant, die sich mit dem Thema Returncodes vs. Exceptions vs. Assertions, wann setzte ich was sinnvoll ein. Was ist wirklich ein “Fehler” und wann gebe ich einfach eine Antwort oder auch mal “null” zurück.
    Zu diesem Thema habe ich im Netzt nicht viel gutes Material gefunden. Vermutlich ist das für erfahrene Entwickler mit aktuellen Sprachen uns Tools ein alter Hut, aber ich fände es interessant.

    ↓
    1. Heiko Behrens Artikelautor

      Danke für das Lob, Timo.

      Ich verstehe Deinen Hinweis auf OCHacmcrest und die Alternative zwischen hybriden Rückgabewerten und Exceptions nicht ganz. Bei letzterem aber variieren die Idiome stark zwischen den jeweiligen Programmiersprachen und sogar Frameworks. So war es in Java bswp. eine Zeit lang sehr beliebt, den Kontrollfluss mit Exceptions abzubilden, während unter Objective-C typischerweise nur dann Exceptions geworfen werden, wenn alles zu spät ist und der Ablauf komplett beendet werden sollte. Dort verwendet man mit NSError einen Out-Parameter (Pointer auf Pointer) an stellen, bei denen Fehler erwartet werden (z.B. IO).

      Zu den Fehlenden Tools in Deiner Umgebung: Auch bei anderen Sprachen kamen die Tools selten “vom Hersteller”, sondern sind (häufig in der Freizeit) von enthusiastischen Entwicklern als Open-Source-Software entwickelt worden. Eigentlich sind so ziemlich alle brauchbaren Testing-Tools, über die Sven und ich sprechen, so entstanden. Selbst Apples nunmer “eigenes” Testing-Framework XCTest basiert auf einem Open-Source-Framework, das so entstanden ist.

      ↓
  2. Dennis Bilousov

    Hallo Heiko,

    ich habe mir diese und für mich auch die erste Deiner Folgen mit großem Interesse angehört und verfolgt. Vielen Dank für das informative und qualitative Interview!

    Dennoch sind bei mir Fragen entstanden:

    Kapitel 00:43:30 Wo stört Unit-Testing?
    Zeit: 45:41 Hier hatte ich das Gefühl, dass Unit Tests und Integrationstests Konzepte miteinander vermischt und ein wenig einander vorbeigesprochen wurde. Denn Sven hat davon gesprochen, dass er praktisch von zwei Seiten den Code testet. Mit Datenbeschaffer-Mocks testet er die Parser von Response Methoden und alles was dahinter hängt. Damit schaft er die Abstraktion von externen Schnittstellen und vertraut auf Mocks. Das sind die Unittests. Von anderer Seite sichert er sich mit Integrationstests zusätzlich ab, da die Mocks nicht die reale Welt abbilden. Bei Integrationstests setzt Sven das OCMockito ein. Allerdings scheint es für mich kein alternatives Werkzeug zu Nocilla zu sein. Du Heiko, so wie ich verstanden habe, setzt die Integrationstests mit Nocilla ein, ohne den Datenbeschaffer zu mocken. Damit entfällt bei Dir der Unittest. Mit keinem dieser Werzeuge bin ich vertraut, lediglich ein paar Beispiele in GitHub mir angeschaut. Könntest Du bitte kurz Erklären wie das genau im Gespräch gemeint war?

    Kapitel: 1:07:47 Wie verkauft man das dem Kunden?
    Ich finde die in dem Kapitel gestellte Frage wurde nicht beantwortet, was mich enttäuscht hat. Gewiss gibt es hier kein Patentrezept und es hängt auch von der Kommunikationspolitik mit dem Kunden ab. Dennoch war meine Erwartung, dass zumindest ein paar Ratschläge an die Hand gegeben werden aus der Praxis, was funktionieren könnte, weil man es selbst schon probiert hat.

    Viele Grüße,
    Dennis

    ↓
    1. Sven

      Hallo Dennis,

      schön dass dir die Folge gefallen hat.

      Wo stört Unit-Testing?
      In Integrationstests nutze ich kein OCMockito. Dies nutze ich nur, um in Unit-Tests Abhängigkeiten zu anderen Objekten abzuschneiden. Integrationstests sollten immer ohne Mocks laufen. Da Integrationstests aber sehr teuer sind, sprich, sehr lange laufen, beschränke ich sie auf ein Minimum. So kann ich mit wenigen Tests prüfen, ob die Schnittstellen korrekt funktionieren. Als eine Mischung zwischen Unit- und Integrations-Tests kann man Tests sehen, die zwar als Integrationstest laufen, aber zB Netzwerkverkehr trotzdem mocken. Dazu bieten sich Tools wie zB Nocilla oder Mocktail an. Damit kann man UI-Tests durchführen und trotzdem auf stabile Eingangsbedingungen setzen. Zudem hat man einen Geschwindigkeitsvorteil, da der langsame Netzwerktraffic ersetzt wird.

      Wie verkauft man das dem Kunden?
      Das hängt in der Tat immer vom jeweiligen Kunden ab. Als Argument kann man sicherlich die höhere Qualität der Anwendung ins Feld führen. Natürlich spielt hier eine Menge Vertrauen mit, welches der Kunde erst vorschießen muss, wenn man bislang noch nicht zusammen gearbeitet hat. Als Ratschlag kann ich hier nur mitgeben, dass Qualität nicht zur Diskussion stehen darf. Das sollte jeder Kunde unterstützen, der eine ernsthafte Anwendung entwickeln lassen will. Wenn man dann noch regelmäßig und häufig Inkremente liefert, die eine hohe Qualität aufweisen kann man sich das Vertrauen sehr schnell erarbeiten.

      Viele Grüße, Sven

      ↓
      1. Dennis Bilousov

        Hallo Sven,

        danke für die umfangreiche Antwort! Ich habe natürlich nicht OCMockito, sondern Mocktail bei der ersten Frage gemeint. Entschuldigung für die Verwirrung. Ok, nun ist für mich die Situation und Abgrenzung klar geworden. Ich probiere mal die beiden Tools Mocktail und Nocilla aus.

        Zu der zweiten Frage: Wie verkauft man das dem Kunden? Ich finde Deine Aussage im Interview stimmig, dass man das Testen und Mehraufwand in Angeboten nicht ausweisen darf, da es zu der Softwareentwicklung gehört. Die Antwort auf die Frage lautet also: Man kann gar nicht das Testen verkaufen, vor allem nicht den bestehenden Kunden. Wahrscheinlich wäre der richtige Weg zunächst den Mehraufwand selbst zu bezahlen, um nachhinein bessere Qualität zu liefern. Daraufhin aus der neuen Position könnte man den eingesteckten Mehraufwand durch eingesparte Zeit beim Bugsfixing wieder rausholen.

        Ich bin auf weitere Folgen mit Dir gespannt.

        Viele Grüße,
        Dennis

        ↓
        1. Sven Günther

          Das ist ein guter Anwendungsfall für Stubs. Du definierst damit für dein Objekt, welches die Rohdaten liefert (zB Netzwerk-Response oder auch FileHandle) ein für den Test fest definierten Ausgangszustand. Dann kannst du für den Code, der die Nutzdaten aus den Rohdaten erzeugt, Tests schreiben, die definierte Ausgangsdaten erwarten.

          ↓