Timeline for Is it ok to assert on the behavior of return values of a testable class?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 23 at 12:09 | history | edited | Doc Brown | CC BY-SA 4.0 |
grammar fixed
|
| Sep 18 at 21:19 | comment | added | nicholaswmin | @DocBrown I'd take it easy, I didnt mean that in a condescending tone. And yes I see your point. | |
| Sep 11 at 15:41 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 641 characters in body
|
| Sep 10 at 11:10 | comment | added | Doc Brown | @SergeyZolotarev: my comments were maybe a little bit exaggerating. Still I am sure when you would ask Bob Martin himself, he would not want you to take everything he wrote in the past for granted, at least not literally. See my answer here softwareengineering.stackexchange.com/a/452939. | |
| Sep 10 at 10:01 | comment | added | Sergey Zolotarev | Btw, I don't think your "dogmatic believer" comments are fair. It's normal that I rely on decades of existing software development experience as I build my developer career with little experience of my own (yet). Whatever you think of Bob Martin and others, they have a ton of experience. It's not that they built that experience building pet projects | |
| Sep 10 at 8:01 | comment | added | Doc Brown |
@SergeyZolotarev: *that would certainly constitute design damage" - sure, in the eyes of a dogmatic believer. But when I see that an object Generator<String> was created with parameters minLength and maxLength, and the requirement is to have a generator which knows about this range and obeyes it, then providing getMinLength and getMaxLength for these kind of generators feels quite natural. Maybe Generator<String> is a supertype which does not provide such getters, then one might use the specific subtype instead which does. But as I said, if you insist on dogmatism, go with a mock.
|
|
| Sep 10 at 6:44 | comment | added | Sergey Zolotarev |
Oh, sorry, forget what I said in the last few comments. I wasn't thinking clearly. The real issue is getPasswordGenerator() returns an abstraction (Generator<String>) that doesn't have any getMinLength(), getMaxLength(), etc. (Generator<T> has only one method, T generate()). If I change that and make the method return an implementation (which does have those methods), that would certainly constitute design damage, imo
|
|
| Sep 10 at 6:03 | comment | added | Doc Brown | @SergeyZolotarev: sorry, but these comments are too terse for me, cannot follow you. If you want to follow dogmatically the "no getters" idea, the go ahead, create a mock builder instead, as I wrote in my answer, but don't be astonished when the code does not become simpler or more maintainable. | |
| Sep 10 at 5:58 | comment | added | Sergey Zolotarev | @DocBrown yes. There would be nothing to provide getters for. They are (currently) possible because the dialog has hard-coded (instead of pluggable) panels that mutate the generator builder, one of which happens to set minimum and maximum length. It's an implementation detail | |
| Sep 10 at 5:54 | comment | added | Doc Brown |
@SergeyZolotarev: sorry, but has this anything to do with changing the design of Generator<String> ?
|
|
| Sep 10 at 5:50 | comment | added | Sergey Zolotarev |
But maybe those are implementation details? I was considering refactoring the dialog so that it accepts a collection of panels implementing some Customizer<StringGenerator> interface (Customizer being a renamed Consumer). There would be panels for setting the length bounds, character categories, etc. getPasswordGenerator() would simply iterate over all of its customizing panels and let them mutate the generator builder before calling build() and returning it. In that scenario, the dialog itself doesn't store any minimums or maximums at all
|
|
| Sep 10 at 3:59 | comment | added | Doc Brown | @SergeyZolotarev: my recommendation is to take Bob Martin's writings with a grain of salt. I don't see any "design damage" when an object which requires (and remembers) certain (immutable) parameters during construction provides getters to exactly these parameters. The "don't add any getters only for testing" mantra is meant as "don't expose any implementation details of an object which could otherwise be changed later" - I don't think that's the case here. And who knows, maybe you find a use case where you need those getters in production code as well? | |
| Sep 10 at 3:44 | comment | added | Doc Brown | @nicholaswmin: sounds a lot like the very same kind of braindead dogmatic thinking. "Test induced design damage" is mostly used for situations where implementation details are unneccesarily exposed. But getters like getMinLength and getMaxLength for a self-contained generator class,which requires minLength and maxLength during construction - sorry, but for me that does not look like exposing something which needs to stay private. | |
| Sep 10 at 2:39 | comment | added | Sergey Zolotarev | Thank you. Yeah, I considered it. But then I would have to create getters that would only be used by tests. If you recall Clean Code, Bob Martin deleted everything that was used only by tests. Maybe, I misinterpreted what he did, but my takeaway was to never include any class members that are not needed in production | |
| Sep 10 at 0:16 | comment | added | nicholaswmin |
maybe because one is a dogmatic follower of the "getters are bad"-school-of-thought, for whatever reason - there's another school of thought that criticises adding code that enhances testing. I believe it's called Test Induced Design Damage in the few posts i've seen it.
|
|
| Sep 9 at 19:21 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 246 characters in body
|
| Sep 9 at 18:58 | history | answered | Doc Brown | CC BY-SA 4.0 |