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!” »
Archiv
Kategorie: SpecflowIch mag Specflow und ich finde es toll, dass gleich eine handvoll von Dateitemplates mit installiert werden. Aber es nervt nach einiger Zeit dann doch, dort immer das Taschenrechnerbeispiel vorzufinden. Aus diesem Grund habe ich meine Templates angepasst und stelle sie hier zur Verfügung.
„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 und Gherkin sind sehr praktisch wenn es darum geht Tests zu verfassen und anschließend zu automatisieren. Dabei werden Tests klarsprachlich mit Gherkin formuliert und anschließend von Specflow in automatische Tests übertragen. Leider gibt es hier aber ein „kleines“ Problem bei der Zusammenarbeit mit den Coded UI Tests von Visual Studio. Diese verwenden, im Gegensatz zum sonst üblichen TestClass-Attribut, das Attribut CodedUITest.
Da Specflow für jede Feature Datei aber nur das TestClass Attribut verwendet, müssen wir nur also Hand anlegen und den Code Generator ein wenig erweitern. Wie man genau vorgeht ist bereits bei GitHub beschrieben, wo ich auch den Code für Version 1.9 nachgetragen habe. Ich würde das Vorgehen dennoch hier ein wenig ausführlicher beschreiben, damit es auch in Deutsch verfügbar ist.
Continue reading “Specflow 1.9 mit Coded UI Tests verheiraten” »
Testautomatisierung läuft uns meist eher auf Ebene der Unit Tests über den Weg. Sie kann aber auch bei System Tests recht praktisch sein. Ein Tool was uns WPF, Silverlight und Windows Forms Entwicklern dabei hilft, ist White. Bei diesem handelt es sich um ein Framework mit dem man Applikationen steuern und Steuerelemente innerhalb dieser Programme identifizieren kann, wodurch es möglich wird bestimmte Use Cases nachzustellen und deren Ergebnisse auf ihre Korrektheit zu prüfen. Dieses kann im Grunde mit jedem beliebigen Testframework verwendet werden und greift auf die UIAutomation API zurück die zum Beispiel auch von den Coded UI Tests des Studios genutzt wird.
Continue reading “How-To: Automatisierte UI Tests mit White” »
Ich habe mal wieder etwas geschrieben bzw. an etwas mit geschrieben. Gemeinsam mit einem guten Freund habe ich den Artikel „Mit Geschichten zum Erfolg“ in der aktuellen Dotnetpro verfasst. Ziel dessen war einmal ohne die direkte Betrachtung von Scrum, Kanban und Co. über die Möglichkeiten aufzuklären die sich ergeben wenn man Anforderungen auf eine etwas andere Art als den typischen Use Case, nach ISO oder Sätzen wie: „The X shall Y“ verfasst.
Natürlich geht es dabei nicht zuletzt auch um Agilität und natürlich ist dieses Thema nicht unbedingt brand heiß oder absolut neu, aber uns ging es viel mehr darum die für den Entwickler wichtigen Kernfaktoren bei diesem Vorgehen hervorzuheben.
Zumindest aus meiner Sicht ist Agilität zu einem gewissen Grad zum Modewort verkommen, dass nicht selten genutzt wird wenn das Wort Chaos besser angebracht währe. Ein Prozess wird meiner Meinung nicht dadurch agil, dass die Anforderungen nur tröpfchenweise zu den Entwickler durchsickern. Er wird auch nicht dadurch agil, dass man jeden Morgen 15 Minuten im Kreis sitzt und über Probleme redet. Er wird agil, weil tatsächlich auf Veränderungen eingegangen werden kann ohne all zu große Reibungsverluste befürchten zu müssen und dafür ist es notwendig, dass das Team zu jeder Zeit den aktuellen Ist-Zustand der Software kennt und sich ebenso bewusst über den zukünftigen Soll-Zustand ist.
Kern dessen ist daher die User Story. Ganz einfach weil sie alle notwendigen Infos auf einen Blick darstellt ohne dabei ein bestimmtes Vorwissen vorauszusetzen. Sie ist einfach zu verstehen und verbietet die nachträgliche Diskussion darüber nicht. Im Gegenteil, sie fördert die Diskussion auf eine normalsprachliche Weise ohne das Geschwurbel, dass ich regelmäßig lesen muss weil irgend wer versucht sich nach allen Seiten hin abzusichern.
Genau diese Aussage ist mir aber in anderen Veröffentlichungen, Bücher ausgenommen, die ich bisher gelesen habe etwas zu kurz gekommen und so haben Stefan und ich uns darüber her gemacht das zentrale Wissen dazu zu destilieren und einmal ohne den Verweis auf Scrum usw. zusammen zu fassen, in der Hoffnung gleichzeit erklären zu können warum jedes einzelne Teammitglied davon profitiert.
Als absoluten Vorteil von BDD empfinde ich die Möglichkeiten die es bei der technischen Dokumentation bietet. Denn sind wir doch mal ehrlich, die einzige Wahrheit steckt doch im Code und herkömmliche Doku lügt uns nur all zu schnell an.
Continue reading “Reporting mit Specflow” »
Mein Vortrag bei der DNUG Dresden ist jetzt schon 2 Wochen her, man wie die Zeit verfliegt. Schuldig geblieben bin ich seit dem aber immer noch die gezeigten Materialien und weiterführende Links. Das will ich an dieser Stelle wenigstens halbwegs nachholen und all Denen, die nicht da waren zumindest einen Weg zur Erkenntnis weisen 
Continue reading “Specflow zum Selber-Spielen - Quellen zum Vortrag bei der DNUG DD” »
Hendrik Lösch
