3 ms·
I was taught that there should be tests against things like class constants so that you have a failing build in the event that someone changes a const that's pa
by remar 10y ago
I was taught that there should be tests against things like class constants so that you have a failing build in the event that someone changes a const that's part of the specification.
This was from some TDD course that my employer brought in where they emphasized that consts that are part of a specification or requirement should be tested against to prevent them from being accidentally changed or changed without full consideration of side effects/review against the program spec.
Is this what you're referring to?
- emodendroket 10y agoI guess so but I disagree with that teaching. All it does is make me change it in two places.
- nostrademons 10y agoThat's sorta the point - to make you think before you change. A constant without a test is part of the implementation, and you can refactor as necessary to make the implementation perform better. A constant with a test is part of the interface, and if you change it, client behavior has changed and the tests should change with it.
- emodendroket 10y agoYes, OK, but what I'm telling you is I think it's just as mindless. If anything, I look less at the tests when I know I'm going to break fifty of them with any real change at all. "Yeah, yeah, whatever" and copying and pasting the new values is the more likely behavior in this scenario.
- aindhaden 10y agoThis is true only for a very particular kind of constants, like the ones defining API error codes (eg. define PAGE_NOT_FOUND 404). And those should be covered by integration tests, not unit tests.