Virtuelle Maschinen sind besser: sie werden in den gewünschten Zustand gebracht, suspendiert und das resultierend Image wird gesichert.
Der Test kann dann dieses Image nehmen, die VM starten, den Test laufen lassen und dann die VM beenden.
Da gebe ich dir völlig Recht. Ich wollte nur darauf hinweisen, dass das bei mangeldem Speicher/Plattenplatz auch mit einem einzelnen, einfachen Server möglich wäre.
Die VMs sind aber ganz klar die besser Lösung, zumal es die für nahezu alle freien Groupware Lösungen bereits fertig gibt. Für Zarafa z.B. hier: http://www.zarafa.com/wiki/index.php/Zarafa_VMware_virtual_appliance
Nicht unüberwindlich, aber kein so einfach vernachlässigbarer Aufwand. Man kann ja nicht einfach ein paar Groupware Server laufen lassen und hoffen, dass die erwartet Testsituation zufällig exisitert.
Der obige Bug wäre mit einem trivialen Integrationstest sofort aufgefallen und erfordert auch keine besondere Testsituation:
1. Item anlegen 2. Sync => FAIL
Noch einfacher geht's nicht.
Die ganzen VM Images brauchen Platz, also Hardware, die sehr wahrscheinliche parallele Ausführung mehrerer VMs brauch Speicher, also Hardware, die Inhalte der VMs müssen gewartet werden, also Administrationsressourcen.
Festplattenplatz wird benötigt, aber eine parallele Ausführung der VMs ist nicht nötig. Die Tests können sequentiell abgearbeitet werden und brauchen dann halt etwas länger. Die Testcases müssen ja nicht unbedingt bei jedem Commit laufen.
Es geht hier nicht um das Schreiben von Testcases, sondern um das Bereitstellen von Infrastruktur für diese Tests. Denn die Testcases sind geschrieben, nur können sie mangels entsprechender Infrastruktur nicht automatisiert, und leider erst recht nicht kontinuierlich, ausgeführt werden.
Wenn die Tests bereits existieren, dann ist die Hürde der Infrastruktur nur umso unverständlicher. Für 600 Euro im Jahr bekommt man bei einem Billighoster wie Hetzner eine Maschine, die weit mehr als ausreichend ist. Darauf könnte man einen Großteil des Testinfrastruktur des KDE Projekts laufen lassen.
Wenn der KDE e.V. keine 600 Euro im Jahr für einen Testserver aufbringen kann, dann ist es in der Tat Zeit für einen Spendenaufruf. Diese 600 Euro dürftet ihr in wenigen Minuten zusammen haben. Ich würde mich ebenfalls beteiligen.
Als Außenstehender hat man natürlich immer leicht reden, aber jetzt mal ernsthaft: Wie wollt ihr KDEPIM jemals stabil bekommen wenn ihr nicht gegen die wirklichen Server testet? Das ist doch ein Ding der Unmöglichkeit. Ich denke da wird jeder, der schon mal größere Softwareprojekte entwickelt hat uneingeschränkt zustimmen. Insofern sollte doch ein Testserver absolut oberstes Gebot sein. So lange der KDE e.V. Geld für Kongresse usw. hat, so lange ist es einfach nicht glaubwürdig, dass es für eine Testinfrastruktur nicht mehr reicht.
Ich wollte nur darauf hinweisen, dass das bei mangeldem Speicher/Plattenplatz auch mit einem einzelnen, einfachen Server möglich wäre.
Klar, für manuelle Tests ginge das. Aber es ging um automatisierte Tests.
In diesem Fall muss sicher gestellt sein, dass erstens eine bekannte Ausgangssiituation besteht und zweitens kein anderer Test zur selben Zeit den Zustand ändert. Letzteres ist auch bei einem manuellen Test notwendig.
Die VMs sind aber ganz klar die besser Lösung, zumal es die für nahezu alle freien Groupware Lösungen bereits fertig gibt. Für Zarafa z.B. hier: http://www.zarafa.com/wiki/index.php/Zarafa_VMware_virtual_appliance
Gut zu wissen, das wäre schon mal ein Ansatz für entsprechende Testimages.
Der obige Bug wäre mit einem trivialen Integrationstest sofort aufgefallen und erfordert auch keine besondere Testsituation:
Das ist ein relativ naiver "hoffen das alles passt" Ansatz, keine aussagekräftige Teststellung.
Für einen echten Test, dessen Fehlschlagen das Auftreten eines Fehlers erkennen lässt, muss sicher gestellt sein, dass die Aufgabe ansich durchführbar ist.
D.h. der Benutzer und das entsprechende Passwort müssen existieren, nicht das vielleicht ein anderer Test gerade das Passwortändern oder das Accountlöschen getestet hat.
Das Quota des Benutzers muss OK sein, der Zielordner muss exisitieren und die am Ordner vorhandene Rechte müssen das Hinzufügen erlauben, der Ordner darf nicht schon einen Eintrag mit der selben Identifikation oder ähnliches beinhalten, während des Test darf nichts anderes den Eintrag löschen, verändern, oder ähnliches mit dem Ordner machen.
Jeder, der schon mal automatisierte Tests erstellt hat, weiß, dass der aufwendige Teil nicht der Test ist, sondern das Herstellen und Absichern der Testsituation.
Ohne Gewissheit, dass alle für den Test notwendigen Vorraussetzungen gegeben sind, ist das Fehlschlagen des Test keine ausreichende Indikation für einen Fehler der getesteten Funktionalität. Selbst ein Testerfolg lässt keine Schlussfolge auf das korrekte Funktionieren zu.
Der Test hat damit seine Aufgabe verloren!
Die Tests können sequentiell abgearbeitet werden und brauchen dann halt etwas länger.
Auch das ist leichter gesagt als getan
Derzeit können verschieden Projekte von einander unabhängig gebaut und getestet werden, d.h. für den Build sind nur die jeweiligen Abhängigkeiten relevant.
Für eine singuläre Instanz müssten alle Projekte hintereinander gebaut werden, ein Fehlschlag während des Bauens darf nicht zum Abbruch des Durchlaufs führen.
Alle gemeinsamen Abhängigkeiten müssen von allen Projekten in der selben Version benutzt werden können. D.h. KDE PIM müsste gegen kdepimlibs und kdelibs stable gebaut werden können, wenn andere davon abhängig Projekte nicht wegen einem Fehler in den jeweiligen Masterzweigen behindert werden sollen.
D.h. Tests für Erweiterungen oder Fixes über Modulgrenzen sind nicht möglich oder riskieren eine "Nullrunde" für alle. Collateral Damage
Wenn die Tests bereits existieren, dann ist die Hürde der Infrastruktur nur umso unverständlicher. Für 600 Euro im Jahr bekommt man bei einem Billighoster wie Hetzner eine Maschine, die weit mehr als ausreichend ist
Infrastruktur ist leider nicht nur die Hardware. Dieser Rechner muss gewartet und überwacht werden, die Enwickler brauchen Tools um Teststellungen zu erzeugen und zu registieren (damit sie in Teste referenziert werden können), Tools um diese Teststellungen zu aktualiseren, usw.
Ich behaupte nicht, dass es nicht möglich wäre, aber es ist wesentlich aufwendiger als man vielleicht meinen könnte, wenn man sich nicht mit den anfallenden Details beschäftigt.
Wie wollt ihr KDEPIM jemals stabil bekommen wenn ihr nicht gegen die wirklichen Server testet?
Es wird ja gegen wirkliche Server getestet, nur hat eben nicht jeder Entwickler Zugriff auf jeden möglicherweise betroffenen Server.
Gut, wenn wir mal automatische Tests wegen des enormen Aufwands außen vor lassen, dann bräuchte es halt trotzdem noch Jemanden, der sich über Serveradministration als Contributor beteiligen möchte, und sich die Zeit nimmt, einen Server aufzusetzen und abszusichern, permanent laufende virtuelle Maschinen einzurichten und über VPN zugänglich machen, an alle interessierten Entwickler VPN und Groupware Zugänge auszugeben und sich auch bereiterklären, das Ding am Laufen zu halten.
Ich bin mir sicher, dass die Hostingkosten dann nicht das Problem sind.
Daher auch meine konfrontationelle Replik am Anfang des Threads. Wenn so getan wird als würden fähige Sysadmins reihenweise Schlange stehen um endlich so einen Server aufbauen und betreiben zu dürften, dann wäre das schon passiert.
Und wie gesagt wäre man dann noch sehr weit von Infrastruktur entfernt, die automatisierte Tests in diesem Bereich möglich machen würde.
Da gebe ich dir völlig Recht. Ich wollte nur darauf hinweisen, dass das bei mangeldem Speicher/Plattenplatz auch mit einem einzelnen, einfachen Server möglich wäre.
Die VMs sind aber ganz klar die besser Lösung, zumal es die für nahezu alle freien Groupware Lösungen bereits fertig gibt. Für Zarafa z.B. hier: http://www.zarafa.com/wiki/index.php/Zarafa_VMware_virtual_appliance
Der obige Bug wäre mit einem trivialen Integrationstest sofort aufgefallen und erfordert auch keine besondere Testsituation:
1. Item anlegen
2. Sync => FAIL
Noch einfacher geht's nicht.
Festplattenplatz wird benötigt, aber eine parallele Ausführung der VMs ist nicht nötig. Die Tests können sequentiell abgearbeitet werden und brauchen dann halt etwas länger. Die Testcases müssen ja nicht unbedingt bei jedem Commit laufen.
Wenn die Tests bereits existieren, dann ist die Hürde der Infrastruktur nur umso unverständlicher. Für 600 Euro im Jahr bekommt man bei einem Billighoster wie Hetzner eine Maschine, die weit mehr als ausreichend ist. Darauf könnte man einen Großteil des Testinfrastruktur des KDE Projekts laufen lassen.
Wenn der KDE e.V. keine 600 Euro im Jahr für einen Testserver aufbringen kann, dann ist es in der Tat Zeit für einen Spendenaufruf. Diese 600 Euro dürftet ihr in wenigen Minuten zusammen haben. Ich würde mich ebenfalls beteiligen.
Als Außenstehender hat man natürlich immer leicht reden, aber jetzt mal ernsthaft: Wie wollt ihr KDEPIM jemals stabil bekommen wenn ihr nicht gegen die wirklichen Server testet? Das ist doch ein Ding der Unmöglichkeit. Ich denke da wird jeder, der schon mal größere Softwareprojekte entwickelt hat uneingeschränkt zustimmen. Insofern sollte doch ein Testserver absolut oberstes Gebot sein. So lange der KDE e.V. Geld für Kongresse usw. hat, so lange ist es einfach nicht glaubwürdig, dass es für eine Testinfrastruktur nicht mehr reicht.
Klar, für manuelle Tests ginge das. Aber es ging um automatisierte Tests.
In diesem Fall muss sicher gestellt sein, dass erstens eine bekannte Ausgangssiituation besteht und zweitens kein anderer Test zur selben Zeit den Zustand ändert.
Letzteres ist auch bei einem manuellen Test notwendig.
Gut zu wissen, das wäre schon mal ein Ansatz für entsprechende Testimages.
Das ist ein relativ naiver "hoffen das alles passt" Ansatz, keine aussagekräftige Teststellung.
Für einen echten Test, dessen Fehlschlagen das Auftreten eines Fehlers erkennen lässt, muss sicher gestellt sein, dass die Aufgabe ansich durchführbar ist.
D.h. der Benutzer und das entsprechende Passwort müssen existieren, nicht das vielleicht ein anderer Test gerade das Passwortändern oder das Accountlöschen getestet hat.
Das Quota des Benutzers muss OK sein, der Zielordner muss exisitieren und die am Ordner vorhandene Rechte müssen das Hinzufügen erlauben, der Ordner darf nicht schon einen Eintrag mit der selben Identifikation oder ähnliches beinhalten, während des Test darf nichts anderes den Eintrag löschen, verändern, oder ähnliches mit dem Ordner machen.
Jeder, der schon mal automatisierte Tests erstellt hat, weiß, dass der aufwendige Teil nicht der Test ist, sondern das Herstellen und Absichern der Testsituation.
Ohne Gewissheit, dass alle für den Test notwendigen Vorraussetzungen gegeben sind, ist das Fehlschlagen des Test keine ausreichende Indikation für einen Fehler der getesteten Funktionalität. Selbst ein Testerfolg lässt keine Schlussfolge auf das korrekte Funktionieren zu.
Der Test hat damit seine Aufgabe verloren!
Auch das ist leichter gesagt als getan
Derzeit können verschieden Projekte von einander unabhängig gebaut und getestet werden, d.h. für den Build sind nur die jeweiligen Abhängigkeiten relevant.
Für eine singuläre Instanz müssten alle Projekte hintereinander gebaut werden, ein Fehlschlag während des Bauens darf nicht zum Abbruch des Durchlaufs führen.
Alle gemeinsamen Abhängigkeiten müssen von allen Projekten in der selben Version benutzt werden können. D.h. KDE PIM müsste gegen kdepimlibs und kdelibs stable gebaut werden können, wenn andere davon abhängig Projekte nicht wegen einem Fehler in den jeweiligen Masterzweigen behindert werden sollen.
D.h. Tests für Erweiterungen oder Fixes über Modulgrenzen sind nicht möglich oder riskieren eine "Nullrunde" für alle.
Collateral Damage
Infrastruktur ist leider nicht nur die Hardware. Dieser Rechner muss gewartet und überwacht werden, die Enwickler brauchen Tools um Teststellungen zu erzeugen und zu registieren (damit sie in Teste referenziert werden können), Tools um diese Teststellungen zu aktualiseren, usw.
Ich behaupte nicht, dass es nicht möglich wäre, aber es ist wesentlich aufwendiger als man vielleicht meinen könnte, wenn man sich nicht mit den anfallenden Details beschäftigt.
Es wird ja gegen wirkliche Server getestet, nur hat eben nicht jeder Entwickler Zugriff auf jeden möglicherweise betroffenen Server.
Gut, wenn wir mal automatische Tests wegen des enormen Aufwands außen vor lassen, dann bräuchte es halt trotzdem noch Jemanden, der sich über Serveradministration als Contributor beteiligen möchte, und sich die Zeit nimmt, einen Server aufzusetzen und abszusichern, permanent laufende virtuelle Maschinen einzurichten und über VPN zugänglich machen, an alle interessierten Entwickler VPN und Groupware Zugänge auszugeben und sich auch bereiterklären, das Ding am Laufen zu halten.
Ich bin mir sicher, dass die Hostingkosten dann nicht das Problem sind.
Daher auch meine konfrontationelle Replik am Anfang des Threads. Wenn so getan wird als würden fähige Sysadmins reihenweise Schlange stehen um endlich so einen Server aufbauen und betreiben zu dürften, dann wäre das schon passiert.
Und wie gesagt wäre man dann noch sehr weit von Infrastruktur entfernt, die automatisierte Tests in diesem Bereich möglich machen würde.