Loading ...
Sorry, an error occurred while loading the content.

Re: [junit] Re: Is Reflection The best way of accessing private member variables and methods?

Expand Messages
  • Gabriele Kahlout
    On Mon, Apr 4, 2011 at 10:51 AM, Joakim Ohlrogge ... neither do i ... same here..and because i look for the highest value from my tests/coding I try to
    Message 1 of 13 , Apr 4, 2011
    • 0 Attachment
      On Mon, Apr 4, 2011 at 10:51 AM, Joakim Ohlrogge

      > 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.
      > agreed

      > Perhaps when I feel that I do something "just for testing" it is a good
      > idea
      > 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
      > later.
      > 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.
      neither do 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
      > quite
      > 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
      same here..and because i look for the highest value from my tests/coding I
      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
      > programmer.
      > If the point was lots of coverage and exercise every single method as a
      > unit
      > 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
      > overrated
      > :)
      > 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
      > in
      > what I wrote then it would be "don't follow the rules, go after the
      > effects"
      I'd summarize my point with: "lazyness is a virtue" [1] "except for the
      compiler", but I'd also be wrong!

      [1] http://projectlombok.org/features/index.html

      > /J
      > -----------------------------------------------------
      > Joakim Ohlrogge
      > Twitter: @johlrogge
      > Blog: johlrogge.wordpress.com
      > [Non-text portions of this message have been removed]

      K. Gabriele

      --- 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]
    Your message has been successfully submitted and would be delivered to recipients shortly.