Ich versuche mich gerade an einem Projekt nach den Regeln der TDD vorzugehen (soweit ich diese aus dem Buch “Clean Code” kenne).
Man soll ja nichts in den Produktcode schreiben, das nicht vorher in einem Test fehlschlug. Gilt da nun auch für ein Enum, dass jede Ausprägung im Test auftauchen muss? Und dass, falls zu jedem Enum-Wert noch ein paar Variablen gehören, deren Werte auch alle in einem Test auftauchen müssen?
Oder reicht da das exemplarische Abfragen einiger Werte?
ach herje, vielleicht nicht auf alles gemünzt,
was soll man auch bei einer statischen Variable int = 100 testen, ob sie == 100 ist?
‘TDD enum’ als Suche liefert aber u. a. diese beiden Seiten
unit testing - How to test enum types? - Stack Overflow
Let’s talk about Java: This powerful Enum - part 2
auch wenn vielleicht selbst zu finden, vielleicht schon gefunden, und lahm immer nur auf altes zu zeigen,
wäre es doch recht sinnlos, ohne diese Grundlagen nochmal ähnlich einfache Punkte/ Möglichkeiten zu wiederholen,
also gehören sie hier auch gepostet
der Enum entsteht doch aufgrund einer anderen Tatsache, bzw anderen Code der gerade entwickelt wird.
Ein simples enum per TDD zu erstellen halte ich für unsinnig. TDD beschreibt nicht, dass man klassenweise seine Tests/produktionscode erstellt.
Ausserdem geht es bei TDD auch nicht darum alle möglichen Kombinationen zu testen, sondern eben die, welche gerade vorgegeben wird.
Weiterhin ist teil von TDD das Refactoring. Das kann geschehen, ohne dass vorher ein Test fehlschlägt.
Es kommt darauf an, wie das enum Eingesetzt wird.
Wenn es tatsächlich nur als “Konstantensammlung” verwendet wird, muss es für jede dieser Konstanten einen Test geben, der deren Wirkung auf den auswertenden Code testet (also nicht das enum selbst). Konstanten die von keinem Test verwendet werden können ja der Theorie nach gar nicht im Programm auftreten…```@Test
public void testMethod__withStateNew__returnsWhatShouldBeReturnedOnNew(){
TheTestedObject tto = new TheTestedObject();
String returnedString = tto.method(MyEnum.NEW);
assertEquals(“what ever should be returned on new”,returnedString);
}
@Test
public void testMethod__withStateOwned__returnsWhatShouldBeReturnedOnOwned(){
TheTestedObject tto = new TheTestedObject();
String returnedString = tto.method(MyEnum.OWNED);
assertEquals(“what ever should be returned on owned”,returnedString);
}```
Generell ist aber von dieser Verwendung abzuraten, weil die große Gefahr besteht, dass man in seiner Anwendung switches verteilt, die auf diesem enum arbeiten.
Aber enums können ja viel mehr, zum Beispiel Methodenaufrufe delegieren:```@Test
public void testEnumNew__withVisitor__callsHandleNewOnVisitor(){
MyVisitorInterface mvi = mock(MyVisitorInterface.class);
MyEnum.NEW.handle(mvi);
verify(mvi).callMeWhenNew();
}
@Test
public void testEnumOwned__withVisitor__callsHandleOwnedOnVisitor(){
MyVisitorInterface mvi = mock(MyVisitorInterface.class);
MyEnum.OWNED.handle(mvi);
verify(mvi).callMeWhenOwned();
}```
das enum sähe dann so aus:```enum MyEnum{
NEW{
public void handle(MyVisitorInterface mvi){
mvi.callMeWhenNew();
}
},
OWNED{
public void handle(MyVisitorInterface mvi){
mvi.callMeWhenOwned();
}
};
public abstact void handle(MyVisitorInterface mvi);
}```
bye
TT
Danke euch. Gesucht hatte ich danach erstaunlicher Weise nicht, warum auch immer ich nicht auf die Idee kam, daher danke für die Links, da schaue ich gleich mal rein.
Genau deshalb meine Frage. Wenn ich sie in den Produktionscode schreibe, dann deshalb, weil vorher ein Test fehlschlug. Daher muss auch die Konstante im Test auftauchen, und daher muss ich sie definieren, denke ich.
Dass Enums ziemlich mächtig sind, weiß und nutze ich ebenfalls. Ich habe ebenfalls schon Enums mit überschriebenen Methoden verwendet, das ist eine ziemlich praktische Sache.
[quote=Crian]Wenn ich sie in den Produktionscode schreibe, dann deshalb, weil vorher ein Test fehlschlug. Daher muss auch die Konstante im Test auftauchen, und daher muss ich sie definieren, denke ich.[/quote]Ich denke: wenn der Zusammenhang zwischen Test, der die Konstante forderert und der Konstanten selbst nicht offensichtlich ist, dass hast Du keinen Unittest, weil der “zu viel” testet, bzw nicht unabhängig genug ist.
bye
TT