Zum Inhalt springen

Just about .Net

It's just a blog about .Net…

Archiv

Kategorie: Test

Bezieht man sich bei der testgetriebenen Entwicklung nur auf die blanke Theorie, so bleiben die eigentlichen Vorteile häufig zu abstrakt. Im nachfolgenden Video wird deshalb eine sehr einfache Code Kata gelöst. Auf diese Weise soll gezeigt werden wie produktiv man mit den entsprechenden Werkzeugen arbeiten kann und wie sehr die so entstandene Testabdeckung bei der Refaktoriserung des Quellcodes hilft.

Ich nutze sehr gern NCrunch um meine Tests automatisch im Hintergrund ausführen zu lassen, hatte aber jüngst das Problem, dass es sich nicht beim Entwickeln einer Universal App nutzen lässt. Im Forum von NCrunch bin ich aber recht schnell auf eine Lösung gestoßen, die ich hier noch einmal zusammen fassen möchte um auch anderen eine schnelle Beseitigung ihres Problems zu ermöglichen.

So scheint das Problem beim Linken der App.xaml Datei zu passieren. Diese liegt im Shared Projekt, welches nachträglich in die jeweiligen Projekte für Windows und Windows Phone eingebunden wird. Die einfachste Lösung scheint nun, diese App.Xaml in der *.projitems Datei des Shared Projekt so zu kennzeichnen, dass sie sauber gelinkt wird.

Continue reading “NCrunch beim Erstellen von Universal Apps verwenden” »

Dieses Jahr war ich für Microsoft als Sprecher auf den Testing Info Days unterwegs. Dies waren zwei Veranstaltungen im März, bei denen ich jeweils in München und Hamburg über Unit Testing mit Visual Studio gesprochen habe. Der entsprechende Mitschnitt dazu findet sich auf Channel 9 und kann nachfolgend auch angesehen werden. Leider gab es wohl beim Schnitt ein paar Probleme mit den Folien wodurch diese nach einiger Zeit asynchron angezeigt werden :(

Weitere Informationen gibt es auch auf der entsprechenden Webseite von Channel9.

Gestern war ich bei Agile Saxony und habe über die unterschiedlichen Schulen des TDD gesprochen und wie sie sich auf unsere Arbeitsweise auswirken. Für mich besonders interessant war dabei die Diskussion am Ende meines Vortrages. Denn anscheinend war meine Vortragsweise etwas negativ konnotiert, wodurch ich eher skeptisch als überzeugt gewirkt haben muss. Ich war sehr übernächtigt, daher entschuldigung an dieser Stelle, wenn der Vortrag nicht die sonst übliche Qualität hatte. Continue reading “Qualität, aber bitte agil!” »

Ein wiederkehrendes Problem das es zu lösen gilt wenn man typische Oberflächen testen möchte, ist die Prüfung auf einen Validierungsrahmen. Solche Rahmen werden immer dann eingesetzt wenn der Nutzer auf eine Falscheingabe hingewiesen werden soll. Dummerweise kann die UI Automation uns keine Informationen über jene Rahmen geben, da sie sie selbst nicht kennt. Wie also vorgehen?

Validierungsrahmen

Continue reading “Coded UI Test: Validierung auf UI Ebene prüfen” »

Ich gebe gern zu, dass ich mich am Anfang eher schwer mit TDD getan habe. Der Grund dafür war, dass die Lehren die ich aus Büchern und Dojos zog, so gar nicht in meinen Entwickleralltag passen wollten. Kleine Umsetzungsschritte die nicht selten durch sinnlos scheinende Zwischenaktionen geprägt waren, haben mich fast zur Weißglut getrieben. Wenn ich dann TDD anwendete verzichtete ich also auf diese Schritte und fand mich nach einiger Zeit wiederum damit konfrontiert, dass meine Tests viel zu komplex wurden und die angeblichen Vorteile von TDD praktisch nicht präsent waren.

Continue reading “„Ausprägungen des TDD“ aka „Die Triangulations-Baby-Step-Holzkeule“” »

„Agilität, Agilität, Agilität.“ So rauscht(e) es durch die Softwareentwicklungslandschaft. Jeder der nicht wenigstens iterativ arbeitet ist uncool, ewig gestrig, arbeitet fernab jeder Realität und wird auf Dauer einen langen und qualvollen Tot in der Change-Request-Refaktorisierungs-Bug-Ping-Pong-Hölle sterben. Na gut, letzteres passiert meiner Erfahrung nach eher denjenigen die sich all zu unvorsichtig auf die Agilität eingelassen haben ohne ihre tatsächlich gelebten Vorgehen einmal in Frage zu stellen.

Die Verschmelzung zweier Welten hat immer zur Folge, dass Teile dieser zwei in die Neue übergehen und das ist völlig richtig so. Dumm nur, wenn Dinge konvergieren die eigentlich besser nicht kombiniert werden sollten. Dann wird aus dem Elysion sehr schnell der Tataros. Genau das passiert meiner Meinung nach wenn sich die Qualitätssicherung nicht daran anpasst, dass Requirements verändert werden. Denn so viel hat das Mantra der Agilität erreicht: In den Köpfen ist angekommen, dass es besser ist auf Veränderung zu reagieren als einem strikten Plan zu folgen. Im Umkehrschluss also: Alles bleibt anders!

Continue reading “Agilität, Qualität & andere Missverständnisse…” »

Da Requirements die Grundlage der Entwicklung und somit auch der Kommunikation mit dem Kunden und innerhalb des Teams sind, lohnt es sich in einigen Fällen diese in der Muttersprache des Kunden zu verfassen um Missverständnissen vorzubeugen. Gherkin bzw. Specflow unterstützen dies in dem die Feature Dateien in über 40 unterschiedlichen Sprachen erstellt werden können. Dazu gehört, wer hätte es gedacht, auch Deutsch.

Um dieses Feature einzuschalten ist auch nicht sonderlich viel Arbeit notwendig. Tatsächlich muss nur eine App.Config im entsprechenden Projekt hinterlegt werden die folgenden Inhalt hat.


<?xml version="1.0" encoding="utf-8"?>
<configuration>
   <configSections>
      <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow" />
   </configSections>
   <specFlow>
      <language feature="de-DE" />
   </specFlow>
</configuration>

Die eigentliche Magie passiert durch das „language“ Element dem über Feature das Kürzel der zu verwendenden Kultur anzugeben ist. Darüber hinaus gibt es noch ein Attribut „tool“ mit dem es theoretisch möglich sein soll auch die Fehlerausschriften, und damit zum Beispiel die Beschreibungen über nicht implementierte Features, zu übersetzen. Praktisch ist dies aber aktuell nicht möglich, da nur Englisch unterstützt wird.

Nachdem die App.config gespeichert wurde, schaltet Specflow sofort in die neue Sprache und funktioniert wie gewohnt, einschließlich Autovervollständigung.

Specflow auf deutsch

Jedes Blog, in dem gelegentlich über Tests geschrieben wird und welches etwas auf sich hält, muss mindestens einmal etwas über das Testen von privaten Klassenmembern schreiben. Zugegeben in einem anderen Post habe ich bereits gezeigt wie das geht, nun habe ich aber endlich ein Praxisbeispiel an dem sich sehr gut zeigen lässt wann man evtl. einen anderen, sichereren Weg gehen sollte.

Entwickelt man seinen Code tatsächlich mit TDD, sollte sich die Frage nach dem Test von privaten Membern eigentlich kaum stellen. Dadurch dass nur Code geschrieben wird, der auch durch Tests abgesichert ist sollten sich in jedem Fall genügend Vorbedingungen ergeben um auch jede private Methode irgendwie durch die öffentlichen Schnittstellen zu prüfen.

Continue reading “Privates testen in dem es public wird…” »

Automatisiertes Testen mit Visual Studio 2012_kleinAnfang letzter Woche hat mein Video Training zur Testautomatisierung mit Visual Studio 2012, welches ich Ende letzten Jahres bei Video2Brain aufgenommen habe, endlich das Licht der Welt erblickt. Der Name des Trainings ist dabei Programm. Mir geht es nicht darum zu beschreiben wie Unit Tests oder sogar TDD mit Visual Studio realisiert werden können, sondern wie Tests generell automatisiert werden.

Ich mache diese Trennung, da aus meiner Sicht Visual Studio einen etwas schlechten Ruf im Bereich der Unit Tests hat, über diese hinaus aber noch wesentlich mehr Möglichkeiten bietet, die gern vergessen werden. Welche das im Einzelnen sind kann man der Beschreibung des Trainings entnehmen. Denn darin beschreibe ich mehr als die Hälfte der Zeit Themen wie Lasttests, Coded UI Tests oder Webleistungs Tests.

Ich mache in dem Training also keine direkte Unterscheidung zwischen Testern und Entwicklern, was auch der Grund ist warum ich im kurzen Theorieteil vor allem auf Beschreibungen aus dem Buch „Basiswissen Softwaretest“ von Andreas Spillner und Tilo Linz, statt auf die Definition einschlägiger englischsprachiger Autoren zurückgegriffen habe. Für mich ist Testautomatisierung ein generelles Thema mit dem ein Team sich insgesamt viel Arbeit ersparen kann und sollte nicht mit der Erstellung von Unit Tests enden.

Ich hoffe also, dass das Training nützlich ist und manchem vielleicht sogar den Weg zu test getriebenen Entwicklung ebnet, denn wo ein Test ist, da folgen sicher noch mehr…