Im Grunde nach werden zwei Arten von Tests durchgeführt mit dem Ziel Software Qualität zu steigern. Der Unit Test prüft mehr oder weniger granular Methoden auf erwartete Rückgabe Werte. Der End 2 End Test nimmt die komplette Anwendung und imitiert die normale Nutzung übers UI.
In meinem aktuellen Umfeld Angular.js wird Jasmine.js als Testframework hauptsächlich eingesetzt. Um besagte End 2 End (E2E) Integration Tests zu erstellen, verwendet die JavaScript Community protactor.js. Das wiederrum setzt node.js als Laufzeitumgebung voraus.
Um einen Taschenrechner zu testen könnte man folgenden Test verwenden
1: describe('Webpage End 2 End', function () {
2: beforeEach(function () {
3: });
4: it('Rechnen 1+2 ', function () {
5: browser.get('calc.html');
6: element(by.id("a")).sendKeys(1);
7: element(by.id("b")).sendKeys(2);
8: element(by.id('btn')).click();
9: var c = element(by.id("c")).getAttribute('value');
10: expect(c).toEqual(3);
11: });
12: });
Um ehrlich zu sein, dieser Test, wird bei mir aufgrund fehlender Infrastruktur aktuell im Visual Studio 2013 Projekt ignoriert.
Nachdem ich einen Schritt zurück getreten bin, stellte sich mir die Frage, warum muss die Testlogik eines HTML UI Tests mit JS geschrieben werden? Richtig – dafür gibt's keinen Grund. Es geht auch mit .net.
Und irgendwer hat sich auch die Zeit genommen eine Portierung nach .net vorzunehmen https://github.com/bbaia/protractor-net
Im einem Anfall von Faulheit, habe ich per google ein Stück Beispiel Code gesucht und von Dan Wahlin gefunden https://github.com/DanWahlin/CustomerManagerStandard indem die Library auch verwendet wird.
Jetzt lehne ich mich noch weiter zurück und erinnere mich an die guten alten Lasttests oder auch Stresstest genannt. Vor vielen Jahren gab es schon mal das Web Application Stress Test Tool von Microsoft (wcat). Damit wurde das Verhalten des Benutzers im Browser aufgezeichnet und dann immer wieder automatisch ausgeführt um die Anzahl der gleichzeitigen Zugriffe zum Webserver bzw. Website messen zu können.
Fazit: Es muss eben nicht immer JavaScript sein. Außerdem halte ich es für völlig ausgeschlossen einen UI Test bzw. Integrations Test dem TDD Pattern folgend zuerst zu implementieren. Alleine schon weil TDD nur mit gemockten (also simulierten) Datenbank zugriffen arbeiten soll.
Meine nächste Aufgabe wird sein sich die Funktion Web Stress Test, das Recording über den Internet Explorer und die Coded UI Tests von Visual Studio 2013 zu beschreiben.