Timeline for My unit test looks very similar to the class I'm testing. How do I support my stance that the test is, in fact, correct?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 30, 2017 at 15:57 | vote | accept | Christopher Francisco | ||
| Oct 31, 2016 at 11:36 | history | tweeted | twitter.com/StackSoftEng/status/793054044529057792 | ||
| Oct 26, 2016 at 18:17 | answer | added | Kevin Reid | timeline score: 4 | |
| Oct 26, 2016 at 15:36 | comment | added | gnat | edited question looks somewhat troublesome, see How do I explain ${something} to ${someone}? Note also that resource requests are explicitly off-topic per help center. Not to mention that whatever resources or arguments could there be in favor of implementation could very well evolve approach, folks willing to challenge it could counter these with YAGNI | |
| Oct 26, 2016 at 14:44 | history | edited | Christopher Francisco | CC BY-SA 3.0 |
added 716 characters in body
|
| Oct 26, 2016 at 14:35 | comment | added | Christopher Francisco |
Not a duplicate. This is not really a getter and the question is not about whether is worth it or not. The class specification is to provide a template text for a boilerplate. The implementation could very well evolve into having it read the text from a non *.php file, and, in that case, a test would have value as it would bind the specification to the functionality. The question is how to explain the fact that, even with the current implementation (the one that is just returning a string block) the test itself is correct. I'm specifically asking for resources that backup that argument.
|
|
| Oct 26, 2016 at 6:46 | comment | added | gnat | Possible duplicate of Is it worth writing a unit test for a DTO with the most basic getter/setters? | |
| Oct 26, 2016 at 6:30 | comment | added | RemcoGerlich | If these are both generated, I think the chance that the test will ever catch a genuine bug is 0%. That's a reason to delete a test. | |
| Oct 26, 2016 at 4:11 | review | Close votes | |||
| Oct 31, 2016 at 3:01 | |||||
| Oct 26, 2016 at 4:08 | answer | added | candied_orange | timeline score: 12 | |
| Oct 26, 2016 at 3:54 | comment | added | djechlin | Duplicate of a few questions similar to "should we unit test getters and setters" | |
| Oct 26, 2016 at 3:54 | comment | added | djechlin | Possible duplicate of Should we test all our methods? | |
| Oct 25, 2016 at 23:51 | comment | added | Christopher Francisco | I thought about forcing a regression bug, but given the fact that the tests I've covered so far are unit, and not integration, I don't see how to explain it to them with mere 'templates'. | |
| Oct 25, 2016 at 23:46 | comment | added | RubberDuck | I suspect you'll need a slightly more complex example to convince your peers. Something where a seemingly innocuous change would "inadvertently" make the test fail. | |
| Oct 25, 2016 at 23:39 | comment | added | Robert Harvey | You said it yourself: demonstrate that the test binds functionality to a specification. | |
| Oct 25, 2016 at 23:28 | history | asked | Christopher Francisco | CC BY-SA 3.0 |