Brauche dringend Hilfe bei Python-Übung

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Raffael1001
User
Beiträge: 2
Registriert: Sonntag 19. Februar 2012, 17:58

Erstellen Sie die Benutzerdokumentation und die technische Dokumentation für ein Programm.
Nutzen Sie dazu argparse, doctest und pydoc.

Das Programm ist ein Datumsrechner.

So lautet meine Aufgabe. Wir sollen nur eine Benutzerdokumentation, sowie die Testfälle schreiben das Programm selbst mit den Methoden noch nicht. "Testgetriebenes Entwickeln" nennt sich das, glaube ich. Unser Lehrer hat uns dahingehend einfach diese Aufgabe vorgelegt, ohne das wir vorher etwas ansatzweise ähnliches gemacht haben, somit bin ich, sowie der Rest der Klasse, ein bisschen unaufgeklärt :K , was die Aufgabenbewältigung betrifft. Unten stehend ist der Code, den ich bis zum jetzigen Zeitpunkt schreiben konnte, das ging aber auch nur mit der Hilfe von Angaben aus einem Schuldokument. Das sollte soweit die Benutzerdokumentation sein. Nur wie ich jetzt dazu die Testfälle schreiben soll, weiß ich echt wenig. Darum bitte ich euch Forenmitglieder, mir ein paar Anhaltspunkte oder Tipps zu geben. Das würde nicht nur mir sondern auch dem Rest der Klasse enorm helfen.

Code: Alles auswählen

#!/usr/bin/python
# coding: UTF-8
import argparse

def Parser():
    parser = argparse.ArgumentParser(description='Der Datumsrechner bietet Funktionen wie das Addieren von Tagen, das Errechnen des zugehörigen Tages zu einem Datum, das Errechnen der Differenz zweier Daten in Tagen, ...', epilog='Ende des Textes')
    parser.add_argument('-t', '--tag', action='store_true', default=False, dest='dat', help='Errechnet zu einem Datum den jeweiligen Tag')
    parser.add_argument('-a', '--addiere', action='store_true', default=False, dest='add', help='Addiere zum gegebenen Datum eine beliebige Anzahl Tage')
    parser.add_argument('-s', '--substrahiere', action='store_true', default=False, dest='sub', help='Subtrahiere vom gegebenen Datum eine beliebige Anzahl Tage')
    parser.add_argument('-d', '--differenz', action='store_true', default=False, dest='diff', help='Errechnet Differenz zweier Daten in Tagen')
    parser.add_argument('-j', '--anzahlschaltj', action='store_true', default=False, dest='schalt', help='Errechnet Anzahl der Schaltjahre bis Angabedatum, ausgehend von 00.00.00')
    parser.add_argument('-e', '--obschaltjahr', action='store_true', default=False, dest='ifschalt', help='Gibt an ob dieses Jahr ein Schaltjahr ist')
    return parser

def Handler(args): 
    pass

parser = Parser()
print Handler(parser.parse_args())
Zuletzt geändert von Anonymous am Sonntag 19. Februar 2012, 18:14, insgesamt 1-mal geändert.
Grund: Quelltext in Python-Code-Tags gesetzt.
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

Da ihr scheinbar doctest nutzen sollt, verweise ich mal auf die Doku: http://docs.python.org/library/doctest.html

Und ja der Ansatz nennt sich Test-driven Development: https://en.wikipedia.org/wiki/Test-driven_development

Aber ohne konkrete Fragen, kann man euch nicht helfen ...
BlackJack

@Raffael1001: Die Aufgabenstellung klingt komisch und widersprüchlich. Zum schreiben der technischen Dokumentation ohne die Funktionalität braucht man kein `doctest`, denn man weiss das Ergebis ja schon: Ohne tatsächliche Implementierung werden die alle fehlschlagen. Das wäre höchstens ein Ansatz in Richtung testgetriebene Entwicklung („test driven development”, TDD). Aber IMHO ein Falscher, denn TDD bedeutet nicht, erst *alle* Tests für das Programm zu schreiben und *dann* die Funktionalität zu implementieren, sondern es wechseln sich beide Tätigkeiten ab.

Die Benutzerdokumentation ist unvollständig. Zum einen gibt es die Auslassungspunkte bei der Beschreibung. Und dann fehlt noch eine Beschreibung wie man die einzelnen Optionen verwendet. Mindestens ansatzweise sollte irgend wie beschrieben werden, mit welchen Argumenten man das Programm aufruft und in welchem Format die sein sollen/müssen.

Was macht das Programm wenn man es ohne Option aufruft? Aber mit Datum oder Daten? Sind die Optionen tatsächlich Optionen, oder sollte es nicht eher ein Argument geben, welches die Operation vorgibt? Nicht-optionale Optionen sind schliesslich ein wenig widersprüchlich. Und das die alle als Aktion 'store_true' haben ist auch komisch, denn man kann sinnvollerweise nur eine der ”Optionen” angeben. Das spricht auch wieder für ein Argument anhand dessen die Operation „dispatch”t wird. Was man in Python übrigens ganz gut mit einem Wörterbuch umsetzen kann, dass zum Beispiel Zeichenketten auf Funktionen abbildet.

Mit technischer Dokumentation dürften DocStrings gemeint sein. Solltest Du nicht wissen was das ist, dann schau danach mal in der Dokumentation von Python und speziell dann auch was das `pydoc`-Modul macht.

Das setzt voraus, dass Du Dir Gedanken darüber machst welche Funktionen in dem Programm alle benötigt werden und die zumindest mit ``pass`` als Funktionskörper implementierst und mittels DocStrings dokumentierst.

Da `doctest` vorgegeben ist, dürfte auch erwartet werden, dass in dieser Dokumentation beispielhafte Aufrufe der Funktionen und deren erwartete Ergebnisse stehen, in einer Form, die mittels `doctest` überprüft werden können.

Bezüglich der Namensgebung der Funktionen solltest Du mal einen Blick in PEP 8 -- Style Guide for Python Code werfen.

Zur ``--anzahlschaltj``-Hilfe: Das Jahr 0 gibt es nicht. Vor 1 nach Christus ist 1 vor Christus.
Raffael1001
User
Beiträge: 2
Registriert: Sonntag 19. Februar 2012, 17:58

Vorerst mal danke für eure Hilfe hätte nicht gedacht' dass das so schnell gehen würde:)
Hier ein paar konkrete Fragen:
1.) Wo in meinem bisherigen Code wäre der Testfall zu schreiben? Irgendwo dazwischen oder am Ende, ... Zum Testfall: Unser Lehrer hat uns kurz einen Einblick in ein Testporgramm gezeigt, in dem nur der Testfall steht. Was ich mich erinnern konnte ging es irgendwie um einen Webbot, dieser sollte irgendwie mit Links hantieren können. Auf jeden Fall stand in diesem Code, wie er die Methoden aufruft (sind alle noch nicht implementiert), bereits ein paar Pfade, die auch alle noch nicht existieren, anscheinend erst geschrieben werden beim Durchlauf des Prgramms. Auf jeden Fall hat er sich so etwas unter dieser Dokumentation vorgestellt, denke ich. Achja und dieses action = store true, sorgt doch dafür dass falls ich diese Methode Aufrufe der der Wert auf True gesetzt wird, falls nicht bleibt er auf false, durch Default= false, oder hab ich da was falsch verstanden?
2.) Er hatte auch etwas davon erwähnt, dass wir uns Gedanken machen sollen, wie wir diese Daten (Datum) irgendwie in Strings umwandeln können. Diese in Strings bei der Eingabe übernehmen können, da wäre auch eine Idee sehr gut, da ich nicht wirklich weiß wie ich das anstellen sollte.
3.) Wenn ich dann diese Dokumentation/ Testfall schreiben soll, wie fange ich diesen an, spezielle Begriffe, oder ganz einfach wie ein Dokument?
BlackJack

@Raffael1001: In Deinem bisherigen Quelltext ist noch kein Platz um einen Testfall zu schreiben. Wenn `doctest` dafür verwendet werden soll, dann würde ich dafür einfach eine zusätzliche externe Textdatei anlegen. Es kann sein, dass Dein Lehrer die in den DocStrings erwartet, dann musst Du erst einmal die (leeren) Funktionen schreiben, die getestet werden sollen. Wobei dort IMHO eher Aufrufbeispiele gehören, die man sinnvollerweise mittels `doctest` absichert, aber nicht unbedingt Tests die alles relevante abdecken. Die Dokumentation soll ja für den Programmierer, der das benutzen oder nachvollziehen möchte, interessant sein, und ihn nicht mit allen möglichen Sonderfällen langweilen. Es kann natürlich auch sein, dass dem Lehrer genau solche einfachen, demonstrativen Aufrufe genügen.

Oder sollt ihr neben Dokumentation auch tatsächlich Unit-Tests als normalen Code schreiben? Da wäre es dann Geschmackssache ob man die in ein eigenes Modul auslagert, oder bei einem kleinen Projekt mit in das gleiche Modul schreibt.

Das mit ``action`` hast Du richtig verstanden. Aber das ist so IMHO nicht der Weg wie man das machen sollte. So endest Du bei den sechs Operationen die das Programm kennt, bei sechs *unterschiedlichen* Attributen die alle den Wert `True` oder `False` haben können, von denen aber nur *einer* `True` sein darf. Und Du musst Code schreiben der prüft welcher Wert `True` ist, und das alle anderen auch tatsächlich `False` sind. Das ist umständlich. Besser wäre *ein* Attribut, welches zum Beispiel als Zeichenkette enthält was gemacht werden soll. Da *kann* dann nur ein Wert gesetzt sein, das „dispatch”en auf eine Funktion geht einfach über ein Wörterbuch. Ausserdem ist das IMHO wie schon gesagt keine Option, denn eine Operation *muss* man ja auswählen, also wäre das eher ein Argument.

Ad 2) Schau mal in das `datetime`-Modul was für Methoden `date` und `datetime` bieten.

Ad 3) `doctest`-Testfälle würde ich wo es nicht offensichtlich ist mit Erklärungen versehen was und warum getestet wird. Unit-Tests im Quelltext kann man so Dokumentieren wie man normalen Code auch dokumentieren würde. Ausserdem sollte man sich an die Namenskonvention halten, dass Funktionsnamen die einen Test darstellen mit dem Präfix `test` beginnen.
Antworten