Benutzer-Werkzeuge

Webseiten-Werkzeuge


cocoaheads:testing

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
cocoaheads:testing [2010/11/12 10:31] – [Vielen Dank] mrococoaheads:testing [2017/07/20 23:40] (aktuell) – [Unit Testing Cocoa] mro
Zeile 15: Zeile 15:
 Vortrag am 17. März 2010 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. [[http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf|Michael Feathers]]//+//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]]//
  
 ----- -----
Zeile 36: Zeile 36:
  * normalerweise in der gleichen Sprache geschrieben wie der zu testende Code,  * normalerweise in der gleichen Sprache geschrieben wie der zu testende Code,
  * nicht Teil des ausgelieferten Programms.  * nicht Teil des ausgelieferten Programms.
 +
 == Quelltext Impression == Quelltext Impression
 +
 <code objc> <code objc>
 #import <SenTestingKit/SenTestingKit.h> #import <SenTestingKit/SenTestingKit.h>
Zeile 63: Zeile 65:
  * eindeutig definiertes Verhalten ([[http://de.wikipedia.org/wiki/Design_by_contract|Design by Contract]]), Förderung der Teamarbeit,  * 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.  * keine "vergessenen" Tests, da jeder Build alle prüft, Bedingung für Continuous Integration.
 +
 == Wie geht's prinzipiell? == Wie geht's prinzipiell?
 +
  * Test Framework zur bequemen Entwicklung, Ausführung und für Berichte,  * Test Framework zur bequemen Entwicklung, Ausführung und für Berichte,
  * normalerweise pro Logikbaustein (Klasse) eine Testklasse,  * normalerweise pro Logikbaustein (Klasse) eine Testklasse,
Zeile 75: Zeile 79:
 } }
 </code> </code>
 +
 == Wie geht's mit Cocoa == Wie geht's mit Cocoa
 +
 {{ :cocoaheads:ocunit-target.png|}} {{ :cocoaheads:ocunit-target.png|}}
  
Zeile 83: Zeile 89:
 {{ :cocoaheads:ocunit-fail.png?400 }} {{ :cocoaheads:ocunit-fail.png?400 }}
  * ...und jetzt der schwierige Teil:  * ...und jetzt der schwierige Teil:
 +
 == Step & Trace == Step & Trace
  
Zeile 97: Zeile 104:
  
 == NSLog == NSLog
 +
  * Terminal: ''xcodebuild'' auf das Test Target loslassen und die NSLogs kommen auf die Konsole  * 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.  * XCode: ''Custom Executable'' als ''Active Executable'' und schon sehen wir die NSLogs auch.
Zeile 102: Zeile 110:
  
 == Exkurs: Entwicklungsprozesse == Exkurs: Entwicklungsprozesse
 +
  * [[http://de.wikipedia.org/wiki/Extreme_Programming#Praktiken|Extreme Programming (XP)]],  * [[http://de.wikipedia.org/wiki/Extreme_Programming#Praktiken|Extreme Programming (XP)]],
  * [[http://de.wikipedia.org/wiki/Testgetriebene_Entwicklung|Test Driven Development (TDD)]],  * [[http://de.wikipedia.org/wiki/Testgetriebene_Entwicklung|Test Driven Development (TDD)]],
Zeile 111: Zeile 120:
  
 == Was ich vermisse == Was ich vermisse
 +
  * einfachere Projekteinrichtung,  * einfachere Projekteinrichtung,
  * benutzerbezogene Einstellungen abschaffen,  * benutzerbezogene Einstellungen abschaffen,
Zeile 117: Zeile 127:
  
 == Locker bleiben == 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. [[http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/UnitTesting/1-Articles/UTGuidelines.html#//apple_ref/doc/uid/TP40002172|ADC]]// 
  
 +//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]],  * Unit Tests verhindern natürlich [[http://cocoawithlove.com/2010/01/high-quality-in-software-development.html|nicht jeden Bug]],
Zeile 124: Zeile 134:
  * ein laufendes Programm ist wichtiger als 100% Testabdeckung,  * ein laufendes Programm ist wichtiger als 100% Testabdeckung,
  * die ersten Tests für Spaghetti Code können allerdings frustrieren.  * die ersten Tests für Spaghetti Code können allerdings frustrieren.
 +
 == Querverweise / Lesetips == Querverweise / Lesetips
  
Zeile 151: Zeile 162:
  
 ein Vortrag bei den [[http://www.cocoaheads.org/de/Munich/|CocoaHeads]] von  ein Vortrag bei den [[http://www.cocoaheads.org/de/Munich/|CocoaHeads]] von 
- 
  
 {{tag> Vortrag CocoaHeads Unit Test Cocoa XCode}} {{tag> Vortrag CocoaHeads Unit Test Cocoa XCode}}
cocoaheads/testing.1289554277.txt.gz · Zuletzt geändert: 2010/11/12 10:31 von mro