Best Practises - Versionsgeschichte

Eschlenker am 13. März 2019 um 12:17 Uhr

2019-03-13T12:17:22Z

Eschlenker am 13. März 2019 um 12:16 Uhr

2019-03-13T12:16:56Z

Eschlenker am 13. März 2019 um 12:15 Uhr

2019-03-13T12:15:47Z

Eschlenker am 13. März 2019 um 12:10 Uhr

2019-03-13T12:10:01Z

Eschlenker am 13. März 2019 um 12:09 Uhr

2019-03-13T12:09:27Z

Eschlenker am 13. März 2019 um 10:44 Uhr

2019-03-13T10:44:33Z

Eschlenker: Die Seite wurde neu angelegt: „===Architecture Commitee=== ===Quality Commitee=== ====Quality Rules and Guidelines==== =====File system conventions===== Es muss durch das AC festgelegt we…“

2019-03-13T10:30:05Z

Die Seite wurde neu angelegt: „===Architecture Commitee=== ===Quality Commitee=== ====Quality Rules and Guidelines==== =====File system conventions===== Es muss durch das AC festgelegt we…“

Neue Seite

===Architecture Commitee===

===Quality Commitee===

====Quality Rules and Guidelines====

=====File system conventions=====
Es muss durch das AC festgelegt werden, ob eine maximale relative Pfadlänge definiert werden sollte, da unter Windows einige Programme (inkl. git) Probleme mit einer absoluten Pfadlänge > 256 Zeichen haben. Dies kann notwendig sein, da die zu erstellende Software auch auf älteren Systemen lauffähig sein muss. Zumindest sollte dieser Punkt im Rahmen zukünftiger Beauftragungen dediziert im jeweiligen Projektkontext betrachtet und ggf. auf Grundlage der Beauftragung bewertet werden.

=====Unit Tests & Code Coverage=====
Unit-Tests oder Komponententests werden verwendet um die funktionalen Einzelteile (Units) von Computerprogrammen zu testen, d. h. sie auf korrekte Funktionalität zu prüfen. Da Algorithmen auf Unit-Ebene meist nur eine begrenzte Komplexität aufweisen und über klar definierte Schnittstellen aktiviert werden, können sie mit relativ wenigen Testfällen weitgehend vollständig getestet werden. Dies gilt als Voraussetzung für die anschließende Teststufe „Integrationstest“. Dort werden die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausgerichtet. Damit lassen sich die modulspezifischen Detailkonstellationen auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle drastisch reduziert.

Im Rahmen der Best Practices werden zur Durchführung von Unit-Tests entwicklungsspezifische Werkzeuge wie z.B. „JUnit“ empfohlen. Die damit generierten Testfälle sind selbst überprüfend und damit wiederholbar. Eine gute Test-Unit zeichnet sich dadurch aus, dass sie möglichst wenige Abhängigkeiten zum Rest des Systems hat und damit für sich genommen gut und einfach testbar ist. Zum Test komplexerer Zusammenhänge sollte zusätzlich ein Mocking-Framework wie z.B. „Mockito“ zur Abbildung weiterer Abhängigkeiten außerhalb des eigentlichen Unit-Kontextes verwendet werden. Ein derartiges Mocking-Framework bietet dem Entwickler die Möglichkeit, das Verhalten des zu testenden Systems verifizieren können, ohne im Vorfeld Annahmen treffen zu müssen. Nebenwirkungen von anderen Klassen und/oder Systemen werden weitestgehend eliminiert und die oft kritisierte enge Kopplung von Unit-Tests an den getesteten Code reduziert. Für die Überprüfung der Code Coverage wird basierend auf den bestehenden Erfahrungen im Java-Umfeld aktuell „JaCoCo“ empfohlen. „JaCoCo“ ist ein Open-Source-Toolkit, mit dem die Qualität des Java-Codes bewertet und das Ergebnis publiziert werden kann. „JaCoCo“ wird unter den Bedingungen der „Eclipse Public License“ vertrieben und kann zudem in SonarQube eingebunden werden.

''Statement Coverage – Anweisungsabdeckung''
Die „Statement Coverage“ entspricht den beim Test durchlaufenden Anweisungen im Verhältnis zu allen Anweisungen. Beispiele für Anweisungen wären Wertezuweisungen bei Variablen, Fallunterscheidungen, Schleifen und Methodenaufrufe.

''Branch Coverage – Zweigabdeckung''
Ein stärkerer Abdeckungsgrad ist die „Branch Coverage“. Sie entspricht dem Verhältnis der beim Test durchlaufenen Zweige (auch Kanten genannt).

''Condition Coverage – Bedingungsabdeckung''
Die „Branch Coverage“ unterscheidet nicht, aufgrund welche Teilbedingungen eine Bedingung als wahr oder falsch ausgewertet wird. Dies erreicht die „Condition Coverage“. Man unterscheidet dabei zwischen der Einfach- und der Mehrfachbedingungsabdeckung.

''Loop Coverage – Schleifenabdeckung''

''Path Coverage – Pfadabdeckung''

← Nächstältere Version		Version vom 13. März 2019, 12:17 Uhr
Zeile 1:		Zeile 1:
	zurück zur [[Hauptseite]]		zurück zur [[Hauptseite]]
−
−	~~== Architecture Commitee ==~~
−
−	~~== Quality Commitee ==~~
−

	==Quality Rules and Guidelines==		==Quality Rules and Guidelines==

@@ Zeile 19: / Zeile 19: @@
 „JaCoCo“ ist ein Open-Source-Toolkit, mit dem die Qualität des Java-Codes bewertet und das Ergebnis publiziert werden kann. „JaCoCo“ wird unter den Bedingungen der „Eclipse Public License“ vertrieben und kann zudem in SonarQube eingebunden werden.
-* '''Statement Coverage – Anweisungsabdeckung'''
+====Statement Coverage – Anweisungsabdeckung====
 Die „Statement Coverage“ entspricht den beim Test durchlaufenden Anweisungen im Verhältnis zu allen Anweisungen. Beispiele für Anweisungen wären Wertezuweisungen bei Variablen, Fallunterscheidungen, Schleifen und Methodenaufrufe.
-* '''Branch Coverage – Zweigabdeckung'''
+====Branch Coverage – Zweigabdeckung====
 Ein stärkerer Abdeckungsgrad ist die „Branch Coverage“. Sie entspricht dem Verhältnis der beim Test durchlaufenen Zweige (auch Kanten genannt).
-* '''Condition Coverage – Bedingungsabdeckung'''
+====Condition Coverage – Bedingungsabdeckung====
 Die „Branch Coverage“ unterscheidet nicht, aufgrund welche Teilbedingungen eine Bedingung als wahr oder falsch ausgewertet wird. Dies erreicht die „Condition Coverage“. Man unterscheidet dabei zwischen der Einfach- und der Mehrfachbedingungsabdeckung.
-* '''Loop Coverage – Schleifenabdeckung'''
+====Loop Coverage – Schleifenabdeckung====
-* '''Path Coverage – Pfadabdeckung'''
+====Path Coverage – Pfadabdeckung====

@@ Zeile 1: / Zeile 1: @@
 zurück zur [[Hauptseite]]
-==Architecture Commitee==
+== Architecture Commitee ==
@@ Zeile 12: / Zeile 11: @@
 Es muss durch das AC festgelegt werden, ob eine maximale relative Pfadlänge definiert werden sollte, da unter Windows einige Programme (inkl. git) Probleme mit einer absoluten Pfadlänge > 256 Zeichen haben. Dies kann notwendig sein, da die zu erstellende Software auch auf älteren Systemen lauffähig sein muss. Zumindest sollte dieser Punkt im Rahmen zukünftiger Beauftragungen dediziert im jeweiligen Projektkontext betrachtet und ggf. auf Grundlage der Beauftragung bewertet werden.
-===Unit Tests & Code Coverage===
+===Unit Tests===
 Unit-Tests oder Komponententests werden verwendet um die funktionalen Einzelteile (Units) von Computerprogrammen zu testen, d. h. sie auf korrekte Funktionalität zu prüfen. Da Algorithmen auf Unit-Ebene meist nur eine begrenzte Komplexität aufweisen und über klar definierte Schnittstellen aktiviert werden, können sie mit relativ wenigen Testfällen weitgehend vollständig getestet werden. Dies gilt als Voraussetzung für die anschließende Teststufe „Integrationstest“. Dort werden die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausgerichtet. Damit lassen sich die modulspezifischen Detailkonstellationen auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle drastisch reduziert.
-Im Rahmen der Best Practices werden zur Durchführung von Unit-Tests entwicklungsspezifische Werkzeuge wie z.B. „JUnit“ empfohlen. Die damit generierten Testfälle sind selbst überprüfend und damit wiederholbar. Eine gute Test-Unit zeichnet sich dadurch aus, dass sie möglichst wenige Abhängigkeiten zum Rest des Systems hat und damit für sich genommen gut und einfach testbar ist. Zum Test komplexerer Zusammenhänge sollte zusätzlich ein Mocking-Framework wie z.B.  „Mockito“ zur Abbildung weiterer Abhängigkeiten außerhalb des eigentlichen Unit-Kontextes verwendet werden. Ein derartiges Mocking-Framework bietet dem Entwickler die Möglichkeit, das Verhalten des zu testenden Systems verifizieren können, ohne im Vorfeld Annahmen treffen zu müssen. Nebenwirkungen von anderen Klassen und/oder Systemen werden weitestgehend eliminiert und die oft kritisierte enge Kopplung von Unit-Tests an den getesteten Code reduziert. Für die Überprüfung der Code Coverage wird basierend auf den bestehenden Erfahrungen im Java-Umfeld aktuell „JaCoCo“ empfohlen. „JaCoCo“ ist ein Open-Source-Toolkit, mit dem die Qualität des Java-Codes bewertet und das Ergebnis publiziert werden kann. „JaCoCo“ wird unter den Bedingungen der „Eclipse Public License“ vertrieben und kann zudem in SonarQube eingebunden werden.
+Im Rahmen der Best Practices werden zur Durchführung von Unit-Tests entwicklungsspezifische Werkzeuge wie z.B. „JUnit“ empfohlen. Die damit generierten Testfälle sind selbst überprüfend und damit wiederholbar. Eine gute Test-Unit zeichnet sich dadurch aus, dass sie möglichst wenige Abhängigkeiten zum Rest des Systems hat und damit für sich genommen gut und einfach testbar ist. Zum Test komplexerer Zusammenhänge sollte zusätzlich ein Mocking-Framework wie z.B.  „Mockito“ zur Abbildung weiterer Abhängigkeiten außerhalb des eigentlichen Unit-Kontextes verwendet werden. Ein derartiges Mocking-Framework bietet dem Entwickler die Möglichkeit, das Verhalten des zu testenden Systems verifizieren können, ohne im Vorfeld Annahmen treffen zu müssen. Nebenwirkungen von anderen Klassen und/oder Systemen werden weitestgehend eliminiert und die oft kritisierte enge Kopplung von Unit-Tests an den getesteten Code reduziert. Für die Überprüfung der Code Coverage wird basierend auf den bestehenden Erfahrungen im Java-Umfeld aktuell „JaCoCo“ empfohlen.
-== Statement Coverage – Anweisungsabdeckung ==
+* '''Statement Coverage – Anweisungsabdeckung'''
 Die „Statement Coverage“ entspricht den beim Test durchlaufenden Anweisungen im Verhältnis zu allen Anweisungen. Beispiele für Anweisungen wären Wertezuweisungen bei Variablen, Fallunterscheidungen, Schleifen und Methodenaufrufe.
-== Branch Coverage – Zweigabdeckung ==
+* '''Branch Coverage – Zweigabdeckung'''
 Ein stärkerer Abdeckungsgrad ist die „Branch Coverage“. Sie entspricht dem Verhältnis der beim Test durchlaufenen Zweige (auch Kanten genannt).
-== Condition Coverage – Bedingungsabdeckung ==
+* '''Condition Coverage – Bedingungsabdeckung'''
 Die „Branch Coverage“ unterscheidet nicht, aufgrund welche Teilbedingungen eine Bedingung als wahr oder falsch ausgewertet wird. Dies erreicht die „Condition Coverage“. Man unterscheidet dabei zwischen der Einfach- und der Mehrfachbedingungsabdeckung.
-== Loop Coverage – Schleifenabdeckung ==
+* '''Loop Coverage – Schleifenabdeckung'''
-== Path Coverage – Pfadabdeckung ==
+* '''Path Coverage – Pfadabdeckung'''

← Nächstältere Version		Version vom 13. März 2019, 10:44 Uhr
Zeile 1:		Zeile 1:
		+	zurück zur [[Hauptseite]]
		+
	===Architecture Commitee===		===Architecture Commitee===

@@ Zeile 6: / Zeile 6: @@
-====File system conventions====
+==Quality Rules and Guidelines==
 Es muss durch das AC festgelegt werden, ob eine maximale relative Pfadlänge definiert werden sollte, da unter Windows einige Programme (inkl. git) Probleme mit einer absoluten Pfadlänge > 256 Zeichen haben. Dies kann notwendig sein, da die zu erstellende Software auch auf älteren Systemen lauffähig sein muss. Zumindest sollte dieser Punkt im Rahmen zukünftiger Beauftragungen dediziert im jeweiligen Projektkontext betrachtet und ggf. auf Grundlage der Beauftragung bewertet werden.
-====Unit Tests & Code Coverage====
+===Unit Tests & Code Coverage===
 Unit-Tests oder Komponententests werden verwendet um die funktionalen Einzelteile (Units) von Computerprogrammen zu testen, d. h. sie auf korrekte Funktionalität zu prüfen. Da Algorithmen auf Unit-Ebene meist nur eine begrenzte Komplexität aufweisen und über klar definierte Schnittstellen aktiviert werden, können sie mit relativ wenigen Testfällen weitgehend vollständig getestet werden. Dies gilt als Voraussetzung für die anschließende Teststufe „Integrationstest“. Dort werden die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausgerichtet. Damit lassen sich die modulspezifischen Detailkonstellationen auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle drastisch reduziert.