Help save net neutrality! Learn more.
Close

#2 Must everything be private?

closed-wont-fix
nobody
None
5
2002-09-03
2002-01-21
Anonymous
No

Hi, I am using MockPreparedStatement and MockResultSet
and I need to add functionality such as addBatch() and
wasNull(), since that's what I'm trying to test. But
all the internal state of your mock objects is private
and has no accessor methods -- like myRows and
myRowOffset in MockMultiRowResultSet, or
mySetParameters in MockPreparedStatement, for
instance. If these were protected or had protected
accessor methods, making a
MockBatchingPreparedStatement subclass would be easy --
as it is, I have to essentially reimplement the whole
class, or hack your source. In general, the idea that
the whole internals of the mock objects are private
and that it throws NotImplementedExceptions whenever
the tested code wants to do something it doesn't know
about decreases its utility greatly. If you would
ignore unimplemented features rather than throwing
exceptions, then at least I could test *some* parts of
my code without having to reimplement your entire
classes. In general, the way you've written these
objects -- highly encapsulated, throwing errors the
minute something unknown is asked for -- would be
appropriate for production code, but is
innappropriately stringent for tester code (where
testing some is better than nothing), if you ask me.

Discussion

  • Steve Freeman

    Steve Freeman - 2002-03-24

    Logged In: YES
    user_id=123464

    These classes are work in progress, so they are supposed to
    be altered for purpose. Apart from the expectation library,
    the mock implementations are for convience to save you
    having to implement your own. Please feel free to hack them.

     
  • Jeff Martin

    Jeff Martin - 2002-09-03
    • status: open --> closed-wont-fix
     

Log in to post a comment.