Von mgraesslin am Mi, 17. September 2014 um 14:44 #
gibt es denn bei KDE keine automatischen Tests, bzw. werden behobene Fehler dort nicht eingepflegt, um solche heftigen Fehler und Regressionen zu vermeiden?
Klar gibt es automatische Tests, aber das verhindert leider nicht alle möglichen Probleme. Um mal ein Beispiel aus meinem Umfeld (KWin) zu nennen: man kann xrandr nicht simulieren, Xvfb unterstützt keine moderne xrandr Versionen, also kann ich Code der mit xrandr interagiert nicht automatisch testen.
Ähnlich sieht es natürlich auch bei anderen Projekten aus wo man eigentlich integration Tests braucht. Wie soll KMail GMail spezifische Probleme abtesten wenn man so einen Server nicht aufsetzen kann.
Fazit: in der Praxis ist das nicht immer ganz so trivial, wie es immer klingt.
Wie soll KMail GMail spezifische Probleme abtesten wenn man so einen Server nicht aufsetzen kann.
Ich frag mich dann halt nur, wie es die Entwickler von anderen Mail-Clients es fertigbringen eine funktionierende Gmail-Anbindung hinzubringen? Die haben doch das gleiche Problem.
Das ist aus dem Kontext im Artikel nicht so ersichtlich, aber soweit ich das verstanden habe ist das ein Fall, wo durch eine Verbesserung der GMail-Anbindung ein nachteiliger Effekt für einige andere IMAP Server aufgetreten ist.
Die Version vorher hatte GMail mehr oder weniger wie jeden andere IMAP Server behandelt (mit den üblichen Workarounds für GMails Mängel).
Von tomkater68 am Mi, 17. September 2014 um 16:39 #
ein nachteiliger Effekt für einige andere IMAP Server aufgetreten ist.
Nicht 'einige andere' sondern 'ein anderer'. Und der hat sich nicht an die IMAP-Spezifikation gehalten, sonst hätte es diesen Effekt auch nicht gegeben.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Sep 2014 um 16:42.
@Martin: Habt ihr denn auch automatisierte Integrationstests? Insbesondere welche, die auch die Oberflächen (oder externe Programme) testen?
Ich habe beruflich Erfahrungen mit dem Ranorex Test Tool. Imho ein tolles Produkt. Ist halt ein kostenpflichtiges Programm, welches leider auch nur in der Windows-Welt läuft Aber prinzipiell wäre so etwas natürlich ein guter Weg, wirklich den Desktop selber zu testen.
Ich hatte auf planetkde.org auch schon mal Artikel gelesen, in denen jemand eine Art Filesystem-Mocker vorgestellt hatte, der aber tatsächlich *wirklich* im FS eine bestimmte Dateistruktur anlegt. Imho sind das keine Unitests mehr, sondern bereits Integrationstests - wenngleich man dafür natürlich ein Unittest-Framework nutzen kann. Im eigentlichen Sinne ist das aber schon ein Integrationstest. Gibt es da Kriterien, wie ihr Tests organisiert?
Ansonsten wie immer ein großes Dankeschön für Deine und Eure Mühen und die imho tolle Arbeit, die Ihr von KDE leistet! Ich bin damit sehr zufrieden
Von mgraesslin am Mi, 17. September 2014 um 18:28 #
Also wenn man testing Puristen fragt, dann ist (fast) jeder Test den ich für KWin oder KWindowSystem geschrieben habe ein Integrationstest. Sie alle laufen gegen einen XServer, zum Teil starten sie sogar einen. Also eigentlich ein Integrationstest. Für mich ist das aber ein Unittest. Die Unit ist halt ein bißchen größer Was anderes macht meiner Meinung nach kaum Sinn. Es ist ja schön, wenn der Code gegen die gemockte Library funktioniert, aber ziemlich wertlos, wenn in der Realität sich X dann doch nicht wie in der Spezifikation verhält. Also nimm ich lieber gleich den X (oder Wayland) dazu den man braucht.
Was Oberflächen angeht weiß ich nicht genau wieviel und wie wir da testen. Ich schreibe ja keine GUI.
Also wenn man testing Puristen fragt, dann ist (fast) jeder Test den ich für KWin oder KWindowSystem geschrieben habe ein Integrationstest. Sie alle laufen gegen einen XServer, zum Teil starten sie sogar einen. Also eigentlich ein Integrationstest. Für mich ist das aber ein Unittest. Die Unit ist halt ein bißchen größer ;-)
Hehe... Du arbeitest ja auch an Stellen, an denen man quasi immer direkten Kontakt zu einem externen System hat. Da ist es dann letztlich egal, wie man es "nennt", denn etwas anderes bleibt Dir eh nicht übrig
Es ist ja schön, wenn der Code gegen die gemockte Library funktioniert, aber ziemlich wertlos, wenn in der Realität sich X dann doch nicht wie in der Spezifikation verhält.
Bei Dir sicherlich ein gesondertes Problem. Allgemein ist es natürlich dennoch sinnvoll, Tests vollkommen losgelöst von einer Abhängigkeit zu haben. Schließlich will man ja die Richtigkeit *seines* Codes überprüfen
Von kamome umidori am Mi, 17. September 2014 um 20:40 #
Danke Martin,
dass es einfach ist, habe ich auch nicht erwartet. Aber das ganze Projekt würde doch sehr davon profitieren, wenn (besonders so wichtige Programme) gut getestet wären (mit Integration). Dann hoffe ich einfach, dass KMail/Akonade/Baloo doch noch die Kurve kriegt und ich irgendwann zu "5er-Zeiten" umsteigen kann.
Klar gibt es automatische Tests, aber das verhindert leider nicht alle möglichen Probleme. Um mal ein Beispiel aus meinem Umfeld (KWin) zu nennen: man kann xrandr nicht simulieren, Xvfb unterstützt keine moderne xrandr Versionen, also kann ich Code der mit xrandr interagiert nicht automatisch testen.
Ähnlich sieht es natürlich auch bei anderen Projekten aus wo man eigentlich integration Tests braucht. Wie soll KMail GMail spezifische Probleme abtesten wenn man so einen Server nicht aufsetzen kann.
Fazit: in der Praxis ist das nicht immer ganz so trivial, wie es immer klingt.
Das ist aus dem Kontext im Artikel nicht so ersichtlich, aber soweit ich das verstanden habe ist das ein Fall, wo durch eine Verbesserung der GMail-Anbindung ein nachteiliger Effekt für einige andere IMAP Server aufgetreten ist.
Die Version vorher hatte GMail mehr oder weniger wie jeden andere IMAP Server behandelt (mit den üblichen Workarounds für GMails Mängel).
ein nachteiliger Effekt für einige andere IMAP Server aufgetreten ist.
Nicht 'einige andere' sondern 'ein anderer'. Und der hat sich nicht an die IMAP-Spezifikation gehalten, sonst hätte es diesen Effekt auch nicht gegeben.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Sep 2014 um 16:42.@Martin: Habt ihr denn auch automatisierte Integrationstests? Insbesondere welche, die auch die Oberflächen (oder externe Programme) testen?
Ich habe beruflich Erfahrungen mit dem Ranorex Test Tool. Imho ein tolles Produkt. Ist halt ein kostenpflichtiges Programm, welches leider auch nur in der Windows-Welt läuft
Aber prinzipiell wäre so etwas natürlich ein guter Weg, wirklich den Desktop selber zu testen.
Ich hatte auf planetkde.org auch schon mal Artikel gelesen, in denen jemand eine Art Filesystem-Mocker vorgestellt hatte, der aber tatsächlich *wirklich* im FS eine bestimmte Dateistruktur anlegt. Imho sind das keine Unitests mehr, sondern bereits Integrationstests - wenngleich man dafür natürlich ein Unittest-Framework nutzen kann. Im eigentlichen Sinne ist das aber schon ein Integrationstest. Gibt es da Kriterien, wie ihr Tests organisiert?
Ansonsten wie immer ein großes Dankeschön für Deine und Eure Mühen und die imho tolle Arbeit, die Ihr von KDE leistet! Ich bin damit sehr zufrieden
Also wenn man testing Puristen fragt, dann ist (fast) jeder Test den ich für KWin oder KWindowSystem geschrieben habe ein Integrationstest. Sie alle laufen gegen einen XServer, zum Teil starten sie sogar einen. Also eigentlich ein Integrationstest. Für mich ist das aber ein Unittest. Die Unit ist halt ein bißchen größer
Was anderes macht meiner Meinung nach kaum Sinn. Es ist ja schön, wenn der Code gegen die gemockte Library funktioniert, aber ziemlich wertlos, wenn in der Realität sich X dann doch nicht wie in der Spezifikation verhält. Also nimm ich lieber gleich den X (oder Wayland) dazu den man braucht.
Was Oberflächen angeht weiß ich nicht genau wieviel und wie wir da testen. Ich schreibe ja keine GUI.
Vielen Dank für die Infos!
Danke Martin,
dass es einfach ist, habe ich auch nicht erwartet. Aber das ganze Projekt würde doch sehr davon profitieren, wenn (besonders so wichtige Programme) gut getestet wären (mit Integration).
Dann hoffe ich einfach, dass KMail/Akonade/Baloo doch noch die Kurve kriegt und ich irgendwann zu "5er-Zeiten" umsteigen kann.
Ihr nutzt doch Jenkins?
ja, build.kde.org ist ein Jenkins setup.