mockobjects-java-dev

[MO-java-dev] CVS: no-stone-unturned/src/nostone/addressbook AddressBookServletTest.java,1.1,1.2

[Steve F. <sm...@us...>]

Update of /cvsroot/mockobjects/no-stone-unturned/src/nostone/addressbook
In directory usw-pr-cvs1:/tmp/cvs-serv3836/src/nostone/addressbook

Modified Files:
	AddressBookServletTest.java 
Log Message:
First test runs, but doesn't test anything.


Index: AddressBookServletTest.java
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/src/nostone/addressbook/AddressBookServletTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AddressBookServletTest.java	21 Aug 2002 21:58:34 -0000	1.1
+++ AddressBookServletTest.java	21 Aug 2002 23:49:39 -0000	1.2
@@ -4,7 +4,7 @@
 
 import javax.servlet.http.*;
 import javax.servlet.ServletException;
-import java.io.IOException;
+import java.io.*;
 
 public class AddressBookServletTest extends TestCase {
   public AddressBookServletTest(String name) {
@@ -12,11 +12,29 @@
   }
 
   public void testNoEntries() throws ServletException, IOException {
-    HttpServletRequest mockRequest = new NullHttpServletRequest();
-    HttpServletResponse mockResponse = new NullHttpServletResponse();
+    final StringWriter page = new StringWriter();
 
-    AddressBookServlet servlet = new AddressBookServlet();
+    HttpServletRequest mockRequest = new NullHttpServletRequest() {
+      public String getMethod() {
+        return "PUT";
+      }
+      public String getProtocol() {
+        return "HTTP/1.1";
+      }
+    };
+    HttpServletResponse mockResponse = new NullHttpServletResponse() /*{
+      public void setContentType(String contentType) {
+        assertEquals("Should be content type", "text/plain", contentType);
+      }
+
+      public PrintWriter getWriter() throws IOException {
+        return new PrintWriter(page);
+      }
+    }*/;
 
+    AddressBookServlet servlet = new AddressBookServlet();
     servlet.service(mockRequest, mockResponse);
+
+    // assertEquals("Response page", "No address found", page.toString());
   }
 }

[MO-java-dev] Understanding alt.java.io?

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

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

Re: [MO-java-dev] Understanding alt.java.io?

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

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

RE: [MO-java-dev] Understanding alt.java.io?

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

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

RE: [MO-java-dev] Understanding alt.java.io?

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

On Mon, 2002-08-26 at 18:50, Tim Mackinnon wrote:
> 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!)

It can be a little confusing but it does have the advantage of allowing
it's use with the minimum of changes to existing code. Just change you
imports from java.io.* to alt.java.io.* and when you need the underlying
file call getRealFile(); although it's probably better to use
StreamFactory.createInputStream(alt.java.io.File)

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

I've tried to take the same approach as I do with mocks in trying to
make them as dumb as possible. So the alt.* stuff is more along the
lines to patched versions to the Sun classes. I kinda feel that anything
else may become dangerously like a framework, which is not what we're
here for. 

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