Am 01.07.2015 um 08:00 schrieb Thomas Güttler:
Vermutlich gibt es die Möglichkeit eine eigene Methode vor dem Test aufzurufen. Zu Not in setUp() deiner TestCase Klasse.
Für Paketinstallations/Setupaufgaben gibt es bei Travis in der .travis.yml den 'before_install'-Abschnitt.
Also ich denke nicht das aus diesem Grund Travis nicht geeignet ist. [...] Ich vermute, dass kein freier Hoster dir das Laden von Kernelmodulen erlaubt.
Die beiden Sätze widersprechen sich etwas, meinst du nicht? Wie schon gesagt und durch den Link in den Bugtracker belegt, kann man in den OpenVZ-Umgebungen von Travis generell keine Kernelmodule laden, da bei dieser Virtualisierungslösung der Kernel des Hostsystems gemeinsam benutzt wird. Siehe dazu auch den Error-Log eines Builds: https://travis-ci.org/SpotlightKid/python-rtmidi/jobs/68403100
Oder den Kernel-Bereich per mock Bibliothek nur vorgaukeln.
Das bringt in diesem Fall leider nicht viel, da es sich bei python-rtmidi um Python-Bindings für eine C++-Bibliothek handelt. Die Tests sollen beweisen, dass der Aufruf der Methoden der C++-Klassen aus Python/Cython heraus, funkioniert und diese korrekt mit dem OS MIDI-Framework interagieren. Wenn ich die gewrappte C++-Bibliothek durch ein Mock ersetzen wollte, müsste das ganze Cython-Modul umgeschrieben werden und hätte dann nicht mehr viel mit dem Production-Code zu tun. Der Einsatzzweck der Bibliothek ist Discovery von MIDI-Schnittstellen und MIDI I/O über diese. Wenn ich diese nicht teste, habe ich durch die Tests wenig gewonnen.
Aus akademischer Sichtweise ist das Testen der Zusammenarbeit zwischen Bibliothek und Kernel ein Integrationstest, kein Unittest.
Ich habe auch nicht behauptet, dass ich nur Unittests machen will, schließlich heißt es ja auch Continuous *Integration*. Gruß, Chris