Timeline for Should we test all our methods?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 19, 2012 at 21:38 | comment | added | Péter Török | -1 for "Getters/Setters are stupid - just don't use them. Instead, put your member variable to public section." - Very wrong. This has been discussed several times on SO. Using public fields everywhere is actually worse even than using getters and setters everywhere. | |
| Jan 19, 2012 at 21:33 | comment | added | Zenzen | Also, since I didn't notice it "Get common code out, and unit test it. That should be as simple as that.". What do you mean by that? It is a service class (in a service layer between the GUI and the DAO), it is common to the whole app. Can't really make it more generic (since it accepts some parameters and calls a certain method in the DAO). The only reason it is there is to adhere to the layered architecture of the application so the GUI won't call the DAO directly. | |
| Jan 19, 2012 at 21:28 | comment | added | Zenzen | Well lets get one thing straight: I didn't mean I do not use TDD/write tests. Quite the opposite. I know that tests might find bug that I didn't think about, but what is there to test here? I just simply think that such method is one of the "not unit testable" ones. As Péter Török said (quoting Kent Beck) you should test stuff that can break. What could possibly break here? Not really much (there is only a simple delegation in this method). I CAN write a unit test but it will simply have a mock of the DAO and an assert, not much testing. As for getters/setters some frameworks require them. | |
| Jan 19, 2012 at 21:22 | history | answered | BЈовић | CC BY-SA 3.0 |