CocoaHeads Aachen Februar 2015: TDD in Swift

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • CocoaHeads Aachen Februar 2015: TDD in Swift

      Liebe CocoaHeads,

      diesen Donnerstag (26.2.2015) ist das nächste Treffen, für das Alex einen interessanten Talk mit dem Titel "Test-driven development – Why and how to do it in Swift" vorbereitet hat. Kommt und seid gespannt!

      Beginn ist um 19 Uhr in Raum 2222 des RWTH-Informatikzentrums an der Ahornstr. 55 (2. Etage), 52074 Aachen. Infos auch unter cocoaheads.de

      Schöne Grüße
      Michael
    • Och, wie sich TDD in Swift umsetzen lässt finde ich schon spannend.
      Vor Allem im Hinblick auf Mocking. Wenn ich beispielsweise etwas testen möchte, das eine bestehende Serververbindung mit vordefiniertem Aufbau voraussetzt, aber nicht auf jeder Maschine einen Webserver aufsetzen möchte, was kann ich dann tun?

      Für Objective-C habe ich OHHTTPStubs im Einsatz.
      Aber was nimmt man unter Swift?

      (Zum Glück heißt das ja CocoaHeads, nicht Objective-CHeads +g+)
      «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

      Iä-86! Iä-64! Awavauatsh fthagn!

      kmr schrieb:

      Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
    • Da OHHTTPStubs "einfach nur" NSURLProtocol implementiert, sollte das auch mit Swift funktionieren (habs aber noch nicht getestet).

      Schwieriger wird es mit Class-Mocks und -Stubs, wie OSMock oder OCMockito. Diese funktionieren nur für NSObject-Subklassen und da auch nicht immer. Mocking und Stubbing wird in Swift von Hand gemacht. Oft mit Klassen, die innerhalb der Testmethode geschrieben werden.

      Ein Framework, dass das mit Swift kann, ist mir nicht bekannt. Wenn jemand was weiss, ich bin sehr interessiert!
    • dasdom schrieb:

      a OHHTTPStubs "einfach nur" NSURLProtocol implementiert, sollte das auch mit Swift funktionieren (habs aber noch nicht getestet).


      Es fügt auch eine Kategorie zu NSURLSessionConfiguration hinzu, die durch ein wenig Methoden-Swizzling dafür sorgt, dass die Kommunikation der Tasks einer NSURLSession über OHHTTPStubs läuft.
      Das wiederum stelle ich mir für Swift einfach nicht umsetzbar vor.
      «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

      Iä-86! Iä-64! Awavauatsh fthagn!

      kmr schrieb:

      Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
    • Marco Feltmann schrieb:

      Deshalb schrieb ich ja: ich nehme OHHTTPStubs für Objective-C und hätte für Swift gern eine Alternative. ;)


      Ich habe das Gefühl, wir reden aneinander vorbei. Was ich meine ist:

      Für den Fall, dass du NSURLSessionConfiguration nicht selbst in Swift nachbaust, solltest du OHHTTPStubs für Stubs deines Swift-Networking-Codes nutzen können. Die Objective-C-Runtime ist ja immer noch da. und NSURLSessionConfiguration ist ja immer noch in Objective-C implementiert. Somit sollte Methoden-Swizzling von Apple-Klassen immer noch funktionieren, da alle Apple-Klassen in Objective-C implementiert sind.

      Und genau das will ich am Wochenende mal testen. Eigener Code nur in Swift. Apple-Code natürlich nur in Objective-C.
    • Ist sicher eine Geschmacksfrage, aber mittlerweile benutze ich kaum noch Mockingframeworks, sondern schreibe mir entsprechende Funktionalität selber. Ist schnell gemacht und einfach wiederzuverwenden. Das spart den ganzen setupcode für die Mocks. Tests sind m.M.n. zu wichtig, um sich von einer 3rd-Party (Mockingframework) abhängig zu machen. Außerdem mocke ich keinen Code, den ich nicht selbst kontrolliere, also keine Foundation/UIKit/AppKit Klassen.

      Mit Swift funktioniert das alles genau so wie mit Objective-C.
    • Markus Müller schrieb:

      Ist sicher eine Geschmacksfrage, aber mittlerweile benutze ich kaum noch Mockingframeworks, sondern schreibe mir entsprechende Funktionalität selber. Ist schnell gemacht und einfach wiederzuverwenden. Das spart den ganzen setupcode für die Mocks. Tests sind m.M.n. zu wichtig, um sich von einer 3rd-Party (Mockingframework) abhängig zu machen. Außerdem mocke ich keinen Code, den ich nicht selbst kontrolliere, also keine Foundation/UIKit/AppKit Klassen.

      Mit Swift funktioniert das alles genau so wie mit Objective-C.


      Aber was ist in dem obigen Beispiel: NSURLSession, die ein JSON erwartet, welches in einem Block (oder eben Closure) verarbeitet wird. Wie mockst du das von Hand? Wie kontrollierst du das was vom Webservice käme. Oder testest du auf dieser Ebene nicht? Oder benutzt du die Block-Methoden von NSURLSession nicht?
    • Ich würde die Komponente, welche das JSON verarbeitet ausgiebig testen, also mit den zu erwartenden Eingaben (inkl. leerem oder kaputten JSON). Das ist ja erstmal unabhängig wie das JSON ankommt. Ob das mit NSURLSession oder wie auch immer reinkommt, ist ein Implementationsdetail. Den eigentlichen NSURLSession-Teil würde ich in einem Integrationstest testen, also nicht mit einem Mock, sondern mit einem kleinen, isolierten Testserver als Teil des Integrationstests. Dort würde ich dann testen, dass das Modul quasi richtig verkabelt ist (also ob url-requests ankommen etc.).
    • Diesen Testserver musst Du dann ja ewig mit Dir rumschleppen, von überall verfügbar haben, der darf seine Adresse nie ändern etc.pp.
      Und falls er doch mal weg kommt und wieder her muss fummelst Du Dir was zurecht ihn wieder genau so zu konfigurieren.

      Wenn der Komponente, die das JSON verarbeitet, eine Art Dispatcher vorgeschaltet ist, der wahlweise von einer lokalen oder einer entfernten Quelle Daten liefert und auch je nach Route unterschiedliche Status zurück liefert, hilft Dir der Integrationstest eigentlich auch nicht weiter. Die korrekte Handhabung wäre ja, dass die Integration mit irgendwas unerheblich ist.
      Anfrage stellen, mit einem definitiven Resultat rechnen, dagegen prüfen. Da finde ich so einen 'gemockten' Server um Längen zuverlässiger (und auch leichter zu kontrollieren) als irgend einen richtigen Webserver.
      «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

      Iä-86! Iä-64! Awavauatsh fthagn!

      kmr schrieb:

      Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P