mockobjects-java-dev

[MO-java-dev] Volunteer: Ted Husted

[Ted H. <hu...@ap...>]

I would like to volunteer to work on the Code formatting and Javadoc. 
I'm a Committer to the Jakarta Struts and Commons, as well as a couple 
other Sourceforge projects. My SourceForge handle is thusted

-Ted. 

RE: [MO-java-dev] Volunteer: Ted Husted

[Vincent M. <vm...@oc...>]

Hi Ted!,

Hey, that's great! I'd love to have you join us. I'm +10000 :-)

Warning: <xp mantra>The consensus on this project is to have no javadoc
(a la XP). The belief is that the code should always be so simple as to
not require any javadoc. If it's too complex, it needs refactoring. In
addition, unit tests are provided and should act as documentation</xp
mantra>

Code formatting would be great. Actually, I need to work with Steve to
mavenize Mock Objects and thus also benefit from the checkstyle reports.

Have you been using mock objects on your projects ?

I'd like to add you right now, but I guess I need to wait for the other
project admins to have a say ...

For all: Having Ted participate to our project is a god send! He is a
very well known committer in jakarta land and has always produced
excellent work.

Thanks
-Vincent

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...] On Behalf Of
Ted
> Husted
> Sent: 23 August 2002 20:38
> To: moc...@li...
> Subject: [MO-java-dev] Volunteer: Ted Husted
> 
> I would like to volunteer to work on the Code formatting and Javadoc.
> I'm a Committer to the Jakarta Struts and Commons, as well as a couple
> other Sourceforge projects. My SourceForge handle is thusted
> 
> -Ted.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

Re: [MO-java-dev] Volunteer: Ted Husted

[Ted H. <hu...@ap...>]

Since the MockObjects Java API, by definition, has to implement many 
methods as stubs, browsing the CVS is much more difficult than it would 
be if this was a finely-tuned XP codebase. My suggestion would be that 
we (meaning I) provide JavaDocs for methods that provide functionality, 
but continue to omit them for "notImplemented()" stub methods. This will 
make it easier for *users* to zoom in on what they need to know. As is 
stands, because of all the red-tape methods, it is very hard to see the 
forest for the trees.

Respectfully, I would also suggest that XP teams do not omit JavaDocs 
because of the presumed clarity of the code. The precept is that XP runs 
on conversation and unit tests rather than on paper *and* that everyone 
will be cross-trained through pair programming. An affect of the 
combined XP team practices is that  conventional documentation tends to 
become redundant.

Since this is a public API -- and not an application being developed by 
a closely-knit team -- we can't rely on many of the XP staples, like 
real-time conversation and pair programming. I agree that it is 
redundant a nd counterproductive to document stub methods. But I do feel 
that omitting JavaDocs for implemented and additional methods will make 
the API harder *for users* to access. IMHO, dismissing JavaDocs for a 
public API is not playing to win.

Of course, I'm not asking anyone else to do anything. But I would like 
to volunteer to provide JavaDocs and package overviews for the 
implemented methods -- for the combined benefit of the thousands of 
developers who (we hope) will be using the API. I would also be happy to 
address any code-style issues as I go.

As for my own stuff: I am trying to turn over a new leaf and move to 
test-driven design. My own toolkit

- 
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/scaffold/#dirlist

does not have unit tests. When I tried to just add application-level 
unit tests for my latest project,

- http://sourceforge.net/projects/wqdata

I found the lack of mock objects for my toollkit made testing difficult. 
Since many of my classes work closely with the Java API, I then found 
that I need to use some standard Java mock objects along with my own. 
Which brings me here.

Since you were looking for help, I thought this would be a good time to 
become involved with the MockObjects project and share what I learn as I 
go.

-Ted.


Vincent Massol wrote:

>Hi Ted!,
>
>Hey, that's great! I'd love to have you join us. I'm +10000 :-)
>
>Warning: <xp mantra>The consensus on this project is to have no javadoc
>(a la XP). The belief is that the code should always be so simple as to
>not require any javadoc. If it's too complex, it needs refactoring. In
>addition, unit tests are provided and should act as documentation</xp
>mantra>
>
>Code formatting would be great. Actually, I need to work with Steve to
>mavenize Mock Objects and thus also benefit from the checkstyle reports.
>
>Have you been using mock objects on your projects ?
>
>I'd like to add you right now, but I guess I need to wait for the other
>project admins to have a say ...
>
>For all: Having Ted participate to our project is a god send! He is a
>very well known committer in jakarta land and has always produced
>excellent work.
>
>Thanks
>-Vincent
>
>>-----Original Message-----
>>From: moc...@li...
>>[mailto:moc...@li...] On Behalf Of
>>
>Ted
>
>>Husted
>>Sent: 23 August 2002 20:38
>>To: moc...@li...
>>Subject: [MO-java-dev] Volunteer: Ted Husted
>>
>>I would like to volunteer to work on the Code formatting and Javadoc.
>>I'm a Committer to the Jakarta Struts and Commons, as well as a couple
>>other Sourceforge projects. My SourceForge handle is thusted
>>
>>-Ted.
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: OSDN - Tired of that same old
>>cell phone?  Get a new here for FREE!
>>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>_______________________________________________
>>Mockobjects-java-dev mailing list
>>Moc...@li...
>>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone?  Get a new here for FREE!
>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>_______________________________________________
>Mockobjects-java-dev mailing list
>Moc...@li...
>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>

RE: [MO-java-dev] Volunteer: Ted Husted

[Vincent M. <vm...@oc...>]

I am personally +1 to everything Ted has mentioned below and I reiterate
my +1 to make Ted a committer.

Thanks
-Vincent

PS: Ted, have you had a look at Easy Mock which uses dynamic proxies to
generate mocks on the fly (needs jdk1.3+).

> -----Original Message-----
> From: Ted Husted [mailto:hu...@ap...]
> Sent: 25 August 2002 17:42
> To: Vincent Massol
> Cc: 'MockObjects'
> Subject: Re: [MO-java-dev] Volunteer: Ted Husted
> 
> Since the MockObjects Java API, by definition, has to implement many
> methods as stubs, browsing the CVS is much more difficult than it
would
> be if this was a finely-tuned XP codebase. My suggestion would be that
> we (meaning I) provide JavaDocs for methods that provide
functionality,
> but continue to omit them for "notImplemented()" stub methods. This
will
> make it easier for *users* to zoom in on what they need to know. As is
> stands, because of all the red-tape methods, it is very hard to see
the
> forest for the trees.
> 
> Respectfully, I would also suggest that XP teams do not omit JavaDocs
> because of the presumed clarity of the code. The precept is that XP
runs
> on conversation and unit tests rather than on paper *and* that
everyone
> will be cross-trained through pair programming. An affect of the
> combined XP team practices is that  conventional documentation tends
to
> become redundant.
> 
> Since this is a public API -- and not an application being developed
by
> a closely-knit team -- we can't rely on many of the XP staples, like
> real-time conversation and pair programming. I agree that it is
> redundant a nd counterproductive to document stub methods. But I do
feel
> that omitting JavaDocs for implemented and additional methods will
make
> the API harder *for users* to access. IMHO, dismissing JavaDocs for a
> public API is not playing to win.
> 
> Of course, I'm not asking anyone else to do anything. But I would like
> to volunteer to provide JavaDocs and package overviews for the
> implemented methods -- for the combined benefit of the thousands of
> developers who (we hope) will be using the API. I would also be happy
to
> address any code-style issues as I go.
> 
> As for my own stuff: I am trying to turn over a new leaf and move to
> test-driven design. My own toolkit
> 
> -
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons-
> sandbox/scaffold/#dirlist
> 
> does not have unit tests. When I tried to just add application-level
> unit tests for my latest project,
> 
> - http://sourceforge.net/projects/wqdata
> 
> I found the lack of mock objects for my toollkit made testing
difficult.
> Since many of my classes work closely with the Java API, I then found
> that I need to use some standard Java mock objects along with my own.
> Which brings me here.
> 
> Since you were looking for help, I thought this would be a good time
to
> become involved with the MockObjects project and share what I learn as
I
> go.
> 
> -Ted.
> 
> 
> Vincent Massol wrote:
> 
> >Hi Ted!,
> >
> >Hey, that's great! I'd love to have you join us. I'm +10000 :-)
> >
> >Warning: <xp mantra>The consensus on this project is to have no
javadoc
> >(a la XP). The belief is that the code should always be so simple as
to
> >not require any javadoc. If it's too complex, it needs refactoring.
In
> >addition, unit tests are provided and should act as documentation</xp
> >mantra>
> >
> >Code formatting would be great. Actually, I need to work with Steve
to
> >mavenize Mock Objects and thus also benefit from the checkstyle
reports.
> >
> >Have you been using mock objects on your projects ?
> >
> >I'd like to add you right now, but I guess I need to wait for the
other
> >project admins to have a say ...
> >
> >For all: Having Ted participate to our project is a god send! He is a
> >very well known committer in jakarta land and has always produced
> >excellent work.
> >
> >Thanks
> >-Vincent
> >
> >>-----Original Message-----
> >>From: moc...@li...
> >>[mailto:moc...@li...] On Behalf
Of
> >>
> >Ted
> >
> >>Husted
> >>Sent: 23 August 2002 20:38
> >>To: moc...@li...
> >>Subject: [MO-java-dev] Volunteer: Ted Husted
> >>
> >>I would like to volunteer to work on the Code formatting and
Javadoc.
> >>I'm a Committer to the Jakarta Struts and Commons, as well as a
couple
> >>other Sourceforge projects. My SourceForge handle is thusted
> >>
> >>-Ted.
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by: OSDN - Tired of that same old
> >>cell phone?  Get a new here for FREE!
> >>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> >>_______________________________________________
> >>Mockobjects-java-dev mailing list
> >>Moc...@li...
> >>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by: OSDN - Tired of that same old
> >cell phone?  Get a new here for FREE!
> >https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> >_______________________________________________
> >Mockobjects-java-dev mailing list
> >Moc...@li...
> >https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> 

RE: [MO-java-dev] Volunteer: Ted Husted

[Tim M. <tim...@po...>]

As I haven't actively commited any code since donating the original stuff -
I think its probably unfair for me to cast a vote - although any new blood
that is willing to put some energy into the thing is welcome.

However I am still slightly nervous by the Java Doc discussion going..

I wouldn't want to see the mock objects project go the way of the SUN
JavaDoc which is quite frankly useless!!! At the method level the doc simply
states everything that the method signature gives - what a waste of energy.
In many projects - Class docs can be useful - but again they usually are out
of date. Overall project documentation is useful - examples are even more
useful.

So maybe I'm a bit jaded - or maybe I'm just used to using good tools like
Idea, Eclipse, Visual Age that let me browse source code as documentation???
What tools do you use Ted - is this what is making you rely on java doc so
much?

Of course - even more poignantly - Mock Objects are just replicas of real
objects - so the only documentation would be the orginal docs wouldn't they?
I will agree there are classes like ExpectationList etc which aren't - so
maybe they are candidates - but they are very simple...

So Maybe - I (we?) need some examples of what java doc Ted feels needs
adding. Maybe if he doesn't mind doing some doc for a class or two and we
can have a look at it. It could be that we've missed something important
that Ted has picked up on - however I think we agree that we don't want to
do java doc just for java doc's sake right?

Tim



-----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of
Ted Husted
Sent: 25 August 2002 17:42
To: Vincent Massol
Cc: 'MockObjects'
Subject: Re: [MO-java-dev] Volunteer: Ted Husted


Since the MockObjects Java API, by definition, has to implement many
methods as stubs, browsing the CVS is much more difficult than it would
be if this was a finely-tuned XP codebase. My suggestion would be that
we (meaning I) provide JavaDocs for methods that provide functionality,
but continue to omit them for "notImplemented()" stub methods. This will
make it easier for *users* to zoom in on what they need to know. As is
stands, because of all the red-tape methods, it is very hard to see the
forest for the trees.

Respectfully, I would also suggest that XP teams do not omit JavaDocs
because of the presumed clarity of the code. The precept is that XP runs
on conversation and unit tests rather than on paper *and* that everyone
will be cross-trained through pair programming. An affect of the
combined XP team practices is that  conventional documentation tends to
become redundant.

Since this is a public API -- and not an application being developed by
a closely-knit team -- we can't rely on many of the XP staples, like
real-time conversation and pair programming. I agree that it is
redundant a nd counterproductive to document stub methods. But I do feel
that omitting JavaDocs for implemented and additional methods will make
the API harder *for users* to access. IMHO, dismissing JavaDocs for a
public API is not playing to win.

Of course, I'm not asking anyone else to do anything. But I would like
to volunteer to provide JavaDocs and package overviews for the
implemented methods -- for the combined benefit of the thousands of
developers who (we hope) will be using the API. I would also be happy to
address any code-style issues as I go.

As for my own stuff: I am trying to turn over a new leaf and move to
test-driven design. My own toolkit

-
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/scaffold/#dirlist

does not have unit tests. When I tried to just add application-level
unit tests for my latest project,

- http://sourceforge.net/projects/wqdata

I found the lack of mock objects for my toollkit made testing difficult.
Since many of my classes work closely with the Java API, I then found
that I need to use some standard Java mock objects along with my own.
Which brings me here.

Since you were looking for help, I thought this would be a good time to
become involved with the MockObjects project and share what I learn as I
go.

-Ted.


Vincent Massol wrote:

>Hi Ted!,
>
>Hey, that's great! I'd love to have you join us. I'm +10000 :-)
>
>Warning: <xp mantra>The consensus on this project is to have no javadoc
>(a la XP). The belief is that the code should always be so simple as to
>not require any javadoc. If it's too complex, it needs refactoring. In
>addition, unit tests are provided and should act as documentation</xp
>mantra>
>
>Code formatting would be great. Actually, I need to work with Steve to
>mavenize Mock Objects and thus also benefit from the checkstyle reports.
>
>Have you been using mock objects on your projects ?
>
>I'd like to add you right now, but I guess I need to wait for the other
>project admins to have a say ...
>
>For all: Having Ted participate to our project is a god send! He is a
>very well known committer in jakarta land and has always produced
>excellent work.
>
>Thanks
>-Vincent
>
>>-----Original Message-----
>>From: moc...@li...
>>[mailto:moc...@li...] On Behalf Of
>>
>Ted
>
>>Husted
>>Sent: 23 August 2002 20:38
>>To: moc...@li...
>>Subject: [MO-java-dev] Volunteer: Ted Husted
>>
>>I would like to volunteer to work on the Code formatting and Javadoc.
>>I'm a Committer to the Jakarta Struts and Commons, as well as a couple
>>other Sourceforge projects. My SourceForge handle is thusted
>>
>>-Ted.
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: OSDN - Tired of that same old
>>cell phone?  Get a new here for FREE!
>>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>_______________________________________________
>>Mockobjects-java-dev mailing list
>>Moc...@li...
>>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone?  Get a new here for FREE!
>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>_______________________________________________
>Mockobjects-java-dev mailing list
>Moc...@li...
>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Mockobjects-java-dev mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002

[MO-java-dev] javax.sql.DataSource

[Ted H. <hu...@ap...>]

In creating a mock object for a JDBC utility, I found it useful to 
implement a mock DataSource.

I didn't find one in the current API. Is this something that we would 
like to add?

-Ted.

[MO-java-dev] Defining Mock Objects

[Tim M. <tim...@po...>]

It occurred to me that it would be useful to share this message with
everyone in this group - as it fills in some history and thoughts.

Tim

------


Hi Russ -

You ask some good questions! We've been working with a few authors to
clarify some of this (Steve is in fact working on a book on the subject).

From a purist point of view I would say all 3 properties must be present.

However it might be useful to fill in some background for you - we didn't
just magically invent mock objects. Starting out with property 1, we found
we had tests with lots of "getters" on them - all doing assertEquals on some
property or another. We wanted to refactor them (to avoid duplication in our
tests) and had to choose between putting them in some test superclass or
putting them into the mock (although by our definition it was still a stub
at that point). Moving them into the mock felt cleaner (it has a more OO
feel to it, doesn't restrict you to test hierarchies and I'm not a big fan
of inheritance anyway).

So if you remove property 3, you will end up with lots of tests all having
the same assertions (in my experience anyway) and the danger that you missed
an important assertion as well. In the early days we were quite strict on
asserting every attribute - however after lots of usage we found that just
asserting on those attributes that you had set expectations on was a better
approach. If you are too strict your tests become a bit too complicated. In
this respect the much overlooked Expectation objects help you - they take
care of this policy automatically. (again this was all based on our
experience of writing lots of tests)

The previous paragraph now hints at property 2 - you need to know what to
assert on for your tests. In fact from a readability point of view -
specifying preconditions makes your test much more readable. It clearly
specifies that intent of the test. Having done this work - our experience
was that Fail fast came for free. When you are debugging your code, I would
say that fail fast is a god send - it gives you a way to imediately pop up a
debugger exactly when the problem occured - and with modern IDE's (eclipse,
visual age) you can even fix the problem and keep running. Steve often cites
an example of a financial product he was working on while we were still
discovering mock objects. They didn't have fail fast - and so had
complicated calculation tests that just had a "fail" message, with no way of
working out which of the stages of calculations had gone wrong.

Having said all of this - the Expectation objects do have a failLate flag -
which can be useful for "collection" style attributes where it can be
clearer to see the full collection of values at the end of the test (to
compare it with the expected list). I havent used this flag much - but it
did crop up once in our production code. (The topic of failing with useful
error messages is one which I covered in my XP2002 poster - A plea for
assertEquals - there are too many bad test examples out there).

I don't understand your point about "If the TestHelper isn't going to be
used repeatedly by the Class". Setting an expection on a Mock gives great
clarity. setExpectedDeleteRecord(1234) is a single interation with database
type object - but it would make a test very clear, and the failure message
would be extrememly useful. The test might bet be further enhanced with
setExpectedAddRecordCalls(0) to ensure that no adds happen in this test as
well (this is a patter I often see).

I also don't understand the point "If different tests have distinct
postconditions"? I think I may have covered this above - by setting
expectations on a mock you are effectively doing this. Actually we don't
really do postconditions in the sense you are hinting at - in that I don't
think I've written a verify that checks the state of an object to make sure
it matches a known condition. Of course you could do - and in this case to
stay general you would probably need to factor out some object to hold all
the states that you could check against (a different sort of expectation
object I guess, an ExpectationPostCondition?). However - you don't normally
need this becuase we are monitoring all the interactions coming in and can
"fail fast". Having said this - one topic we've never properly addressed is
message ordering - so an ExpectationPostCondition could be used for this
kind of thing... I quite like that now I think about it.

Hope this helps. And yes, if I was in the are, I would love to drop by. The
same applies to any of you guys if you are in London, get in touch or stop
the the ExtremeTuesdayClub and have a beer.

Tim

-----Original Message-----
From: Russ Rufer [mailto:ru...@pe...]
Sent: 23 August 2002 15:13
To: tim...@po...; st...@m3...; ph...@po...
Subject: Defining Mock Object


Hi,

I lead the Silicon Valley Patterns Group, a technical study group in
California.

We studied your Endo-Testing paper (and realted papers) over the last
two weeks, and we would really appreciate if you could help us with some
clarification.

The Endo-Testing paper never strictly defines what must be satisfied to
justify using the term Mock Object.

Crawling through the MockObject, Shunt, Stub, etc. pages on Wiki only
add to the confusion.

There seem to be three key ingredients:

(I'll use the name TestHelper to avoid conflicting with definitions I'm
trying to understand)

1: Provide an implementation of a TestHelper that your Class Under Test
   relies upon.  A simple implementation of the interface that
   contains minimal code required to interact with the Class
   Under Test for testing.

2: Fast Fail.  As soon as the Class Under Test attempts to interact
   with your TestHelper in an eroneous way, the TestHelper fails
   immediately, rather than hiding the problem until the test is
   over.

3: A verify() method on TestHelper that the test calls to check
   postconditions.

Clearly (1) is essential.  How about (2) and (3)?  Would you use the
term Mock Object if either of these were missing?

E.g. If the TestHelper isn't going to be used repeatedly by the Class
Under Test, failing fast (2) may not benefit your understanding of the
failure.

E.g. If different tests have distinct postconditions, the tests may be
simpler if you just extend the TestHelper with getters not on the
original interface.  In this case a uniform verify() method might just
be redundant--possibly empty.

Also, are there any other key elements to Mock Object that you would
want to include?

Thanks for any light you can shed on this for us.

BTW, if any of you find yourselves travelling to the Silicon Valley (or
the San Fransico Bay Area) you might enjoy joining a meeting of the
Silicon Valley Patterns Group.  Or it might just be fun to meet for
coffee or dinner while you're in the area.  If so, please feel free to
drop me a line.

- Russ Rufer
  Silicon Valley Patterns Group

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002

Re: [MO-java-dev] javax.sql.DataSource

[Jeff M. <je...@mk...>]

Yes, please send it in and I'll stick it somewhere.


On Mon, 2002-08-26 at 23:08, Ted Husted wrote:
> In creating a mock object for a JDBC utility, I found it useful to 
> implement a mock DataSource.
> 
> I didn't find one in the current API. Is this something that we would 
> like to add?
> 
> -Ted.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com

Re: [MO-java-dev] javax.sql.DataSource

[Ted H. <hu...@ap...>]

Patch submiited.

Jeff Martin wrote:

>Yes, please send it in and I'll stick it somewhere.
>
>
>On Mon, 2002-08-26 at 23:08, Ted Husted wrote:
>
>>In creating a mock object for a JDBC utility, I found it useful to 
>>implement a mock DataSource.
>>
>>I didn't find one in the current API. Is this something that we would 
>>like to add?
>>
>>-Ted.
>>
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: OSDN - Tired of that same old
>>cell phone?  Get a new here for FREE!
>>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>_______________________________________________
>>Mockobjects-java-dev mailing list
>>Moc...@li...
>>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>>

Re: [MO-java-dev] Volunteer: Ted Husted

[Ted H. <hu...@ap...>]

The patch submitted for CommonDataSource shows what I think would be 
appropriate for a mock class.

-Ted.

Tim Mackinnon wrote:

>So Maybe - I (we?) need some examples of what java doc Ted feels needs
>adding. Maybe if he doesn't mind doing some doc for a class or two and we
>can have a look at it. It could be that we've missed something important
>that Ted has picked up on - however I think we agree that we don't want to
>do java doc just for java doc's sake right?
>
>Tim
>