~~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
#import
@interface MyClassTC : SenTestCase {}
@end
#import "MyClass.h"
@implementation MyClassTC
-(void)setUp {
}
-(void)tearDown {
}
-(void)testMethodXY {
...
STAssertEqualObjects(@"expected", ..., @"fail");
}
@end
== 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:
-(void)testRFC1123 {
NSString *s = @"Fri, 14 Aug 2009 14:45:31 GMT";
STAssertEqualObjects(s, [[NSDate dateFromRFC1123:s]
rfc1123String], @"fail");
}
== 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}}