[Django] Beginner-Fragen bezüglich Implem. eines Test-Tools

[Knöpkenböller]

Moin,

meine Frage, die ich hier stellen möchte ist von etwas umfangreicherer Natur. Ich habe ein Projekt umzusetzten,
dass sich in seiner Komplexität etwas meinen bisher beschränkten Django-Fähigkeiten entzieht und möchte
von daher einmal von erfahrenen Django-Usern Rat und Räte einholen. Unter Umständen ist der eine oder andere
mit Django-Funktionen vertraut, die ich nicht kenne und die ggf. etwas Arbeit abnehmen. Denn alles zu Fuss
zu machen zu wollen liegt dem Beginner, dann ja doch oftmals ob der weniger tiefen Kenntnis des Rahmenwerks
nahe. Ich wende mich an dieses Forum, da mir hier auf der Arbeit die Ansprechpartner fehlen. Ich würde gerne
meinen Ansatz vorstellen und gerne Verbesserungsvorschläge annehmen, bzw. Stellen wo der ein oder andere
Stolperfallen sieht.

Desweiteren möchte ich dieses Projekt verwenden, um mir die Testgetriebene-Entwicklung anzueignen, welche
ich vorher nie verwndet habe.

#Das Projekt:
Es ist ein Online-Tool zu entwicklen mit dem "Tests" druchgeführt. Das lasse ich erstmal so schwamig, da das
tatsächliche Fachgebiet keine Rolle spielt. Ein "Test" wird an Hand einer Reihe von "Testfragen" durchgeführt.
Diese "Testfragen" sollen editierbar sein, bzw. sollen neue Versionen des Testschemas erstellt werden können,
ohne das die alten "Tests" inkonsistent werden. Es gibt "Tester" bzw. "Prüfer" oder einfach "User", die die
"Tests" durchführen. Einem "Test" können hierbei mehrere "Tester" zugeordnet werden, á la Erst-, Zweit- und
Dritt-Prüfer. Einer "Test"-Instanz sind "Items" zugeorndet, die der tatsächliche Testgegenstand sind und anhand
derer die jeweiligen "Testfragen" von den "Testern" beantwortet werden. Bevor ein "Test" beendet ist bzw.
als abgeschlossen veröffentlich wird, sollen die "Tester" über die "Testfragen" abstimmen können, die sie
unterschiedlich bewertet haben. Das Ergenis eines "Tests" errechnet sich aus Punktwerten, die durch die
beanworteten Fragen ergeben. Die Antwortmöglichkeiten bzgl. einer Testfrage ist immer eine Untermenge einer
globalen Menge von Antwortmöglichkeiten. (zB. global: [ja, eher ja, eher nein, nein, nicht anwendbar],
frage1: [ja, nein], frage2: [ja, nein, nicht anwendbar], frag3: [ja, eher ja, eher nein, nein, nicht anwendbar], etc.)


#Mein Ansatz:
Letzteres mit der Abstimmung ist der Bereich, der mir die meisten Knoten ins Hirn macht. Meine Models sehen
bisher wie folgt aus:

Testschema:
- hat eine Versionsnummer oder ähnliches, damit sich einzelne Testfragen einem übergordnetem
Schema zuordnen lassen

Testfrage:
- kennt das Schema, zu dem es gehört
- die Frage an sich
- Menge der Antwortmöglichkeiten
- seine Gewichtung bzgl. des Endergebnisses

Testitem:
- sein Beschreibung

Test:
- das Testschema, welches ihm zu Grunde liegt
- Auftraggeber
- die Prüfer, welche ihn durchführen (der Erstprüfer ist speziell zu kennzeichnen)
- kennt seine Testitems
- boolesche Flags: abgeschlossen, veröffentlich
- Anmerkungen
- Ergebnis

Bewertung:
- Testzugehörigkeit
- Prüfer
- Testitem
- Testfrage
- Bewertung bzw. Antwort als Punktwert

Abstimmung:
- Testzugehörigkeit
- Testfrage
- zwischen welchen beiden Prüfern
- Anmerkung

Als "Tester"-Modell hatte ich erstmal Django's eigenes "User"-Modell angenommen, da dies alle Felder mitbringt,
die ich brauche (Name, Vorname, eMail).

#Meine Fragen:
So wie ich das TTD (test-driven development) bzgl. Django verstanden habe, werden zuerst die Modells festgelegt
und dann für diese Tests geschrieben. Anschliessend werden Tests für die Views geschrieben, die dann erst implementiert
werden. Wo würdet ihr in den Entwicklungszyklus das Erstellen von Templates einbauen?

Ich tue mich damit schwer mir konzeptionell Tests für Views auszudenken. TTD will irgendwie nicht in meinen Kopf rein.

Eigentlich wäre es ja schöner, bzw. praktischer, wenn man anstatt eines Bewertungs-Modells einfach ein Dictionary in einem
Feld des Tests ablegen könnte, in welchem steht welcher Tester, welche Frage wie beantwortet hat. Aber ich denke, dass ich
einsehe, dass es witzlos wäre Dinge als String in eine Datenbank zu schreiben und sie somit nicht mehr der Konsistenz-
prüfung einer Datenbank zu überlassen.

Vom Ding her sehe ich das ganze eigentlich als eine Django-App. Oder gäbe es hier sinnvolle Möglichkeiten es in mehrere
Apps zu zerlegen. Ich habe mal gehört, dass man erst einmal pauschal davon ausgehen kann, dass Dinge, die über vers.
Urls angesprochen werden auch konzeptionell vers. Apps sind?!

Gewisse Testfragen haben eine gewisse Auswahl an Anwortmöglichkeiten. Ich frage mich, wie ich am besten dafür sorge,
dass der User auch nur diese Auswahl zu sehen bekommt. Die eine Möglichkeit ist serverseitig ein Dictionary oder ähnliches
zusammen zubasteln, dass jeweils Listen mit den Antwortmöglichkeiten zusammenstellt. Die andere Möglichkeit ist abhängig
von der Frage im Template eine Drop-Down-Box zu befüllen. Die letzte Mögliochkeit, die mir einfällt, ist Javascript, wovon
ich aber ersteinmal gerne die Finger lassen würde.

Fallen jemandem spontan bereits veröffentlichte Apps ein, die gewünschte Funktionalität teilweise auffangen oder vielleicht
"abgucken" lassen. Für die Veröffentlichung von Tests habe ich schon an Blog-Apps gedacht, da sie das erstellen, editieren
und veröffenltichen von Einträgen abbilden. Für die Abtimmungen sind mir Polls eingefallen, aber ich denke, dass die
Anwendung hier zu spezifisch ist, als dass man eine generische Poll-App verwenden könnte?


Ich freue mich über jeden kleinen Tipp und Ratschlag. Ich weiss auch, dass nicht alles aufeinmal oder überhaupt nach dem Motto
"so musst du das machen und nicht anders" zu beantworten ist.
Danke vielmals schon einmal und beste Grüße

[ms4py]

TDD braucht leider seine Zeit bis das flüssig von der Hand geht, da muss man sich einfach "hineindenken". Tu mir da manchmal auch recht schwer.

Zu deinen Models:
Jedes Model mit nur einem Feld ist IMO überflüssig und kann auch gleich in das zugehörige Model (Test-Item und Schema). (Oder sind das 1:n Beziehungen? Dann ist dein Modell etwas unklar, beschreibe dann auch mal die Beziehungen oder mach gleich ein Diagramm/ERM)

Außerdem finde ich den Ansatz einer Poll-App grundsätzlich richtig (und wird auch vom offiziellen Tutorial bereitgestellt). Die Antworten musst du nämlich schon in einem eigenen Model speichern. (Eine "Menge" musst du in einem Datenmodell immer Auslagern)

[Knöpkenböller]

TDD braucht leider seine Zeit bis das flüssig von der Hand geht, da muss man sich einfach "hineindenken". Tu mir da manchmal auch recht schwer.

Zu deinen Models:
Jedes Model mit nur einem Feld ist IMO überflüssig und kann auch gleich in das zugehörige Model (Test-Item und Schema). (Oder sind das 1:n Beziehungen? Dann ist dein Modell etwas unklar, beschreibe dann auch mal die Beziehungen oder mach gleich ein Diagramm/ERM)

Außerdem finde ich den Ansatz einer Poll-App grundsätzlich richtig (und wird auch vom offiziellen Tutorial bereitgestellt). Die Antworten musst du nämlich schon in einem eigenen Model speichern. (Eine "Menge" musst du in einem Datenmodell immer Auslagern)

Ja, es handelt sich um eine 1:n-Beziehung. Ich habe mal eine graphische-Visualisierung mit django-extensions erzeugt.


Eine Poll-App erscheint mir aber dennoch nicht ganz passend, da es sich im Endeffekt ja weder um eine Abstimmung als um einen Abgleich zwischen Ergebnissen handelt, der manuell durchegführt wird. Angenommen wir haben Frage 3 unterscheidlich beantwortet, dann sollte kurz vor Testabschluss irgendwo Frage3 auftauchen mit der Aufforderung die "Abstimmung durchzuführen" oder ähnliches. Dort kann ich dann sehen, wie andere Prüfer bewertet haben und evtl. meine Antowrt anpassen oder eine Anmerkung hinterlassen, um die anderen Prüfer zur Rücknahme zu bewegen.