Re: [junit] Re: Is Reflection The best way of accessing private member variables and methods?
- View SourceOn Mon, Apr 4, 2011 at 10:51 AM, Joakim Ohlrogge
>neither do i
> The argument: "I don't like the idea of changing production code just for
> testing" would not rub me the wrong way if the changes generally introduced
> for testing would not have other benefits as well (hence, the changes are
> not just for testing at all). It would also not rub me the wrong way if it
> was not he case that code that is written in a TDD manner turns out to be
> testable pretty much by definition.
> Perhaps when I feel that I do something "just for testing" it is a good
> for me to reflect upon if there is some way that I can achieve the
> testability with other benefits as well. Perhaps now is not a good time to
> reflect so I write a note to myself to get back to the problem and reflect
> agreed.. //FIXME is an IDE-supported 'comment tag'
> The whole testing private methods discussion would never rub me the wrong
> way either if I didn't feel that we chose to resort to technical voodoo in
> order to avoid changing how we generally approach problems and IMO are more
> or less guaranteed to miss out on an oportunity to learn.
> The "its not agile" argument always rubs me the wrong way because it's
> pointless. Frankly I don't care about being agile unless it works better
> than something else I would be doing.
>same here..and because i look for the highest value from my tests/coding I
> I do the things I do because I know no better way of doing them right now.
> If I could do less testing I would, since having lots of tests is also
> pointless in itself. It is the effects of having them that I am after. Or
> seemingly it is the effect of writing them that I am after. I write lots of
> tests because I know no better way of ensuring that my code has quality and
try to integration/higher-level/emperical test as much as possible. However
there I sometimes need access to private methods to get the testing
environment/parameters i need.
> of driving me to reflect daily about design that helps me improve as a+1.
> If the point was lots of coverage and exercise every single method as a
> I would probably make all methods public... but it's not...
> By the way, I have come to find that the private keyword is pretty
> Sorry for the rant... I just need to do that at least once every year :)
> Anyone is free to disagree and it may very well be because they are smarter
> or better programmers than I am. If there is anything worth reflecting on
> what I wrote then it would be "don't follow the rules, go after the
I'd summarize my point with: "lazyness is a virtue"  "except for the
compiler", but I'd also be wrong!
> Joakim Ohlrogge
> Twitter: @johlrogge
> Blog: johlrogge.wordpress.com
> [Non-text portions of this message have been removed]
--- unchanged since 20/9/10 ---
P.S. If the subject contains "[LON]" or the addressee acknowledges the
receipt within 48 hours then I don't resend the email.
subject(this) ∈ L(LON*) ∨ ∃x. (x ∈ MyInbox ∧ Acknowledges(x, this) ∧ time(x)
< Now + 48h) ⇒ ¬resend(I, this).
If an email is sent by a sender that is not a trusted contact or the email
does not contain a valid code then the email is not received. A valid code
starts with a hyphen and ends with "X".
∀x. x ∈ MyInbox ⇒ from(x) ∈ MySafeSenderList ∨ (∃y. y ∈ subject(x) ∧ y ∈
[Non-text portions of this message have been removed]