Timeline for An atomic method updates dozens of properties. Am I "testing too much"?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot | Commonmark migration | |
| Jul 12, 2019 at 8:12 | comment | added | usr-local-ΕΨΗΕΛΩΝ | Initially I would say yes, BUUUUUUT, it's hard to tell which property is failed on Hamcrest's equalTo matcher. Either I would write my own custom matcher with my own custom description (lots of checks and LOCs) or write a lot of custom checks | |
| Jul 12, 2019 at 8:09 | comment | added | Bart van Ingen Schenau | Would you be happy with your testcase if you could write the verification as checkThat(form, equalTo(expectedForm))? | |
| Jul 11, 2019 at 17:11 | answer | added | Karl Bielefeldt | timeline score: 3 | |
| Jul 11, 2019 at 16:20 | comment | added | usr-local-ΕΨΗΕΛΩΝ | What should the integration test be testing? All the 100+ columns at once? The method code is not all that complex, it leverages a few for-cycles to be kept simply simple. I'm really interested in digging through this. | |
| Jul 11, 2019 at 16:04 | comment | added | Ant P | It seems as though you're testing too much in one go - break down the logic into isolated components that operate on minimal data, test each piece of the calculation independently and then just have an integration test to test that the whole thing is saved properly. | |
| Jul 11, 2019 at 15:59 | comment | added | usr-local-ΕΨΗΕΛΩΝ | Comment: I am still working since this morning on writing the full code for the first version of the testing code | |
| Jul 11, 2019 at 15:58 | history | asked | usr-local-ΕΨΗΕΛΩΝ | CC BY-SA 4.0 |