[OpenSlides users-de] OpenSlides 1.5 Code-Sprint-Meeting

[René Köcher]

Hi Oskar,

Am 27.07.13 11:14 schrieb "Oskar Hahn" unter <mail at oshahn.de>:

>Hi René,
>
>die aktuelle Situation zur Testbarkeit von OpenSlides ist die, dass wir
>momentan ein coverage von 66% mit unittests haben. Tendenz steigend.
>Diese testen wir auch jetzt schon vor jedem Pullrequest mit travis.[1]
Super, das hatte mir Emanuel auch schon kurz angerissen :)

>
>Außerdem besteht der Plan noch eine Testsuit mit Selenium[2][3]
>aufzubauen.[4]
Dafür würde sich aus meiner Sicht splinter auch anbieten[1]. Es ist für
genau
solche Interaktionstests gedacht und abstrahiert eine API auf Basis von
z.b. Selenium.

>Am 26.07.2013 10:29, schrieb René Köcher:
>> Ich hätte als Beitrag die Integration von Lettuce[1] + Splinter[2][3]
>>als BDD[4]-Test-Suites zu bieten.
>Diese Pakete waren mir neu. Ich finde es klingt interessant.
>
>Bitte korrigiere mich wenn ich falsch liege, aber wenn wir tatsächlich
>100% unittests und Selenium-Tests haben, gibt es keinen Mehrgewinn aus
>Lettuce und Splinter. Möglicherweise verstehe ich aber den Unterschied
>noch nicht richtig.
Wenn du 100% coverage hast dann ist es generell egal mit welcher
Test-Suite, also: ja, kein Mehrgewinn.

Mein Gedankengang war eher das Testen bzw. Schreiben dieser Tests für die
Zukunft robuster und
Konsistenter zu gestalten. Wie du schon feststellst haben wir aktuell etwa
66% coverage - die aber
Auch nur, weil sich mal jemand hingesetzt hat um sich die Tests
auszudenken und (wohl meist nach der
Implementation der zu testenden Klassen) geschrieben hat.

An dieser Stelle kommt Behaviour-Driven-Development und damit Lettuce bzw.
der von Lettuce angebotene
Dialekt "Cucumber" zum Einsatz. Generell wird dann der Ablauf einfach
umgekrempelt:

- 1. es gibt eine Anforderung (z.B. Eine Login-Seite)
- 2. die Anforderung wird in Cucumber/Lettuce als Testfall aufgeschrieben
- 3. die Tests werden ausgeführt
- 4. fehlgeschlagene Testcases werden repariert / implementiert
- 5. die Tests werden erneut ausgeführt

Bei jeder Änderung / Neuentwicklung werden die Schritte von 3. an
ausgeführt.
(Bei neuen Anforderungen von 1. / 2. An)

Der Gedanke hier ist ganz simpel: schreib auf was der Code tun soll und
implementiere ihn dann.
Damit stellst du automatisch auch die Testcoverage sicher. Wenn du beim
Umsetzen der Tests merkst, dass
Du zusätzliche Methoden / Features implementieren musst, dann durchläufst
du ebenfalls die Schritte 1-5
Und hast somit gerade auch gleich das gewünschte Verhalten + die nötigen
Tests implementiert.

Mal als Beispiel für einen Cucumber-Testcase (ohne Step-Definitionen, die
sind aber nicht komplex
Und noch dazu zu fast 100% zwischen Testcases wiederverwendbar):

---------------------------------------------------------------------------
-

Feature: users can logout of their accounts

	In order to protect my privacy
	As a User
	I want to be able to logout when I'm done using OpenSlides

	Scenario: User want's to logout
		Given I am a registered User
		And I am successfully logged in
		When I press the button labeled "logout"
		Then I should be redirected to the login page
		And I should no longer be logged in
	
---------------------------------------------------------------------------
-


Das Ganze ist also zum einen für jeden mit ein wenig Enlisch-Kenntnissen
lesbar
und zusätzlich auch mit einer kurzen Erklärung der Grammatik für nicht
Programmierer
Nutzbar.

Cucumber / Lettuce testen hierbei die Abläufe / Nutzungsszenarien.
Detail-Implementationen von einzelnen Methoden einer Klasse können über
normale Unittests abgewickelt
Oder aber z.B. Auch durch Kits wie RSpec (für python dürfte das nose
sein..) umsetzen.

>
>Meinst du, du wirst beim nächsten Code-Sprint-Meeting dabei sein können,
>und kannst uns da genauer über diese Tests aufklären?

Ich hätte zumindest Lust und Anfang September auch Zeit
(schau mal in den Doodle den Emanuel erstellt hat).

>
>Gruß Oskar
Gruß,
René