🐳

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
~~SLIDESHOW~~

-----

Diese Wiki Seite sieht etwas verhagelt aus, da sie in erster Linie im Präsentationsmodus funktionieren muß.

Browser im Kiosk Modus:
 * Safari: keine Ahnung 
 * Firefox recht gut per Plugin: https://addons.mozilla.org/de/firefox/addon/1568
 * Opera von Haus aus


= Unit Testing Cocoa

Vortrag am 17. März 2010

//The main thing that distinguishes legacy code from non-legacy code is tests, or rather a lack of tests. [[https://web.archive.org/web/20100819042330/http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf|Michael Feathers]]//

-----

{{ :cocoaheads:octest-new-target.png|}}

ungeordnete Stichpunkte
 * Michael Feathers http://www.objectmentor.com/omTeam/feathers_m.html
 * Martin Fowler 
    * CI http://www.martinfowler.com/articles/continuousIntegration.html
    * OT: VCS http://martinfowler.com/bliki/VersionControlTools.html
 * Michael T. Nygard http://www.pragprog.com/titles/mnee/release-it
 * SQLite Testing http://www.sqlite.org/testing.html

== Was ist ein Unit Test?

 * Testprogramm für einzelne Programmbausteine (Klassen, einzelne Methoden),
 * zustandslos, bereitet die Vorbedingungen selbst vor,
 * automatisierbar, prüft alle Nachbedingungen, Schritt im Build Prozeß,
 * normalerweise in der gleichen Sprache geschrieben wie der zu testende Code,
 * nicht Teil des ausgelieferten Programms.

== Quelltext Impression

<code objc>
#import <SenTestingKit/SenTestingKit.h>
@interface MyClassTC : SenTestCase {}
@end

#import "MyClass.h"
@implementation MyClassTC
-(void)setUp {
}

-(void)tearDown {
}

-(void)testMethodXY {
  ...
  STAssertEqualObjects(@"expected", ..., @"fail");
}
@end
</code>

== Was nützen mir Unit Tests?

 * Klarheit der Abhängigkeiten in meinem Code (Stichwort [[http://www.martinfowler.com/articles/injection.html|Dependency Injection & Inversion of Control]]),
 * Refactoring ohne Nervenkitzel,
 * eindeutig definiertes Verhalten ([[http://de.wikipedia.org/wiki/Design_by_contract|Design by Contract]]), Förderung der Teamarbeit,
 * keine "vergessenen" Tests, da jeder Build alle prüft, Bedingung für Continuous Integration.

== Wie geht's prinzipiell?

 * Test Framework zur bequemen Entwicklung, Ausführung und für Berichte,
 * normalerweise pro Logikbaustein (Klasse) eine Testklasse,
 * pro Bug / gewünschtem Verhalten eine Testmethode:

<code objc>
-(void)testRFC1123 {
  NSString *s = @"Fri, 14 Aug 2009 14:45:31 GMT";
  STAssertEqualObjects(s, [[NSDate dateFromRFC1123:s]
    rfc1123String], @"fail");
}
</code>

== Wie geht's mit Cocoa

{{ :cocoaheads:ocunit-target.png|}}

 * [[http://www.sente.ch/software/ocunit/|SenTestingKit / OCUnit]] kommt [[http://developer.apple.com/tools/unittest.html|von Apple]] mit - gibt aber [[http://blog.carbonfive.com/2009/02/testing/iphone-unit-testing-toolkit|auch andere Implementierungen]] und Zusätze,
 * [[http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/UnitTesting/1-Articles/CreatingTests.html#//apple_ref/doc/uid/TP40002171|neues XCode Target]]: "Cocoa > Unit Test Bundle"
 * direkte Abhängigkeit vom bisherigen Target, fertig.
{{ :cocoaheads:ocunit-fail.png?400 }}
 * ...und jetzt der schwierige Teil:

== Step & Trace

{{ :cocoaheads:custom-executable.png|}}
dazu brauchen wir ein "Custom Executable":
 * Pfad ''Developer/usr/bin/otest'' relativ zu "Current SDK"
 * einige [[http://wiki.mro.name/iphone/xcode_project_setup#unit_tests|Parameter und etliche Umgebungsvariablen]]
das können wir dann als ''Active Executable'' starten und debuggen. **Vorsicht:**
 * Parameter und Umgebungsvariablen gehen in die ''*.pbxuser'' Datei ein und gehen drum leicht verloren.
 * die Debugsitzung startet nur, wenn alle Tests erfolgreich sind (Build Abhängigkeit) - ich kommentiere die kritischen ''STAsserts'' zeitweise aus (Holzhammer)

---------
{{ http://images.apple.com/hk/en/macosx/developers/images/icon_xcode_20090824.png}}

== NSLog

 * Terminal: ''xcodebuild'' auf das Test Target loslassen und die NSLogs kommen auf die Konsole
 * XCode: ''Custom Executable'' als ''Active Executable'' und schon sehen wir die NSLogs auch.
{{ :cocoaheads:nslog.png }}

== Exkurs: Entwicklungsprozesse

 * [[http://de.wikipedia.org/wiki/Extreme_Programming#Praktiken|Extreme Programming (XP)]],
 * [[http://de.wikipedia.org/wiki/Testgetriebene_Entwicklung|Test Driven Development (TDD)]],
 * [[http://peomeint.blogspot.com/2006/08/beyond-tdd-documentation-driven.html|Documentation Driven Development (DDD)]],
 * [[http://en.wikipedia.org/wiki/Design_by_contract|Design by Contract (DbC)]].

--------------
 * [[http://redotheweb.com/2008/09/23/document-driven-development-in-practice-rethinking-sfforms/|DDD mit Link zu "presentation on Documentation-Driven Development" (Slideshare)]]

== Was ich vermisse

 * einfachere Projekteinrichtung,
 * benutzerbezogene Einstellungen abschaffen,
 * [[http://www.jcurl.org/m2/site/jc-core/0.7-SNAPSHOT/cobertura/|Testabdeckung]] messen und anzeigen. ([[http://code.google.com/p/coverstory/wiki/UsingCoverstory|CoverStory]]?)
{{ :cocoaheads:cobertura-report.png |Test Coverage}}

== Locker bleiben

//Don’t stress about unit tests. They are intended as a tool for ensuring good test coverage and memory management. Use them in that way to aid your development process. [[https://web.archive.org/web/20100223021458/http://developer.apple.com:80/mac/library/DOCUMENTATION/DeveloperTools/Conceptual/UnitTesting/1-Articles/UTGuidelines.html#//apple_ref/doc/uid/TP40002172|ADC]]//

 * Unit Tests verhindern natürlich [[http://cocoawithlove.com/2010/01/high-quality-in-software-development.html|nicht jeden Bug]],
 * Testing-Taliban schrecken moderate Seelen oft ab,
 * ein laufendes Programm ist wichtiger als 100% Testabdeckung,
 * die ersten Tests für Spaghetti Code können allerdings frustrieren.

== Querverweise / Lesetips

 * {{ http://ecx.images-amazon.com/images/I/51RCXGPXQ8L._SL500_AA240_.jpg?150}}[[http://www.informit.com/store/product.aspx?isbn=0131177052|Michael Feathers: Working Effectively with Legacy Code]]
 * [[http://www.tuaw.com/2010/03/10/iphone-devsugar-unit-testing-for-iphone-view-controllers/|Erica Sadun bei TUAW]]

XCode Anleitungen die ich schlußendlich verstanden habe:
 * [[http://cocoawithlove.com/2009/12/sample-iphone-application-with-complete.html|Cocoa with Love: A sample iPhone App with unit tests]]
 * [[http://cocoawithlove.com/2009/12/sample-mac-application-with-complete.html|Cocoa with Love: A sample Mac Application with unit tests]]
 * [[http://wiki.mro.name/iphone/xcode_project_setup#unit_tests|meine Zusammenfassung zur XCode Projekteinrichtung]]

== Vielen Dank

{{ http://www.cocoaheads.org/dev/cocoahead_sm2.png}}
für Eure Aufmerksamkeit.

Feedback willkommmen an [[post@mro.name?subject=Cocoaheads Vortrag: Testing|Marcus Rohrmoser]]

Die Folien zum Nachlesen gibt's hier:

{{ :cocoaheads:cocoacode.png?200}}
http://mro.name/go/cocoaheads_testing

------

aus Sicht eines iPhone Entwicklers.

ein Vortrag bei den [[http://www.cocoaheads.org/de/Munich/|CocoaHeads]] von 

{{tag> Vortrag CocoaHeads Unit Test Cocoa XCode}}
🐳

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Seiten-Werkzeuge
