Zum Inhalt springen

Just about .Net

It's just a blog about .Net…

Archiv

Archiv für Mai 2013

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

… and all I got was this lousy Christmas tree.

I like TDD and I like test automation. It is great to see the application growing with each successful test and to be sure that it will work even if a lot of changes are made on the code base. On the other I see (especially) TDD as a practice which is hard to master and I can understand people who drop any ambition because it feels intricate and some times frustrating in real projects.

One of these things is for example the advice to use baby steps to drive the implementation. I thing this advice is essentially to TDD and makes, from my point of view, the difference between Test First and Test Driven Development. Baby steps means, that you are not allowed to implement more functionality than needed by your tests. If the test expects a 1 as return value of your method, than your first step would be to simply return a 1. Your algorithm will also grow with each test you write and that’s why it is called Test Driven Development. This has also the advantage that the your tests get more robust, they are easier to change and to read, at least in theory.

Continue reading “All I wanted was a pyramid…” »