dave339
commented
8 years ago - Ich habe beim letzten mal die statische Code-Analyse vergessen, was wir auch durchführen müssen... In den .TeX Dateien ist es aber schon drin.
Open dave339 opened 8 years ago
dave339
commented
8 years ago 
SpringVaS
commented
8 years ago Hallo,
karma habe ich noch nicht zum laufen bekommen. Irgendwie hat auch noch niemand Testcases gepusht oder benutzen wir für die jetzt auch ein anderes Repo??? Grüße Valentin
On Feb 24, 2016, at 7:31 PM, dave339 notifications@github.com<mailto:notifications@github.com> wrote:
— Reply to this email directly or view it on GitHubhttps://github.com/uzdry/PSE/issues/15#issuecomment-188396141.
ubebg
commented
8 years ago Kurze Info: nach dem was ich nach einigen minuten googeln über Karma herausgefunden habe: Karma lässt die Tests im Browser gegen (nicht auf) einen Testserver laufen. Enstsprechend ist Karma in zwar in Node geschrieben, ist aber nicht für das Testen von Node ausgelegt. Für die Server-Tests müssen wir also glaube ich auf etwas anderes ausweichen.
SpringVaS
commented
8 years ago Das habe ich auch rausgefunden! War nur skeptisch, da bei mir nicht einmal Davids Testcases laufen. Ich bin leider erst ab Dienstag wieder in Karlsruhe bin aber bereit am Wochenende viel zu tun. und habe auch schon die Woche über ein paar Sachen erledigt, siehe Commits. @Nicolas. Kannst du dein GUI zeug gescheit testen? @David: kümmerst du dich um die Benchmarks? Die Kommunikation ist leider immer noch sehr Latenzbehaftet. @David bzw alle. Wie sollte eine gescheite Fehlerdokumentation aussehen. @Jonas und David: Für das Finetuning an der Software, High Speed Bluetooth etc gibt es leider keinen konkreten Ziele.
Viele Grüße
Valentin
On 26 Feb 2016, at 13:40, ubebg notifications@github.com<mailto:notifications@github.com> wrote:unden
Kurze Info: nach dem was ich nach einigen minuten googeln über Karma herausgefunden habe: Karma lässt die Tests im Browser gegen (nicht auf) einen Testserver laufen. Enstsprechend ist Karma in zwar in Node geschrieben, ist aber nicht für das Testen mit Node ausgelegt. Für die Server-Tests müssen wir also glaube ich auf etwas anderes ausweichen.
— Reply to this email directly or view it on GitHubhttps://github.com/uzdry/PSE/issues/15#issuecomment-189259389.
uzdry
commented
8 years ago Ich hab selbst einige Probleme beim Testen. Generell Testen funktioniert, nur kann man nicht den eigentlichen Code sondern nur den gebrowserifyten Code testen. Die Coverage ist dann natürlich auch ganz anders
YimengZhu
commented
8 years ago Weiß jemand wie man mit jasmine ein Event-basiert Funktion testen kann?
Kurze Zusammenfassung (also was wir heute beim Treffen vereinbart haben):
1.) Allgemein: Wenn ihr Code/Code documentation (also Javadoc-ähnlich) oder Testfälle schreibt, dann müsst ihr die ins Repo hochladen, wo wir die Implementation hochgeladen haben (sollte ja klar sein), .TeX files und andere Sachen, die wir als Dokument und nicht als Code ansehen können (auch die Screenshots von Tests... usw.) kommen hierhin. Sollte eigentlich klar sein, ich habe es aber nochmals explizit hingeschrieben.
2.) Jasmine: Wir versuchen möglichst gute Code-Coverage Ergebnisse zu erzielen, 100% ist nicht notwendig, aber je mehr, desto besser. Jeder testet was er geschrieben hat (es ist zwar nicht ganz optimal, aber in unserem Fall ist es höchstwahrscheinlich die beste Lösung). Wir verwenden verschiedene Verzeichnisse pro Modul (z.B..: /spec/ui, /spec/bus/ ... ), wenn die noch nicht erzeugt sind, dann müsst ihr die erzeugen. Siehe auch: 1.) Wenn es nicht klar wäre: für Testfälle ist das Verzeichnis /spec vorgesehen.
3.) Karma: Hilft uns unsere Code-Coverage Ziele zu überprüfen. Verwendet intern Istanbul, läuft im Browser oder auf Node.js, wir können also Karma also für beide Softwareteile verwenden. Einrichtung: Man muss karma installieren, es war ursprünglich in package.json, ich schreibe es irgendwann wieder rein. Wir brauchen die folgende Pakete (also npm install ...):
Es schadet nicht die Firefox/Chrome launchers zu installieren, ist allerdings glaube ich kein muss. Ich nehme an, dass ihr die installiert habt. Wir funktioniert karma? Google hilft... Oder wenn doch nicht: Man kann einfach den Terminal in Webstorm benutzen. Wenn man zuerst ins Verzeichnis node_modules/karma/bin navigiert, dann muss man folgendes eintippen: "karma start ./karma.conf.js" und dann Enter drücken. Damit es läuft muss selbstverständlich karma.conf.js vorhanden sein (im Verzeichnis "node_modules/karma/bin/", ein Beispiel für karma.conf.js lade ich gleich hoch (aber nicht hierhin, sonder ins Repo Vinjab), man kann aber so etwas auch im Internet finden (Google). Klar: man kann andere Verzeichnisse, andere Dateinamen verwenden, dies ist nur als Beispiel gedacht. Laut Nicolas ist karma sogar in Webstorm irgendwie vorhanden / man kann es ziemlich gut integrieren und konfigurieren - ich meine mit Webstorm und nicht nur mit config files - , muss aber nicht, Geschmackssache. Wie finde ich die Coverage-Resultate von Karma? Es wird ein Verzeichnis erzeugt (default: node_modules/karma/bin/coverage/), da gibt es eine Menge von index.html Dateien. Die muss man einfach mit Chrome/Firefox öffnen, die sind statisch, es sind einfach die exportierte Resultate. Hinweis: als wir heute das getestet haben öffnete sich eine Index.html Datei bei mir nicht (war leer), bis jetzt passierte das nie, man muss dann versuchen die verschiedene Index.html Dateien öffnen. Die sind nicht selbstverständlich gleich, sonder hierarchisch strukturiert, man kommt aber nach 20 Sekunden drauf, wie es gemacht wurde, will nicht runterschreiben. Also wenn es nicht klappt, andere index.html Dateien auch versuchen, vielleicht läuft nur die hälfte von Karma nicht :) Wie gesagt bis jetzt hätte ich keine Probleme.
4.) Wir sollen alle Probleme, die wir beim Testen entdecken dokumentieren. Dafür werde ich dann die entsprechende .TeX files hierhin hochladen. Dann soll jeder die einzelne .TeX files bearbeiten, die wir dann am Sonntag nur zusammenfügen müssen, wir haben vereinbart, dass wir am Sonntag praktisch keine Arbeit mehr erledigen können, weil wir jetzt nicht nur schreiben müssen, wie es beim Pflichtenheft war, sondern die Ergebnisse beschreiben müssen, dafür sind aber die Ergebnisse notwendig. Wie wir das vorgestellt haben: jeder produziert eine Liste von Fehlern, die er gefunden hat (siehe auch: 2.)) und fügt folgendes zur .TeX Datei hinzu (Beispiel):
Nach meiner Einschätzung kommt man dann auf ca. 4-5 Fehlern pro Seite bei einem Tex PDF Dokument, das heißt es wäre gut pro Kopf ca. 8-10 Fehlern zu finden. Wenn es mehr gibt, dann ist es in dieser Phase komischerweise gut..
5.) Tests, die wir manuell durchführen müssen. Da wir ziemlich viel GUI haben, gibt es bestimmte Tests, die wir zwar auch automatisiert durchlaufen lassen können, wollen wir aber nicht, weil es kaum etwas bringt, bei Änderungen immer mitgeändert werden muss, auch selbst getestet werden muss... usw. Deswegen werden wir die per Hand durchführen. Wir sollen die aber genau beschreiben - Beispiel: "man klickt dahin, danach tippt man dies und das ein, und dann soll dort folgendes erscheinen und zwar in 0.5 Sekunden". Nicolas hat vorgeschlagen, dass wir vielleicht auch DOM Events erzeugen können, wenn es gelingt, dann ist es gut, aber wie gesagt bei uns ändern sich die Sachen ziemlich schnell und es ist auch eine Fehlerquelle, wenn man die Tests immer manuell mitändern muss, also wenn es klappt, dann klappt, und wir haben gelernt, wie man DOM Events erzeugt, wenn nicht, dann haben wir nicht so viel verloren.
6.) Testszenarien Es gibt manche, die wir im Pflichtenheft haben, wir werden aber höchstwarscheinlich neue Testszenarien schreiben, weil es sich seitdem ziemlich viel geändert hat. Dann gehen wir durch und läuft alles hoffentlich.
7.) Benchmarks Es ist gut, wenn wir nicht nur wissen, dass es funktioniert, sondern auch wissen, wie schnell es funktioniert. Das müssen wir auch messen, also: wir versuchen dann das System zu überlasten und gucken ob es abstürzt oder 100% CPU Auslastung (pro Kern zumindest) verursacht. Es ist zwar ein bisschen komplizierter, aber im Prinzip ist es so.
8.) Installation für unerfahrene Nutzer Wir sollen unsere Implementierung so verpacken, dass praktisch jeder Nutzer dies einrichten kann. Also irgendwie installierbar, ohne eine Menge von node Befehlen, Webstorm-Umgebung & co. Sondern z.B. html öffnen und genießen.
9.) Abnahme Wir sollen alles, was wir gemacht haben zusammenfassen und abgeben. Da wir alles auf Github erledigt haben, wird dies nicht so schwierig.
10.) Wer macht was?
Dies war praktisch alles für heute. Wenn es Fragen gibt, dann bitte einfach fragen.
MfG. David