Visual Studio und Jasmine

Um ganz ehrlich zu sein, um TDD (Testdriven Development) habe ich bisher einen großen Bogen gemacht. Die theoretischen Grundlagen, ein zwei Beispiele und fertig. Der Aufwand ist definitiv höher und der erwartete Gewinn kaum erkennbar, da meine Software ohnehin nie Fehler hat.

Nun ist es aber so, dass JavaScript auf absehbare Zeit, die gesetzte Sprache ist. Anders als bei meinem geliebten VB.NET, bügelt kein Intellisense und Compiler meine Typos aus. JavaScript ist eben sehr dynamisch, auch in den Ergebnissen. Nach einem intensiven Coding Dojo, reifte in mir die Erkenntnis, das Tests ein adäquates Mittel sind, um in JavaScript Projekten reproduzierbare Ergebnisse zu erhalten.

Um nicht gänzlich die geliebte Heimaterde zu verlassen, habe ich mir in den Kopf gesetzt Node.js, npm und anderes Gedöns dabei links liegen zu lassen und ausschließlich Visual Studio zu verwenden.

In der Regel brauchen Units Tests ein Framework das hilft, die Tests zu schreiben und einen sogenannten Runner, der die Tests zu einem bestimmten Zeitpunkt ausführt. Für letzteres wird gerne Karama verwendet, dass auf Node aufsetzt. Für das Test Szenario wird häufig Jasmine genutzt.

Aufsetzen der Testumgebung

Im ersten Schritt wird Visual Studio 2013 um zwei Extensions erweitert, die beide Chutzpah genannt werden (idealer Name für Google suche). Das eine  ein Testrunner der das Context Menü von Visual Studio erweitert. Das zweite als Adapter für die Integration der Tests in den Visual Studio Unit Test Explorer.

https://visualstudiogallery.msdn.microsoft.com/71a4e9bd-f660-448f-bd92-f5a65d39b7f0

https://visualstudiogallery.msdn.microsoft.com/f8741f04-bae4-4900-81c7-7c9bfb9ed1fe

Dies muss nur einmalig installiert werden.

Im nächsten Schritt wird ein Web Projekt auf ASP.NET MVC Basis (Sprache C#) angelegt. Per Nuget Paket Manager wird das Paket JasmineTest in das Projekt eingefügt.

Jasmintest

Damit hat man ein fertiges Beispielprojekt und die passenden Tests dazu. Als Spielwiese vorerst ausreichend. Die JavaScript Logik liegt in den Beispiel Dateien Player und  Song. Die Tests in PlayerSpec und in der Helper Datei.

image

Ein Jasmine Test beginnt mit einem Beschreibungsblock (Describe). In den Zeilen 2-8 wird vorbereitender Code ausgeführt. Mit dem IT Kommando wird der Test eingeleitet und damit die eigentliche Logik ausgeführt. Expect beschreibt das erwartete Ergebnis.

   1:  describe("Player", function () {
   2:    var player;
   3:    var song;
   4:   
   5:    beforeEach(function() {
   6:      player = new Player();
   7:      song = new Song();
   8:    });
   9:   
  10:    it("should be able to play a Song", function() {
  11:      player.play(song);
  12:      expect(player.currentlyPlayingSong).toEqual(song);
  13:   
  14:      //demonstrates use of custom matcher
  15:      expect(player).toBePlaying(song);
  16:    });

 

Es gibt verschiedene Arten den Test auszuführen. Wenn man das Jasmine.js Framework direkt von Github lädt, befindet sich im Paket eine Datei SpecRunner.html. Die kann man im Browser aufrufen, ganz ohne Visual Studio oder Webserver. Im Nuget HTML Template wird diese Datei als Razor View ausgeführt, samt Controller. Also Server rendert Code. Eigentlich völlig unnötig, außer man möchte die Routing Engine von MVC unbedingt nutzen. Der JasmineController lädt den SpecRunner.cshtml.

   1:    public class JasmineController : Controller
   2:      {
   3:          public ViewResult Run()
   4:          {
   5:              return View("SpecRunner");
   6:          }
   7:          
   8:      }

Im Browser führt die URL /Jasmin/run folglich zum Test, der hier in fünf Stufen erfolgreich ist.

image

Eine weitere Möglichkeit die Tests laufen zu lassen findet sich im Kontext Menü des Projektes.

image

Die Ergebnisse lassen sich im Output Fenster von Visual Studio analysieren. Allerdings benötigt Chutzpah verweise auf die Code Dateien in der test Datei. Beim ersten Beispiel mit der HTML Datei im Browser waren das simple Script Referenzen. Im Falle von Chutzpah werden speziell formatierte Kommentare am Anfang eingefügt, die vom Testrunner geparst werden.

   1:  /// <reference path="C:\Users\user\Documents\visual 
studio 2013\Projects\WebApplication7Test\WebApplication7Test\
Scripts\jasmine-samples\player.js"
/>
   2:  /// <reference path="C:\Users\user\Documents\visual 
studio 2013\Projects\WebApplication7Test\WebApplication7Test\
Scripts\jasmine-samples\song.js"
/>
   3:  /// <reference path="C:\Users\user\Documents\visual 
studio 2013\Projects\WebApplication7Test\WebApplication7Test\
Scripts\jasmine-samples\spechelper.js"
/>

Weil die Test Runner Extension installiert ist, werden die Tests auch automatisch beim Build des JavaScript Projektes im Test Explorer durchgeführt.

image

Das ist für mich der eigentliche Ersatz für den Compiler.

Für einen ersten Versuch wurde die Logik des Players verändert und der Status isPlaying bei Play auf false gesetzt. Prompt schlagen zwei Tests fehl.

image

Als nächstes wird die Verwendung anhand eines Angular.JS Controllers demonstriert, da dies auch Bestandteil der Angular Schulung ist.

Kommentare sind geschlossen