swe, Softwarekonstruktion
Modul swe
Modul swe
-
- 1 / 82
-
Cartes-fiches
Methoden einer Unit Testklasse (5 Punkte)
- Test Methoden keine Argumente entgegen, keine return Wete. Testmethode = void
- sollte komplett unabhängig von jeder anderen Testmethode sein
- jede Testmethode testet einzelne Methode der CUT
- Deklaration:
@Test
pubilc void testY(){...}
Vorbereitung von Tests (@Before)
- Methode, welche vor jeder Testmethode aufgerufen wird
- garantiert, dass jede Testmethode mit genau den gleichen Voraussetzungen startet
- setup-methode muss public und mit @before markiert sein
- deklaration:
@Before
public void setUp(){...}
Aufräumen nach dem Testen (@After)
- nach jeder Testmethode muss eine tear-down-Methode aufgerufen werden
- tear-down-Methode räumt die Unordnung während dem Test auf
- durch tear-down-Methode, wird das Resultat jeder Testmethode aufgeräumt
- tear-down-Methode = public & mit @After
- Deklaration:
@After
public void teardown(){...}
Assertion
Definition
assertions werden während jeder Testmethode dazugebraucht, aktuelle gegenüber erwarteten Resultaten zu testen.
assert-Methoden haben entweder Status fail oder pass.
Assertions
Was sind:
- assertEquals
- assertSame
- assertNull
- fail()
assertEquals(<Type> expected, <Type> actual)
- vergleicht primitive Typen durch deren Value
- vergleicht Klassen mit dem Aufruf von equals
- Overloaded mit allen primitiven Typen, Objekten und Strings
Assertions
Was sind:
- assertEquals
- assertSame
- assertNull
- fail()
assertSame(Object expected, Object actual)
- vergleicht Referenzen mit dem ==-Operator
Assertions
Was sind:
- assertEquals
- assertSame
- assertNull
- fail()
- assertNull(Object x), assertTrue(boolean b)
Assertions
Was sind:
- assertEquals
- assertSame
- assertNull
- fail()
leer
- Testen von Exceptions, wenn nur eine exception erwartet wird
- Falls mehrere Exceptions erwartet werden
- @Test(expected=IlligalArgumentException.class)
- siehe Code
Vorgehen des JUnit Frameworks (4 Punkte)
- lokalisieren aller Methoden, welche mit @BeforeClass, @AfterClass @Before, @After oder @Test markiert sind. Verifikation, dass diese public void sind oder keine Argumente enthalten
- danach werden alle Methoden aufgerufen, welche mit @BeforeClass markiert sind (statisch)
- Für jede Methode markiert mit @Test
- falls mit @Ignoer markiert, -->Methode wird ignoriert
- Aufruf aller Methoden mit @Before
- Aufruf Testmethode
- Aufruf aller Methoden mit @After
- Aufruf aller Methoden markiert mit @AfterClass (statisch)
Organisation der Tests
Tests von produktivem Code trennen
Unit Testing Practices
Was sind gute Tests A-TRIP
- Automatic
- Thorough (Code coverage)
- Repeatable
- Independent
- Professional
Unit Testing Practices
Was soll getestet werden?
alles was scheitern kann!
- setters/getters nicht, scheitern nie
- setters/getters implizit getestet
- mit code coverage kann man die test coverage überprüfen
Unit Testing Practices
Wie viel soll getestet werden?
soviel, dass System nicht abbricht, wenn es von Usern benutzt wird. Wähle minimales Set an Daten, um maximale Test Coverage zu erreichen
Äquivalenzklassen
Definition:
Ziel
Wähle geeignete Untermenge an Inputs, damit grosser Teil von anderen möglichen Tests abgedckt wird. Input Domain wird in mehrere Regionen aufgeteilt, in denen das gleiche Verhalten erwartet wird.
Ziel: Anzahl an Testklassen zu minimieren. Idee dass pro Äquivalenzklasse nur ein Test Case benötigt wird. Da das gesamte Input-Set auf dem selben Verhalten beruht, kann jeder mögliche Wert die ganze Klasse repräsentieren.
Jeder Wert kann Fehler aufdecken!
Boundary Value Analysis
(5 Punkte)
- Bestimme Boundary Values
- Teste um diese gewählten Werte herum
- Ziel: off-by-one Fehler entdecken
- um zu testen wählt man den Boundary Value um die ein darunter und darüber
- Boundary Value Analyis ergänzt / kann in Verbindung mit Äquivalenz-Partitionierung gebraucht werden
RIGHT-BICEP
RIGHT
B
I
C
E
P
RIGHT: sind alle Resultate richtig
B: sind alle Boudary konditionen richtig
I: kann man inverse Beziehung testen
C: Cross-check
E: Kann man Error-Conditionen zwingen aufzutreten?
P: Ist die Performance charakteristisch
Boundary Condition:
CORRECT
C: Conformance
O: Order
R: Range
R: Refference
E: Existence
C: Cardinality
T: Time
Boundary Condition
C: Conformance
O: Order
R: Range
R: Refference
E: Existence
C: Cardinality
T: Time
entspricht der Wert einem erwarteten Resultat
Boundary Condition
C: Conformance
O: Order
R: Range
R: Refference
E: Existence
C: Cardinality
T: Time
Ist das Set der Werte geeignet geordnet oder ungeordnet
Boundary Condition
C: Conformance
O: Order
R: Range
R: Refference
E: Existence
C: Cardinality
T: Time
Ist der Wert in einem akzeptierbaren Rahmen
Boundary Condition
C: Conformance
O: Order
R: Range
R: Refference
E: Existence
C: Cardinality
T: Time
Tut die Code Referenz etwas, was nicht direkt unter Kontrolle ist
Boundary Condition
C: Conformance
O: Order
R: Range
R: Refference
E: Existence
C: Cardinality
T: Time
Existiert die Value
Boundary Condition
C: Conformance
O: Order
R: Range
R: Refference
E: Existence
C: Cardinality
T: Time
Ist das Resultat die erwartete Anzahl an Werten
Boundary Condition
C: Conformance
O: Order
R: Range
R: Refference
E: Existence
C: Cardinality
T: Time
Geschieht alles in der richtigen Reihenfolge, zur Richtigen Zeit
Test First (Test-Driven Development)
Prinzip
zuerst Test Code schreiben, dann produktiven Code
Test First
Ziel: (5 Punkte)
- Interface der Methoden definieren
- Test Code anhand Methoden-Anforderungen schreiben
- so viel wie möglich implementieren, damit Tests gelingen
- Impementationen stoppen
- Implementation refactoren
Test First
Vorteile
- Sicherheitsnetzt
- Minimale Implementation
- Testbarer Code
- getestete Software
Metrics
Definition
= ein Massstab und eine Methode um den Wert eines Indikators einer bestimmten SW zu bestimmen.
Ein Indikator = interne Charakteristik, welche an externe Charakteristik angelehnt werden kann.
z.B.: External characteristic: Analyzibility
Indicator: complexity of functions / methods
Metric: McCable's cyclomatic number
Metrics
Statische Software Metrics (6 Metrics)
- Size Metrics
- Dataflow Metrics
- Style Metrics
- OO Metrics
- Coupling Metrics
- Statistic Metrics
Metrics (statische Software Metrics)
- Size Metrics
- Dataflow Metrics
- Style Metrics
- OO Metrics
- Coupling Metrics
- Statistic Metrics
Lines of code, number of statements,fields methods packages
Metrics (statische Software Metrics)
- Size Metrics
- Dataflow Metrics
- Style Metrics
- OO Metrics
- Coupling Metrics
- Statistic Metrics
cyclomatic complexity, dead code detection, initalization before use
Metrics (statische Software Metrics)
- Size Metrics
- Dataflow Metrics
- Style Metrics
- OO Metrics
- Coupling Metrics
- Statistic Metrics
number of levels, naming conventions, formation conventions
Metrics (statische Software Metrics)
- Size Metrics
- Dataflow Metrics
- Style Metrics
- OO Metrics
- Coupling Metrics
- Statistic Metrics
number of classes, packages, methods
Metrics (statische Software Metrics)
- Size Metrics
- Dataflow Metrics
- Style Metrics
- OO Metrics
- Coupling Metrics
- Statistic Metrics
lack of cohesion metrics, number of calling classes, number of called classes
Metrics (statische Software Metrics)
- Size Metrics
- Dataflow Metrics
- Style Metrics
- OO Metrics
- Coupling Metrics
- Statistic Metrics
instability, abstractness
Metrics (dynamische Metrics)
2 Metrics
- Performance Metrics
- Other
Metrics (dynamische Metrics)
- Performance Metrics
- Other
Time spent, network traffic, number of clicks to perform a task
Metrics (dynamische Metrics)
- Performance Metrics
- Other
number of test executes, number of failed tests, code coverage
Cyclomatic Complexity (McCable)
Definition
2 Punkte
Definition:
Anzahl möglicher Ausrtittsmöglichkeiten im Code
- für einzelne Methode ist Cyclomatic number N definiert als: N=b+1. b ist Anzahl an binären Entscheidungspunkten (if, while, for, case)
- Switch-Statements blasen cyclomatic number auf
