Direkt zum InhaltDirekt zur Navigation

Code Qualität

Automatische Tests

Screenshot eines CI-Testservers

Die Module müssen mit automatischen Software-Tests versehen werden. Die automatischen Tests müssen alle wichtigen Bereiche eines Moduls abdecken. Je nach Situation werden verschiedene Arten von Tests (Unittests, Integrationstests, funktionale Tests etc.) eingesetzt.

Die automatischen Tests werden durch einen Continuous Integration Server bei jeder Änderung durchgeführt. Zusätzlich zu den Tests werden weitere Analysen durchgeführt:

  • Pyflakes: Dieses Tool führt eine statische Code-Analyse durch und meldet nicht verwendete Variablen oder unnötige Imports und führt weitere einfache Überprüfungen durch. Dies sind einfache Überprüfungen, die normalerweise keine Fehler werfen dürfen.
  • Pep8: Das Tool pep8 überprüft, ob die gleichnamige PEP8-Konvention eingehalten wird. Die Konvention definiert den verwendeten Coding-Stil - vom Code Layout bis zur Benennung von Komponenten. Da Zope sich nicht in allen Punkten an PEP8 hält und die lokale Konsistenz wichtig ist, ist es nicht möglich, im Plone Umfeld PEP8 komplett einzuhalten. Daher wird von den OneGov Modulen erwartet, dass minimale Regeln (z.B. maximale Zeilenlänge von 79 Zeichen) eingehalten werden. Folgende pep8 Konfiguration sollte verwendet werden: https://github.com/4teamwork/ftw-buildouts/blob/master/pep8.cfg
  • Pylint: Pylint ist ein Tool das statische Code-Analysen durchführt. Auch hier können gewisse Regeln aus technischen Gründen nicht eingehalten werden. Die Module sollen sich so gut wie möglich an diese Regeln halten, jedoch haben auch hier Regeln von Zope und Plone Vorrang. Grundsätzlich soll folgende pylint-Konfiguration verwendet werden: https://github.com/4teamwork/ftw-buildouts/blob/master/pylintrc

Jedes einzelne Modul soll über eine Buildout-Konfiguration verfügen, die eine Testumgebung für dieses Modul installieren kann. Es wird empfohlen, folgende Buildouts als Grundlage zu verwenden: https://github.com/4teamwork/ftw-buildouts. Dies ermöglicht eine automatische Installation und Konfiguration in einem Jenkins Continuous Integration Server.

Upgrades

Die Module müssen einen Migrationspfad über alle Versionen anbieten. Dieser muss vorhanden sein, sobald eine neue Version des Moduls veröffentlicht wird.

Die Upgrades sollen nach den Plone-Standards in portal_setup registriert werden und alle notwendigen Arbeiten durchführen.

Die Versionsnummer im metadata.xml ist so zu pflegen, dass portal_setup die nötigen Änderungen automatisch erkennt.

Dokumentation

Jedes Modul muss mindestens über ein README verfügen, das alle wichtigen Komponenten des Moduls beschreibt. Die Standardsprache für README Dateien ist Englisch, damit auch internationale Entwickler und Anbieter das Modul verwenden können.

Bei Änderungen an der Funktionsweise des Codes eines Moduls (neu Features, Bug Fixes, etc) soll ein Changelog innerhalb des Moduls nachgeführt werden. Dort soll ersichtlich sein, wer welche Änderung in welcher Version des Moduls gemacht hat.

Metadaten

Die Metadaten der Module werden in einer setup.py Datei im Wurzelverzeichnis des Moduls angegeben. Die Metadaten sollen gepflegt und aktualisiert werden. Insbesondere soll auf folgende Punkte geachtet werden:

  • Die Classifier im setup.py sind richtig gesetzt (Plone inkl. Version etc)
  • Alle Dependencies sind im setup.py korrekt angegeben, die Dependencies sind nicht gepinnt (höchstens mit Ranges, wie "x<3.0", nie mit "x=2.5")
  • z3c.autoinclude wird verwendet
  • Die im setup.py eingetragene URL soll auf das github Code-Repository zeigen.
    • Der Maintainer soll im setup.py eingetragen sein.