Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.
max-power
Ohje. Viele grundlegende Fragen.

Ein Test sollte im wesentlichen Input/Output Paare überprüfen. Du nimmst deine Funktion die du testen willst und erstellst möglichst viele Input und Output Paare. Am besten sollten diese alle Branches (if, else, etc.) der Funktion abdecken (Stichwort "code coverage"), so dass jede Zeile der Funktion von dem Test betroffen ist. Zudem sehr simple Fälle oder besondere Randgruppen-Fälle und ggf. Fälle von fehlerhaftem Input. Der Sinn des ganzen ist, dass spätere Änderungen am Code oder Package-updates den Output dieser Input/Output Paare nicht verändern sollten. Bevor man größere Änderungen commited oder deployed sollte man also den Test laufen lassen um sicherzustellen dass noch alle Funktionen den erwarteten Output erzeugen (Es gibt auch Tools wie z.B. Jenkins die Commits mit failenden Tests unterbinden.). Man asserted dass der Output noch ist was er sein soll. Beispielsweise: assert(2*3===6);. Bei komplexerem Output lohnt es sich den erwarteten Output beispielsweise als json im test ordner zu speichern und für den Test zu laden, wie es auch das später erwähnte testcompare Package erleichtert.

Bei node verwende ich mocha fürs testing. Dazu installierst du mocha mit

npm install mocha --save-dev

Das speichert mocha in der package.json als dev depedency.

Dann deklarierst du mocha als Test-Tool in package.json:

  "scripts": {
    "test": "mocha"
  },


dann erzeugst du deine Test Scripts in einem Unterverzeichnis namens "test". Ich nenne sie immer <file>.test.js, also wenn ich bier.js testen will erstelle ich eine bier.test.js im test ordner. So behält man die gut die Übersicht.

um deine Tests auszuführen startest du

npm test

oder

mocha

Um das Schreiben von Tests zu erleichtern hab ich mal folgendes Package geschrieben, dass das Vergleichen größerer Datenstrukturen erleichtert:

https://www.npmjs.com/package/testcompare

das installierst du mit

npm install testcompare --save-dev

das Package selbst enthält auch Tests (ich empfehle mal das Testverzeichnis dort anzuschauen) und im Readme wird die Funktionsweise weiter beschrieben.

Zur vorher erwähnten Code Coverage: Mit einem tool namens istanbul kann dir mocha einen Code Coverage Report erstellen der dir sagt wie gut deine Tests den Code überprüfen.

https://github.com/gotwarlost/istanbul#readme

als root:

npm install -g istanbul

dann:

istanbul cover _mocha -- -R spec

dann im Browser die Datei coverage/lcov-report/index.html öffnen um den code coverage report zu lesen. Dort wären dann Zeilen im Code rot markiert die nie von deinen mocha-Tests erreicht werden.

Zur Linux Distributionsfrage ists schwer was zu sagen. Das hat ja schon religiöse Züge. Ich verwende Arch Linux, es ist rolling Release und läuft einfach. Schon lange keine Probleme mehr gehabt. Updates gehen nicht automatisch, aber mit einem einfachen Konsolenkommando. Ist auch besser so, weil ich keine Versionswechsel will wenn mir der Zeitpunkt nicht passt. Arch hat doch meist sehr aktuelle Versionen die schonmal kleine Wehwehchen haben... Auf einem Server würde ich aber kein Arch laufen lassen. Aber ich will da jetzt nicht zu viel ins Detail gehen. Da bekommt man eh nur Gegenwind...

Ach und ob node nun das richtige für dich ist, kann ich dir nicht sagen, ich weiß ja nicht was du vorhast... Ich finde man kann gut damit arbeiten und das npm system funktioniert gut und erleichtert das Deployment z.B. auf AWS skalierbarer Infrastruktur. Am Ende aber alles Geschmackssache...

Und ein großes LOL an "Spezialsprachen aus den 80ern". Ich war mir kurz unsicher ob du hier trollen willst... Weißt du was alles an gutem Zeug aus dem 80ern oder noch älter ist??? Oft sind es genau die, die deine Anforderung des "einfach laufen"s am besten erfüllen ;)

Ebenso, warum nennst du C eine "Kartenhaus-Sprache"? O.o

Ich hoffe ich konnte helfen ;-)

@sofias: hab noch was dazugeschrieben...

Don't be the product, buy the product!

Schweinderl