From: Steve F. <st...@m3...> - 2003-04-18 08:41:03
|
First the simple bit. Assuming you're using the same statement object, you can just add another result set to be returned. I'm not quite sure what you're unhappy about with the test. Could you post an example of the sort of test you want to write? The short answer is that this sort of testing tends to push you towards writing smaller, more focussed classes and methods which some of us believe is a Good Thing. S. James Howe wrote: > I'm just starting to experiment with using MockObjects to test classes > which access a database. I have some simple methods which I've been > able to test, but now I'm trying to test some more complicated methods. > In particular I'm testing a method which uses another method to get a > result which is then input into a second query. It looks something like > this (a rough approximation of the algorithm): > > public double value() { > int count = fullCount(); // this method peforms a count(*) type of > query > String query = "blah blah blah limit " + (count * .30); > mockResults = mockStatement.executeQuery(query); > if (mockResults.next()) > return mockResults.getDouble(1); > return Double.NaN; > } > > The problem is testing this method. I'm doing two different queries so > I need to get two different result sets. I'm sure I can come up with > some way to handle this, but I'm wondering if there is a general pattern > for handling this sort of thing? What bothers me is that in order to > test my "value" method, I also have to know how to set up the > environment to support methods that the method might call, and so on > down the line. Is there a better way to organize my database code which > might avoid this problem? > > Thanks. > > -- "A LISP programmer knows the value of everything but the cost of nothing. A C programmer knows the cost of everything but the value of nothing." (Todd Proebsting) |