Menu
▾
▴
mockobjects-java-dev — For people who are working on the implementation of the java version
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(13) |
Aug
(151) |
Sep
(21) |
Oct
(6) |
Nov
(70) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(47) |
Feb
(66) |
Mar
(23) |
Apr
(115) |
May
(24) |
Jun
(53) |
Jul
(10) |
Aug
(279) |
Sep
(84) |
Oct
(149) |
Nov
(138) |
Dec
(52) |
| 2003 |
Jan
(22) |
Feb
(20) |
Mar
(29) |
Apr
(106) |
May
(170) |
Jun
(122) |
Jul
(70) |
Aug
(64) |
Sep
(27) |
Oct
(71) |
Nov
(49) |
Dec
(9) |
| 2004 |
Jan
(7) |
Feb
(38) |
Mar
(3) |
Apr
(9) |
May
(22) |
Jun
(4) |
Jul
(1) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(15) |
Dec
(2) |
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(28) |
Jun
(3) |
Jul
(11) |
Aug
(5) |
Sep
(1) |
Oct
(5) |
Nov
(2) |
Dec
(3) |
| 2006 |
Jan
(8) |
Feb
(3) |
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nat P. <nat...@b1...> - 2002-08-26 21:18:10
|
Just to stick my oar in... the mock objects library is really divided into two parts, the core com.mockobjects package, which contains the expectation classes and MockObject base class, and then the packages of classes that mock actual APIs. The com.mockobjects package is so simple that I have not found a need for documentation beyond the source and tests. The other packages implement predefined interfaces (already documented by Sun, for example), and add setExpected... and setup... methods, the names of which follow strict conventions and are derived from the method and parameter names defined by the API. The steepest part of the learning curve, in my experience, was learning the naming conventions and how to apply the com.mockobject classes to the mocking of my own interfaces. The source to the mocked API packages was useful guidance. So, perhaps it would be better to write some tutorial documents, explaining the naming conventions and how to use the classes in com.mockobjects to create new mocks. There already is a document on naming conventions, but it is quite terse and the link is tucked away in the corner of the mock objects home page. Cheers, Nat. -- Dr. Nathaniel Pryce, Technical Director, B13media Ltd. Studio 3a, 22-24 Highbury Grove, London N5 2EA, UK http://www.b13media.com |
|
From: Tim M. <tim...@po...> - 2002-08-26 18:51:39
|
Hmmm - have seen this before at OTI where (when I was there many years ago)
we were required to put a method comment on public methods (and this was all
highly disciplined people) - and generally the method and names of the
paramters were all that was needed. I often wanted to write "Does just as it
says on the tin"!
If not - renaming the method is usually a better fix than writing the doc?
The only type of comment needed might be the range of the paramaters - but
then I think that the tests of a method more reliably document this. And if
you've got tests - why create more work by duplicated them in non-executable
code? Maybe a tool to autogenerate the comments would be an answer for those
who don't have good IDE's. We could just ship a little program with the
source code - DocGenerator.exe (that would be more useful). Of course -
there is sometimes a policy decision, or workaround that does require
documentation, and in this respect Ted is right. But for the mindless
stuff - docgenerator may be a better answer?
For example - I have just randomly picked a Java class from the javadoc
that I didn't know anything about "Control". The constructor has:
Control(Control.Type type)
Constructs a Control with the specified type.
and methods:
Control.Type getType()
Obtains the control's type.
String toString()
Obtains a String describing the control type and its current
state.
This isn't very useful is it??? There are lots of examples of this -
although once in a while there is a useful doc e.g. (InputStream)
public abstract int read()
throws IOExceptionReads the next byte of data from the
input stream. The value byte is returned as an int in the range 0 to 255. If
no byte is available because the end of the stream has been reached, the
value -1 is returned. This method blocks until input data is available, the
end of the stream is detected, or an exception is thrown.
Anyway - I'll stop now :-)
Tim
-----Original Message-----
From: Shellman, Joel [mailto:Joe...@su...]
Sent: 26 August 2002 18:27
To: tim...@po...
Subject: RE: [MO-java-dev] Volunteer: Ted Husted
> 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.
How ironic. I was just reading Sun's guidelines for writting JavaDoc and
they specifically stated that the JavaDoc should not state what is already
in the method signature.
Joel Shellman
---
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
|
|
From: Tim M. <tim...@po...> - 2002-08-26 17:51:01
|
Jeff - yep, you've answered the question. I think my problem was, that by implementing the entire interface - it looks too close (I didn't spot the getRealFile method). Which while technically correct - can cause lots of confusion - the type inconsistency being the main one (I curse sun over and over for this mess!) For very low file stuff - I guess you may need all the methods, so your implementation would prove useful. Do you think there is a use for "SimpleXXXX" implementations that just leave most of the low level stuff that most people don't use anyway? I'm of two minds on this... By the way - this kind of decision I would agree would benefit from Java Doc :-) Tim -----Original Message----- From: moc...@li... [mailto:moc...@li...]On Behalf Of Jeff Martin Sent: 23 August 2002 15:56 To: MockObjects Subject: Re: [MO-java-dev] Understanding alt.java.io? public java.io.File alt.java.io.File.getRealFile(); Was that the question? On Fri, 2002-08-23 at 00:22, Tim Mackinnon wrote: > Guys - I don't understand how alt.java.io.File (the interface that sun > should have used in the first place) helps us mock stuff up? > > I must be missing something very obvious - but if I have a MockFile that > conforms to that interface, I can't use it with Sun's FileReader object > which expects a java.io.File (there is a basic type difference problem > here). > > So I guess I don't understand the point of it??? At connextra we have > subclassed things like java.io.Reader (as we did for some of the other io > classes - some of which live in the orginial mockobjects code base), and > have implemented the crucial methods that get it to work as a stub and a > mock. This way a MockReader can be used with a BufferedReader and you can > write relevent tests with it. > > For trickier classes like File - which really seem to require fileDescriptor > objects we have adopted the "SimpleFile" convention, which just wraps File > and just delegates a subset of the most useful methods. This interface also > provides getFile, so that if you do use it at a low level in your code you > can get the File object and pass it to something like an XML Document class > (although we tend to use a MockReader in preference to the real file > anyway). > > Is alt.java.io.File an equivalent to the SimpleFile strategy? It doesn't > seem to be to me - so I am scratching my head trying to understand how its > being used in production code at the moment? > > With regards to some of this stuff, I promise to reintegrate asap to pass on > some of the stuff we have lurking around. Its taken us a long time to get > off visualAge so we can more easily work on open source projects (we are > almost there). > > Tim > --- > 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 > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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 |
|
From: Tim M. <tim...@po...> - 2002-08-26 17:20:45
|
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 |
|
From: Vincent M. <vm...@oc...> - 2002-08-25 17:52:06
|
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 > > > |
|
From: Ted H. <hu...@ap...> - 2002-08-25 16:41:42
|
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 > |
|
From: Vincent M. <vm...@oc...> - 2002-08-25 08:48:20
|
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 |
|
From: Ted H. <hu...@ap...> - 2002-08-23 19:37:45
|
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. |
|
From: Nat P. <np...@us...> - 2002-08-23 16:23:50
|
Update of /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/test
In directory usw-pr-cvs1:/tmp/cvs-serv17637/src/core/com/mockobjects/test
Modified Files:
AllTests.java
Added Files:
TestExpectationDoubleValue.java
Log Message:
Added ExpectationDoubleValue class that expects a double value within some error
--- NEW FILE: TestExpectationDoubleValue.java ---
package com.mockobjects.test;
import junit.framework.*;
import com.mockobjects.*;
import com.mockobjects.util.*;
public class TestExpectationDoubleValue extends TestCaseMo {
private static final Class THIS = TestExpectationDoubleValue.class;
private ExpectationDoubleValue myExpectation =
new ExpectationDoubleValue("ExpectationDoubleValue for testing");
public TestExpectationDoubleValue(String name) {
super(name);
}
public static void main(String[] args) {
start(new String[] { THIS.getName()});
}
public static Test suite() {
return new TestSuite(THIS);
}
public void testExpectNothing() {
myExpectation.setExpectNothing();
assertTrue("Should have an expectation",
myExpectation.hasExpectations());
}
public void testExpectNothingFail() {
myExpectation.setExpectNothing();
try {
myExpectation.setActual(100.0);
fail("Should fail fast");
} catch (AssertionFailedError ex) {
// expected
}
}
public void testFailOnVerify() {
myExpectation.setExpected( 0.0, 0.0 );
myExpectation.setFailOnVerify();
myExpectation.setActual(1.0);
assertVerifyFails(myExpectation);
}
public void testFlushActual() {
myExpectation.setActual(10);
myExpectation.setExpectNothing();
myExpectation.verify();
}
public void testHasNoExpectations() {
myExpectation.setActual(0.0);
assertTrue( "Has no expectations",
!myExpectation.hasExpectations());
}
public void testFailOutsideError() {
myExpectation.setExpected( 100.0, 1.0 );
try {
myExpectation.setActual(102.0);
fail("Should fail fast on double");
} catch (AssertionFailedError ex) {
//expected
}
}
public void testPassOnError() {
myExpectation.setExpected( 100.0, 1.0 );
myExpectation.setActual(101.0);
myExpectation.verify();
}
public void testPassWithinError() {
myExpectation.setExpected( 100.0, 1.0 );
myExpectation.setActual(100);
myExpectation.verify();
}
}
Index: AllTests.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/test/AllTests.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- AllTests.java 19 Jun 2002 15:07:11 -0000 1.4
+++ AllTests.java 23 Aug 2002 16:23:44 -0000 1.5
@@ -44,6 +44,10 @@
suite.addTest(TestExpectationValue.suite());
}
+ public static void addTestExpectationDoubleValue(TestSuite suite) {
+ suite.addTest(TestExpectationDoubleValue.suite());
+ }
+
public static void addTestMapEntry(TestSuite suite) {
suite.addTest(TestMapEntry.suite());
}
|
|
From: Nat P. <np...@us...> - 2002-08-23 16:23:46
|
Update of /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects
In directory usw-pr-cvs1:/tmp/cvs-serv17637/src/core/com/mockobjects
Added Files:
ExpectationDoubleValue.java
Log Message:
Added ExpectationDoubleValue class that expects a double value within some error
--- NEW FILE: ExpectationDoubleValue.java ---
package com.mockobjects;
import com.mockobjects.util.AssertMo;
import com.mockobjects.util.Null;
import junit.framework.Assert;
public class ExpectationDoubleValue extends AbstractExpectation {
private Double expectedValue = null;
private double expectedError = 0.0;
private boolean expectNothing = false;
private Double actualValue = null;
public ExpectationDoubleValue(String name) {
super(name);
clearActual();
}
public void clearActual() {
actualValue = null;
}
public void setActual( double value ) {
actualValue = new Double(value);
if (shouldCheckImmediately()) {
verify();
}
}
public void setExpected( double value, double error ) {
expectedValue = new Double(value);
expectedError = Math.abs(error);
setHasExpectations();
}
public void setExpectNothing() {
expectNothing = true;
clearActual();
setHasExpectations();
}
public void verify() {
if( expectNothing ) {
AssertMo.assertNull( myName + " expected no value",
actualValue );
} else if( expectedValue != null ) {
AssertMo.assertNotNull( myName + " expected a value",
actualValue );
double actualError = Math.abs(
actualValue.doubleValue() - expectedValue.doubleValue() );
AssertMo.assertTrue(
myName + " expected a value within " + expectedError +
" of " + expectedValue + ", was " + actualValue,
actualError <= expectedError );
}
}
}
|
|
From: Jeff M. <je...@mk...> - 2002-08-23 14:59:58
|
public java.io.File alt.java.io.File.getRealFile(); Was that the question? On Fri, 2002-08-23 at 00:22, Tim Mackinnon wrote: > Guys - I don't understand how alt.java.io.File (the interface that sun > should have used in the first place) helps us mock stuff up? > > I must be missing something very obvious - but if I have a MockFile that > conforms to that interface, I can't use it with Sun's FileReader object > which expects a java.io.File (there is a basic type difference problem > here). > > So I guess I don't understand the point of it??? At connextra we have > subclassed things like java.io.Reader (as we did for some of the other io > classes - some of which live in the orginial mockobjects code base), and > have implemented the crucial methods that get it to work as a stub and a > mock. This way a MockReader can be used with a BufferedReader and you can > write relevent tests with it. > > For trickier classes like File - which really seem to require fileDescriptor > objects we have adopted the "SimpleFile" convention, which just wraps File > and just delegates a subset of the most useful methods. This interface also > provides getFile, so that if you do use it at a low level in your code you > can get the File object and pass it to something like an XML Document class > (although we tend to use a MockReader in preference to the real file > anyway). > > Is alt.java.io.File an equivalent to the SimpleFile strategy? It doesn't > seem to be to me - so I am scratching my head trying to understand how its > being used in production code at the moment? > > With regards to some of this stuff, I promise to reintegrate asap to pass on > some of the stuff we have lurking around. Its taken us a long time to get > off visualAge so we can more easily work on open source projects (we are > almost there). > > Tim > --- > 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 > > > > ------------------------------------------------------- > 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 |
|
From: Nat P. <np...@us...> - 2002-08-23 14:43:38
|
Update of /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects
In directory usw-pr-cvs1:/tmp/cvs-serv11331/src/core/com/mockobjects
Modified Files:
ExpectationValue.java
Log Message:
Added setExpected(double) & setActual(double) to ExpectationValue
Index: ExpectationValue.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/ExpectationValue.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ExpectationValue.java 29 Jul 2001 19:50:24 -0000 1.1
+++ ExpectationValue.java 23 Aug 2002 14:43:32 -0000 1.2
@@ -24,6 +24,10 @@
setActual(new Long(aValue));
}
+ public void setActual(double aValue) {
+ setActual(new Double(aValue));
+ }
+
public void setActual(Object aValue) {
myActualValue = aValue;
if (shouldCheckImmediately()) {
@@ -41,6 +45,10 @@
public void setExpected(long aValue) {
setExpected(new Long(aValue));
+ }
+
+ public void setExpected(double aValue) {
+ setExpected(new Double(aValue));
}
public void setExpected(Object aValue) {
|
|
From: Nat P. <np...@us...> - 2002-08-23 14:43:37
|
Update of /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/test
In directory usw-pr-cvs1:/tmp/cvs-serv11331/src/core/com/mockobjects/test
Modified Files:
TestExpectationValue.java
Log Message:
Added setExpected(double) & setActual(double) to ExpectationValue
Index: TestExpectationValue.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/test/TestExpectationValue.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestExpectationValue.java 29 Jul 2001 19:50:24 -0000 1.1
+++ TestExpectationValue.java 23 Aug 2002 14:43:33 -0000 1.2
@@ -129,6 +129,27 @@
myExpectation.verify();
}
+ public void testDoubleFail() {
+ myExpectation.setExpected(100.0);
+
+ boolean testPasses = false;
+ try {
+ myExpectation.setActual(150.0);
+ } catch (AssertionFailedError ex) {
+ testPasses = true;
+ }
+
+ assertTrue("Should fail fast on double", testPasses);
+ }
+
+ public void testDoublePass() {
+ myExpectation.setExpected(100.0);
+
+ myExpectation.setActual(100.0);
+
+ myExpectation.verify();
+ }
+
public void testNullFail() {
myExpectation.setExpected(null);
|
|
From: Tim M. <tim...@po...> - 2002-08-22 23:38:25
|
I disagree with that change Steve. I know you prefer it - but its much clearer to have a boolean parameter. It also allows for a clearer test when you explicitly use false, to communicate that you really don't want an exception. It also lets you set true in a test setup method and for an odd test set it back to false. -----Original Message----- From: moc...@li... [mailto:moc...@li...]On Behalf Of Steve Freeman Sent: 22 August 2002 10:53 To: moc...@li...; mockobjects users Subject: Re: [MO-java-dev] com.mockobjects.io.MockWriter correction I've checked this in twice. 1) more or less as you sent it. 2) invoking committer's privilege I've: - changed setWriteShouldThrowException() not to take a parameter. The idea is that new instances should be constructed for each test, so you shouldn't be toggling this value on and off. It's either the default (off) or set. - changed some variable names - changed verify() to use the Verifier helper class. If you don't like this let me know and we can rollback, in the meantime, both versions are in CVS. Steve ----- Original Message ----- From: "Francois Beausoleil" <fbe...@ft...> To: <moc...@li...> Sent: Thursday, August 22, 2002 3:08 AM Subject: [MO-java-dev] com.mockobjects.io.MockWriter correction > [...] ------------------------------------------------------- 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 |
|
From: Tim M. <tim...@po...> - 2002-08-22 23:22:35
|
Guys - I don't understand how alt.java.io.File (the interface that sun should have used in the first place) helps us mock stuff up? I must be missing something very obvious - but if I have a MockFile that conforms to that interface, I can't use it with Sun's FileReader object which expects a java.io.File (there is a basic type difference problem here). So I guess I don't understand the point of it??? At connextra we have subclassed things like java.io.Reader (as we did for some of the other io classes - some of which live in the orginial mockobjects code base), and have implemented the crucial methods that get it to work as a stub and a mock. This way a MockReader can be used with a BufferedReader and you can write relevent tests with it. For trickier classes like File - which really seem to require fileDescriptor objects we have adopted the "SimpleFile" convention, which just wraps File and just delegates a subset of the most useful methods. This interface also provides getFile, so that if you do use it at a low level in your code you can get the File object and pass it to something like an XML Document class (although we tend to use a MockReader in preference to the real file anyway). Is alt.java.io.File an equivalent to the SimpleFile strategy? It doesn't seem to be to me - so I am scratching my head trying to understand how its being used in production code at the moment? With regards to some of this stuff, I promise to reintegrate asap to pass on some of the stuff we have lurking around. Its taken us a long time to get off visualAge so we can more easily work on open source projects (we are almost there). Tim --- 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 |
|
From: Jeff M. <cus...@us...> - 2002-08-22 18:03:53
|
Update of /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects
In directory usw-pr-cvs1:/tmp/cvs-serv29534/src/core/com/mockobjects
Modified Files:
ExpectationList.java
Log Message:
Fixed typo
Index: ExpectationList.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/ExpectationList.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ExpectationList.java 29 Jul 2001 19:50:24 -0000 1.1
+++ ExpectationList.java 22 Aug 2002 18:03:49 -0000 1.2
@@ -17,7 +17,7 @@
myName
+ " had different sizes\nExpected Size:"
+ myExpectedItems.size()
- + "\nReceived` Size: "
+ + "\nReceived size: "
+ size
+ " when adding:"
+ actualItem,
|
|
From: Francois B. <fbe...@ft...> - 2002-08-22 17:41:12
|
Hi there ! A simple typing mistake. It changes absolutely nothing in the running of the code itself. Bye ! -- Francois Beausoleil (fra...@ya...) Developper of Java Gui Builder - http://jgb.sourceforge.net/ I am Shakespeare of Borg. Prepare to be, or not to be, assimilated. ======================================================== Index: src/core/com/mockobjects/ExpectationList.java =================================================================== RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/ExpectationList.java,v retrieving revision 1.1 diff -u -r1.1 ExpectationList.java --- src/core/com/mockobjects/ExpectationList.java 29 Jul 2001 19:50:24 -0000 1.1 +++ src/core/com/mockobjects/ExpectationList.java 22 Aug 2002 17:39:53 -0000 @@ -17,7 +17,7 @@ myName + " had different sizes\nExpected Size:" + myExpectedItems.size() - + "\nReceived` Size: " + + "\nReceived size: " + size + " when adding:" + actualItem, |
|
From: Jeff M. <je...@mk...> - 2002-08-22 16:16:09
|
Okay guv On Thu, 2002-08-22 at 14:23, Steve Freeman wrote: > Committed > Hope it's ok now. > > I'm offline for a week. Jeff, can you keep an eye on this? > > Steve > > - - - - - - - - - - - - - - - > Steve Freeman st...@m3... > Programme chair OT2003. http://www.ot2003.org > > "Nonsense is just nonsense, but the study of nonsense is science." > > > > > ------------------------------------------------------- > 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 |
|
From: Steve F. <st...@m3...> - 2002-08-22 13:22:55
|
Committed Hope it's ok now. I'm offline for a week. Jeff, can you keep an eye on this? Steve - - - - - - - - - - - - - - - Steve Freeman st...@m3... Programme chair OT2003. http://www.ot2003.org "Nonsense is just nonsense, but the study of nonsense is science." |
|
From: Steve F. <sm...@us...> - 2002-08-22 13:21:58
|
Update of /cvsroot/mockobjects/mockobjects-java/src/jdk/common/com/mockobjects/io
In directory usw-pr-cvs1:/tmp/cvs-serv22461/src/jdk/common/com/mockobjects/io
Modified Files:
MockWriter.java
Log Message:
added new exception throwing methods
fixed infinite loop in verify
Index: MockWriter.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/common/com/mockobjects/io/MockWriter.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MockWriter.java 22 Aug 2002 09:48:14 -0000 1.2
+++ MockWriter.java 22 Aug 2002 13:21:50 -0000 1.3
@@ -31,11 +31,16 @@
* @author Francois Beausoleil, fb...@us...
*/
public class MockWriter extends Writer implements Verifiable {
- private ExpectationSegment segment = new ExpectationSegment("String segment");
- private ExpectationCounter flushCallsCount = new ExpectationCounter("flush calls");
- private ExpectationCounter closeCallsCount = new ExpectationCounter("close calls");
+ private ExpectationSegment segment =
+ new ExpectationSegment("String segment");
+ private ExpectationCounter flushCallsCount =
+ new ExpectationCounter("flush calls");
+ private ExpectationCounter closeCallsCount =
+ new ExpectationCounter("close calls");
private boolean writeShouldThrowException = false;
+ private boolean flushShouldThrowException = false;
+ private boolean closeShouldThrowException = false;
/**
* Instantiates a new mock writer which will act as a data sink.
@@ -44,20 +49,42 @@
* the provided methods.
*/
public MockWriter() {
- super();
+ // NOTE: We *have* to use the Writer(Object lock) constructor because
+ // Writer() will use this as a lock. When we call
+ // Verifier.verifyObject(MockWriter), it will find the lock field,
+ // which is Verifiable, resulting in an infinite recursion loop...
+ super(new Object());
}
/**
* Sets the mock's behavior when writing.
- * If this method has been called, then
- * {@link #write(char[],int,int) write(char[], int, int)} will throw an
- * {@link java.io.IOException IOException}.
+ * If this method has been called, then
+ * {@link #write(char[],int,int) write(char[], int, int)} will throw an
+ * {@link java.io.IOException IOException}.
*/
public void setWriteShouldThrowException() {
writeShouldThrowException = true;
}
/**
+ * Sets the mock's behavior when flushing. If this method has been called,
+ * then {@link #flush() flush()} will throw
+ * an {@link java.io.IOException IOException}.
+ */
+ public void setFlushShouldThrowException() {
+ flushShouldThrowException = true;
+ }
+
+ /**
+ * Sets the mock's behavior when closing.
+ * If this method has been called, then {@link #close() close()} will
+ * throw an {@link java.io.IOException IOException}.
+ */
+ public void setCloseShouldThrowException() {
+ closeShouldThrowException = true;
+ }
+
+ /**
* Sets the expected number of times that the {@link #flush() flush()}
* method will be called.
* @see #flush()
@@ -101,25 +128,46 @@
segment.setActual(new String(cbuf, off, len));
}
- /**
- * Increments the flush counter and asserts that this method was not
- * called too many times.
- * @see #setExpectedFlushCalls(int)
- */
- public void flush() throws IOException {
- flushCallsCount.inc();
- }
-
- /**
- * Increments the close counter and asserts that this method was not
- * called too many times.
- * @see #setExpectedCloseCalls(int)
- */
- public void close() {
- closeCallsCount.inc();
- }
-
+ /**
+ * This method will also throw an {@link java.io.IOException IOException}
+ * if asked to do so by calling
+ * {@link #setFlushShouldThrowException() setFlushShouldThrowException()}.
+ * Please note that the call count will be incremented <em>before</em> the
+ * check for the exception is done.
+ * @see #setExpectedFlushCalls(int)
+ * @see #setFlushShouldThrowException()
+ */
+ public void flush() throws IOException {
+ flushCallsCount.inc();
+
+ if (flushShouldThrowException) {
+ throw new IOException("Mock Exception");
+ }
+ }
+
+ /**
+ * Increments the close counter and asserts that this method was not
+ * called too many times.
+ * This method will also throw an {@link java.io.IOException IOException}
+ * if asked to do so by calling
+ * {@link #setCloseShouldThrowException() setCloseShouldThrowException()}.
+ * Please note that the call count will be incremented <em>before</em> the
+ * check for the exception is done.
+ * @see #setExpectedCloseCalls(int)
+ * @see #setCloseShouldThrowException()
+ */
+ public void close() throws IOException {
+ closeCallsCount.inc();
+
+ if (closeShouldThrowException) {
+ throw new IOException("Mock Exception");
+ }
+ }
+
public void verify() {
- Verifier.verifyObject(this);
+ // WARNING: If the MockWriter calls its parent no-arg constructor,
+ // this call will fail with a StackOverflowError. See constructor
+ // for details.
+ Verifier.verifyObject(this);
}
}
|
|
From: Francois B. <fbe...@ft...> - 2002-08-22 13:02:14
|
Hi guys ! Just found a problem with the MockWriter as committed by Steve. I had the problem yesterday, but did not have the energy to find why. Anyway, the diff below corrects this problem. Check the comments in the no-arg constructor for details. I also implemented two new functions: close() and flush() will cause IOExceptions if requested to do so. Have a nice day ! -- Francois Beausoleil (fra...@ya...) Developper of Java Gui Builder - http://jgb.sourceforge.net/ Index: src/jdk/common/com/mockobjects/io/MockWriter.java =================================================================== RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/common/com/mockobjects/io/MockWriter.java,v retrieving revision 1.2 diff -u -r1.2 MockWriter.java --- src/jdk/common/com/mockobjects/io/MockWriter.java 22 Aug 2002 09:48:14 -0000 1.2 +++ src/jdk/common/com/mockobjects/io/MockWriter.java 22 Aug 2002 12:57:52 -0000 @@ -36,6 +36,8 @@ private ExpectationCounter closeCallsCount = new ExpectationCounter("close calls"); private boolean writeShouldThrowException = false; + private boolean flushShouldThrowException = false; + private boolean closeShouldThrowException = false; /** * Instantiates a new mock writer which will act as a data sink. @@ -44,7 +46,11 @@ * the provided methods. */ public MockWriter() { - super(); + // NOTE: We *have* to use the Writer(Object lock) constructor because + // Writer() will use this as a lock. When we call + // Verifier.verifyObject(MockWriter), it will find the lock field, + // which is Verifiable, resulting in an infinite recursion loop... + super(new Object()); } /** @@ -58,6 +64,26 @@ } /** + * Sets the mock's behavior when flushing. + * If this method has been called, then + * {@link #flush() flush()} will throw an + * {@link java.io.IOException IOException}. + */ + public void setFlushShouldThrowException() { + flushShouldThrowException = true; + } + + /** + * Sets the mock's behavior when closing. + * If this method has been called, then + * {@link #close() close()} will throw an + * {@link java.io.IOException IOException}. + */ + public void setCloseShouldThrowException() { + closeShouldThrowException = true; + } + + /** * Sets the expected number of times that the {@link #flush() flush()} * method will be called. * @see #flush() @@ -104,22 +130,45 @@ /** * Increments the flush counter and asserts that this method was not * called too many times. + * This method will also throw an {@link java.io.IOException IOException} + * if asked to do so by calling + * {@link #setFlushShouldThrowException() setFlushShouldThrowException()}. + * Please note that the call count will be incremented <em>before</em> the + * check for the exception is done. * @see #setExpectedFlushCalls(int) + * @see #setFlushShouldThrowException() */ public void flush() throws IOException { flushCallsCount.inc(); + + if (flushShouldThrowException) { + throw new IOException("Mock Exception"); + } } /** * Increments the close counter and asserts that this method was not * called too many times. + * This method will also throw an {@link java.io.IOException IOException} + * if asked to do so by calling + * {@link #setCloseShouldThrowException() setCloseShouldThrowException()}. + * Please note that the call count will be incremented <em>before</em> the + * check for the exception is done. * @see #setExpectedCloseCalls(int) + * @see #setCloseShouldThrowException() */ - public void close() { + public void close() throws IOException { closeCallsCount.inc(); + + if (closeShouldThrowException) { + throw new IOException("Mock Exception"); + } } public void verify() { + // WARNING: If the MockWriter calls it's no-arg parent constructor, + // this call will fail with a StackOverflowError. See constructor + // for details. Verifier.verifyObject(this); } } |
|
From: Steve F. <sm...@us...> - 2002-08-22 11:28:35
|
Update of /cvsroot/mockobjects/no-stone-unturned/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv14284/doc/xdocs
Modified Files:
how_mocks_happened.xml
Log Message:
more rework
Index: how_mocks_happened.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/how_mocks_happened.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- how_mocks_happened.xml 21 Aug 2002 19:57:21 -0000 1.13
+++ how_mocks_happened.xml 22 Aug 2002 11:28:31 -0000 1.14
@@ -730,10 +730,20 @@
design decision and, again, we drove it from the process of writing a test.
</para>
<para>
- Design by composition, top-down with polymorphism, do the protocols first, shows the fault lines but
- it's more than divide and conquer.
+ We're designing each unit of code from the outside-in, from how the caller sees it. When we
+ program, writing tests with Mock Objects makes us think about the objects it
+ depends on, its environment. Sometimes those objects don't yet exist, which means that we've
+ found a conceptual <quote>fault line</quote> in the system that we can turn into
+ a new object interface. In our tests, we describe what the objects should say to each other,
+ their <emphasis>protocol</emphasis>, without having to figure out how the new objects actually
+ work. Applied consistently, this pushes us towards a codebase made up of components with
+ clear interfaces which (so I've been led to believe) makes good things like reusability
+ happen almost as a byproduct. What makes &TDD; so powerful is that we can do
+ all this incrementally, evolving the code from the requirements in hand rather than
+ having to place bets on the what we think we're going to need.
</para>
+
<para>
We want to unit test but don't want to expose more of the internals of the object than is necessary,
because that makes the class, and the code that uses it, that little bit harder to change; across a
@@ -760,12 +770,18 @@
a couple of critical failings: it turned out to be hard to change early design
decisions because, of course, they're embedded in the top-level structure, and it's not good at
encouraging reuse between lower-level components. It looks like &TDD; avoids those failures because
- of its emphasis on refactoring.
+ object-orientation makes it easier to share and replace components throughout the application and
+ because its emphasis on refactoring means we can adjust as the codebase grows.
</para>
</sidebar>
</section> <!-- What about design? -->
<!-- TODO --> <comment>Under development</comment>
+ <para>
+ Design by composition, top-down with polymorphism, do the protocols first, shows the fault lines but
+ it's more than divide and conquer.
+ </para>
+
<section>
<title>What does this mean?</title>
|
|
From: Steve F. <st...@m3...> - 2002-08-22 09:54:38
|
I've checked this in twice. 1) more or less as you sent it. 2) invoking committer's privilege I've: - changed setWriteShouldThrowException() not to take a parameter. The idea is that new instances should be constructed for each test, so you shouldn't be toggling this value on and off. It's either the default (off) or set. - changed some variable names - changed verify() to use the Verifier helper class. If you don't like this let me know and we can rollback, in the meantime, both versions are in CVS. Steve ----- Original Message ----- From: "Francois Beausoleil" <fbe...@ft...> To: <moc...@li...> Sent: Thursday, August 22, 2002 3:08 AM Subject: [MO-java-dev] com.mockobjects.io.MockWriter correction > [...] |
|
From: Steve F. <sm...@us...> - 2002-08-22 09:48:17
|
Update of /cvsroot/mockobjects/mockobjects-java/src/jdk/common/com/mockobjects/io
In directory usw-pr-cvs1:/tmp/cvs-serv18909/src/jdk/common/com/mockobjects/io
Modified Files:
MockWriter.java
Log Message:
changed some variable names
only set throwException, default is not to do anything
used Verifier to verify expections
Index: MockWriter.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/common/com/mockobjects/io/MockWriter.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockWriter.java 22 Aug 2002 09:41:54 -0000 1.1
+++ MockWriter.java 22 Aug 2002 09:48:14 -0000 1.2
@@ -31,9 +31,9 @@
* @author Francois Beausoleil, fb...@us...
*/
public class MockWriter extends Writer implements Verifiable {
- private ExpectationSegment mySegment = new ExpectationSegment("String segment");
- private ExpectationCounter myFlushCalls = new ExpectationCounter("flush calls");
- private ExpectationCounter myCloseCalls = new ExpectationCounter("close calls");
+ private ExpectationSegment segment = new ExpectationSegment("String segment");
+ private ExpectationCounter flushCallsCount = new ExpectationCounter("flush calls");
+ private ExpectationCounter closeCallsCount = new ExpectationCounter("close calls");
private boolean writeShouldThrowException = false;
@@ -44,19 +44,17 @@
* the provided methods.
*/
public MockWriter() {
+ super();
}
/**
- * Sets the mocks behavior when writing.
- * When the {@link #write(char[],int,int) write(char[], int, int)} method
- * is called, if this method was called with <code>true</code>, the mock
- * will throw an {@link java.io.IOException IOException} instead of
- * asserting a string segment.
- * @param state Set to <code>true</code> if you want the mock to throw an
- * exception, <code>false</code> otherwise.
+ * Sets the mock's behavior when writing.
+ * If this method has been called, then
+ * {@link #write(char[],int,int) write(char[], int, int)} will throw an
+ * {@link java.io.IOException IOException}.
*/
- public void setWriteShouldThrowException(boolean state) {
- writeShouldThrowException = state;
+ public void setWriteShouldThrowException() {
+ writeShouldThrowException = true;
}
/**
@@ -65,7 +63,7 @@
* @see #flush()
*/
public void setExpectedFlushCalls(int calls) {
- myFlushCalls.setExpected(calls);
+ flushCallsCount.setExpected(calls);
}
/**
@@ -74,7 +72,7 @@
* @see #close()
*/
public void setExpectedCloseCalls(int calls) {
- myCloseCalls.setExpected(calls);
+ closeCallsCount.setExpected(calls);
}
/**
@@ -87,7 +85,7 @@
* @see #write(char[], int, int)
*/
public void setExpectedSegment(String aString) {
- mySegment.setExpected(aString);
+ segment.setExpected(aString);
}
/**
@@ -97,10 +95,10 @@
*/
public void write(char cbuf[], int off, int len) throws IOException {
if (writeShouldThrowException) {
- throw new IOException("Exception, as requested");
+ throw new IOException("Mock Exception");
}
- mySegment.setActual(new String(cbuf, off, len));
+ segment.setActual(new String(cbuf, off, len));
}
/**
@@ -109,7 +107,7 @@
* @see #setExpectedFlushCalls(int)
*/
public void flush() throws IOException {
- myFlushCalls.inc();
+ flushCallsCount.inc();
}
/**
@@ -118,12 +116,10 @@
* @see #setExpectedCloseCalls(int)
*/
public void close() {
- myCloseCalls.inc();
+ closeCallsCount.inc();
}
public void verify() {
- mySegment.verify();
- myFlushCalls.verify();
- myCloseCalls.verify();
+ Verifier.verifyObject(this);
}
}
|
|
From: Steve F. <st...@m3...> - 2002-08-22 09:42:18
|
Done. Imports tidied up as well. S. ----- Original Message ----- From: "Francois Beausoleil" <fbe...@ft...> To: <moc...@li...> Sent: Thursday, August 22, 2002 2:51 AM Subject: [MO-java-dev] com.mockobjects.io.MockPrintWriter correction > Hello all ! > > I found a tiny problem with com.mockobjects.io.MockPrintWriter. I have > included a diff to correct this problem. The problem is a colon on the > author tag, which should not be there. Javadoc chokes on it. > [...] |
39 messages has been excluded from this view by a project administrator.
