getter und setter testen
-
Dortmunder schrieb:
Getter und Setter werden eigentlich nie getestet - denn welche Implementierung soll da überhaupt getestet werden? Eben, es gibt keine. Also macht auch ein Test keinen Sinn ;).
Sinn von getter und setter nicht verstanden.
-
Den Sinn von Settern werde ich wohl auch nie verstehen.
-
MBreuer schrieb:
kann mir jemand helfen, eine Strategie vorschlagen wie ich getter und setter teste ?
Ich würde mir als erstes überlegen, wie man sowas generisch lösen kann, sodass man nicht für jede zu testende Funktion eine oder sogar mehrere Testfunktionen schreiben muss. Ich weiss nicht genau, wie deine Tests aussehen, aber ich denke an sowas:
#define TEST_SETTER_GETTER(object, attribute, value) \ { \ (object).Set##attribute(value); \ if ((object).Get##attribute() != value) \ throw TestFailure(/* ... */); \ } int main() { Produkt p; TEST_SETTER_GETTER(p, Preis, 3.95); }Ad aCTa schrieb:
Den Sinn von Settern werde ich wohl auch nie verstehen.
Was verstehst du daran nicht?
-
Nexus schrieb:
MBreuer schrieb:
kann mir jemand helfen, eine Strategie vorschlagen wie ich getter und setter teste ?
Ich würde mir als erstes überlegen, wie man sowas generisch lösen kann, sodass man nicht für jede zu testende Funktion eine oder sogar mehrere Testfunktionen schreiben muss. Ich weiss nicht genau, wie deine Tests aussehen, aber ich denke an sowas:
#define TEST_SETTER_GETTER(object, attribute, value) \ { \ (object).Set##attribute(value); \ if ((object).Get##attribute() != value) \ throw TestFailure(/* ... */); \ } int main() { Produkt p; TEST_SETTER_GETTER(p, Preis, 3.95); }Ad aCTa schrieb:
Den Sinn von Settern werde ich wohl auch nie verstehen.
Was verstehst du daran nicht?
setter werden eigentlich nur dazu benutzt um Zuweisungswerte zu begrenzen. Dies wird hier überhaupt nicht getestet.
-
Janjan schrieb:
setter werden eigentlich nur dazu benutzt um Zuweisungswerte zu begrenzen. Dies wird hier überhaupt nicht getestet.
Für sowas benutzt man aber eher
assert()auf Seiten der Implementierung. Oder was meinst du?Zudem war das Makro nur als Anregung gedacht. Wie gesagt kenne ich den genauen Kontext zu wenig.
-
Ich finde, dass man von außen überhaupt nicht auf irgendwelche Membervariablen über direkte Setter zugreifen sollte. Sie beschreiben einen Zustand des Objekts, der durch bestimmte Memberfunktionen beeinflusst werden kann, aber nicht selbst geändert werden sollte. Macht man nun Setter bricht das doch eh die Kapselung enorm.
-
Ad aCTa schrieb:
Ich finde, dass man von außen überhaupt nicht auf irgendwelche Membervariablen über direkte Setter zugreifen sollte. Sie beschreiben einen Zustand des Objekts, der durch bestimmte Memberfunktionen beeinflusst werden kann, aber nicht selbst geändert werden sollte. Macht man nun Setter bricht das doch eh die Kapselung enorm.
Du darfst Setter nicht mit direktem Zugriff auf eine Membervariable gleichsetzen. Die Abstraktion ist ja der grosse Vorteil von Setter-/Getterfunktionen und erlaubt es zum Beispiel, die Implementierung bei gleichbleibender Schnittstelle zu wechseln. Natürlich gibt es Situationen, in denen z.B. nur Getter oder gar keine Zugriffsmethoden sinnvoll sind. Aber diese Fälle kann man nicht verallgemeinern.
Was machst du zum Beispiel hier?
Button b; if (/* wir wollen eine rote Schaltfläche */) b.SetColor(Color::Red); // arbeite mit b
-
Janjan schrieb:
Dortmunder schrieb:
Getter und Setter werden eigentlich nie getestet - denn welche Implementierung soll da überhaupt getestet werden? Eben, es gibt keine. Also macht auch ein Test keinen Sinn ;).
Sinn von getter und setter nicht verstanden.
Immer diese Gäste mit ihren Minimalkommentaren. Dann erklär uns doch bitte den Sinn. Vielleicht lernt dann der ein oder andere noch etwas.
-
/** setzen des Dateinamens *@param name der Dateiname */ void Data::setFilename(char* name){ // filename interner buffer // BUFFERSIZE größe des internen Buffers strncpy_s(filename,BUFFERSIZE,name,strlen(name)); } /** holen des Dateinamens *@return der Dateiname */ char* Data::getFilename(){ return filename; } //-------------------------------------- /** setzen des Dateinamens */ void Test::setFilename(){ char* name = "test1"; Data data; data.setFilename(name); ASSERT_EQUAL("setFilename", name, data.getFilename()); }; /** holen des Dateinamens */ void Test::getFilename(){ char* name = "test2"; Data data; data.setFilename(name); ASSERT_EQUAL("getFilename", name, data.getFilename()); }wenn ich jetzt "test1" durch einen namen ersetze der länger ist als der Buffer sollte die Funktion fehlschlagen, das Problem ist beim Setter.
Eigentlich gehören Getter und Setter zusammen, nur muss ich nicht unbedingt bekommen was ich eingegeben habe.
Die beiden Testfunktionen sind im grunde identisch also redundant.
Ich könnte auch folgendes machen./** setzen/holen des Dateinamens */ void Test::setGetFilename(){ char* name = "test1"; Data data; data.setFilename(name); ASSERT_EQUAL("setGetFilename", name, data.getFilename()); }; /** setzen des Dateinamens */ void Test::setFilename(){ Test::setGetFilename(); }; /** holen des Dateinamens */ void Test::getFilename(){ Test::setGetFilename(); }
-
MBreuer schrieb:
Die beiden Testfunktionen sind im grunde identisch also redundant.
Dann lass eine davon weg!
-
Fryi schrieb:
Janjan schrieb:
Dortmunder schrieb:
Getter und Setter werden eigentlich nie getestet - denn welche Implementierung soll da überhaupt getestet werden? Eben, es gibt keine. Also macht auch ein Test keinen Sinn ;).
Sinn von getter und setter nicht verstanden.
Immer diese Gäste mit ihren Minimalkommentaren. Dann erklär uns doch bitte den Sinn. Vielleicht lernt dann der ein oder andere noch etwas.
Um den Zugriff zu begrenzen, gültige Werte zu limitieren oder generell zu erfahren wann ein Zugriff getätigt wird. Sonst kann man die Variable gleich public machen.