mockobjects-java-users — For people who use the mock objects libraries

Re: [MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

Quoting Nat Pryce <nat...@b1...>:

> ClassUnderTest would call an interface to perform unmarshalling.  It
> wouldn't care if the implementation of the interface was an adapter or a
> direct implementation.  Whichever approach you take (adapter or mocking
> castor), you'd put the mock unmarshaller into your own test package. 
> There's no need to touch the castor packages.

Yeah, it seems that an adapter is the most viable way so far.  I did have some 
other thoughts while we were exchanging these messages, though.  Is it possible 
to relax the expectation semantics so that expectations wouldn't have to be set 
*before* the "actuals" happen.  Wouldn't it be more flexible if expectations 
can be set at any time before verification, while actual cases are only 
recorded as they happen?  Then only at verification time they would be compared 
against each other. 

--J.X.

Re: [MO-java-users] any pattern for this?

[Nat P. <nat...@b1...>]

On Wed, 2003-12-17 at 15:03, J. Xue wrote:
> Quoting Nat Pryce <nat...@b1...>:
> 
> > Can't you mock the unmarshaller?
> 
> Well I thought about that, but first of all, wouldn't it go against the "Only 
> Mock Your Own Interface" pattern?  

Yes.  And if you're going to only mock your own interfaces the whole
problem goes away, doesn't it?

But if you're not, then this would be a workaround

> Secondly, that'd require ClassUnderTest to 
> call an adapter instead of calling the real unmarshaller directly (or do I just 
> make the mock unmarshaller in the castor package and shadow the real one on the 
> classpath?)  I wasn't sure either way would be a good idea...

ClassUnderTest would call an interface to perform unmarshalling.  It
wouldn't care if the implementation of the interface was an adapter or a
direct implementation.  Whichever approach you take (adapter or mocking
castor), you'd put the mock unmarshaller into your own test package. 
There's no need to touch the castor packages.

Cheers,
	Nat.

Re: [MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

Quoting Nat Pryce <nat...@b1...>:

> Can't you mock the unmarshaller?

Well I thought about that, but first of all, wouldn't it go against the "Only 
Mock Your Own Interface" pattern?  Secondly, that'd require ClassUnderTest to 
call an adapter instead of calling the real unmarshaller directly (or do I just 
make the mock unmarshaller in the castor package and shadow the real one on the 
classpath?)  I wasn't sure either way would be a good idea...

--J.X.

Re: [MO-java-users] any pattern for this?

[Nat P. <nat...@b1...>]

Can't you mock the unmarshaller?

Cheers,
            Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: "J. Xue" <sou...@ma...>
To: "MockObjects Users" <moc...@li...>
Sent: Tuesday, December 16, 2003 11:29 PM
Subject: Re: [MO-java-users] any pattern for this?


> Quoting Steve Freeman <st...@m3...>:
>
> > I don't understand. Are you trying to run your unit test within castor?
> > Why can't you just create an instance?
>
> ClassUnderTest calls the castor XML Unmarshaller to load ClassToMock. For
the
> test code to be able to sneak in a canned instance of ClassToMock, the
only
> way I can think of now is to make ClassUnderTest call a factory instead of
> calling castor directly, but it would unnecessarily complicate the design
> since most of the code is closely tied to castor anyway.
>
> --J.X.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

Re: [MO-java-users] any pattern for this?

[Steve F. <st...@m3...>]

Sounds like you should wrap the unmarshaller in an interface that you 
control, like you say.

Joe Walnes has come up with the interesting concept that you should only 
mock types that you own, not third party types. It's an interesting 
twist that pushes you to write your code in terms of your domain, not in 
terms of your infrastructure. I've been doing a lot of this recently on 
.Net (thank you MS for your flexible libraries...) and it works nicely.

S.

J. Xue wrote:
> ClassUnderTest calls the castor XML Unmarshaller to load ClassToMock.
> For the test code to be able to sneak in a canned instance of
> ClassToMock, the only way I can think of now is to make
> ClassUnderTest call a factory instead of calling castor directly, but
> it would unnecessarily complicate the design since most of the code
> is closely tied to castor anyway.

Re: [MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

Quoting Steve Freeman <st...@m3...>:

> I don't understand. Are you trying to run your unit test within castor? 
> Why can't you just create an instance?

ClassUnderTest calls the castor XML Unmarshaller to load ClassToMock. For the 
test code to be able to sneak in a canned instance of ClassToMock, the only 
way I can think of now is to make ClassUnderTest call a factory instead of 
calling castor directly, but it would unnecessarily complicate the design 
since most of the code is closely tied to castor anyway.

--J.X.

Re: [MO-java-users] any pattern for this?

[Steve F. <st...@m3...>]

I don't understand. Are you trying to run your unit test within castor? 
Why can't you just create an instance?

S.

J. Xue wrote:

> The class I'm trying to mock is instantiated by a third part tool (castor xml 
> unmarshaller in this case) that does not take any factory. My problem with this 
> is that I don't have chance to set any expectations before the actual calls are 
> made. How does everybody else handle cases like this with mock objects?
> 
> TIA.
> --J.X.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> 

-- 
"A LISP programmer knows the value of everything but the cost of nothing.
  A C programmer knows the cost of everything but the value of nothing."
(Todd Proebsting)

[MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

The class I'm trying to mock is instantiated by a third part tool (castor xml 
unmarshaller in this case) that does not take any factory. My problem with this 
is that I don't have chance to set any expectations before the actual calls are 
made. How does everybody else handle cases like this with mock objects?

TIA.
--J.X.

Re: [MO-java-users] Help Using expectAndReturn with a Mock object as the return value .

[Steve F. <st...@m3...>]

I've been through your example and can't see anything obvious. Can you 
include the MO source code and use your debugger to see what's in the 
Mock? One of the annoying things about a cast exception is that it 
doesn't tell you what the actual class of the object is.

Steve

p.s. what were your problems with the mailing list?

[MO-java-users] Help Using expectAndReturn with a Mock object as the return value .

[Cruz, E. J. <e....@ra...>]

	Hi, 

	I have an interface described below.

      	interface AccountBusiness {
		public UserTo authenticateUser(AccountTo account);
	}

	interface AccountDao {
		public AccountBusiness getAccount(account);
	}

	I have a method that uses this interface below:

	public UserTo authenticateUser(AccountTo account) {
		AccountBusiness accountBusiness = null;
		
		accountBusiness = getAccount(account);

		/** Some more stuff to perform authentication */
	}


         	private AccountBusiness getAccount(accounTo account) {	

	AccountBusiness accountBusiness = null;
     	 try {
                  	defaultDaoManager.startTransaction();
         		accountBusiness = accountDao.getAccount(account);
<------------  This line produces the error below.
         		defaultDaoManager.commitTransaction();
         	} catch (DaoException de) {
        	 	try {
            		defaultDaoManager.rollbackTransaction();
         		} catch (DaoException de2) {

		log.error(de.getMessage(), de);
         		throw new ResourceException(de);
         	}
	return accountBusiness;	
	}


          	I am trying to test this method using Mock Objects.  I have
the following code to test this:
	
	public class AccountAppServiceTest extends TestCase {

   		private AccountAppService accountAppService = null;
   		private AccountTo account = null;
   		private DaoManager defaultDaoManager = null;
   		private Mock accountDao = null;

   		protected void setUp() throws Exception {
      			super.setUp();
      			defaultDaoManager = new DaoManagerMock();
      			accountDao = new Mock(AccountDAO.class);
      			accountAppService = new AccountAppService
         				(defaultDaoManager,
(AccountDAO)accountDao.proxy());
      			account = new AccountTo();
      			account.setUsername("ecruz");
      			account.setPassword("testing");
      			account.setStatus("Active");
      			account.setBadPasswordCounter(2);
      			account.setDatePasswordChanged(new Date());
     			account.setFirstLogin(true);
   		}

		 public void testAuthenticateUser() {
      			//Setup
      			Mock returnMock = new Mock(AccountBusiness.class);
      			UserTo expectedUser = new
UserTo(account.getUsername());
      			List expectedRoles = new ArrayList();
      			expectedRoles.add("test");
      			expectedRoles.add("test1");

      			AccountBusiness returnVal =
(AccountBusiness)returnMock.proxy();

					/** Here I tell it to expect the
call to the accountDao getAccount method and to return the AccountBusiness
Mock proxy but I receive the error below.*/

      			accountDao.expectAndReturn("getAccount",
C.eq(account),
 
(AccountBusiness)returnMock.proxy());   

      			returnMock.expectAndReturn("authenticateUser",
C.eq(account),
                        			       expectedUser);

			accountDao.expectAndReturn("getAccountRoles",
C.eq(account), expectedRoles);
     			UserTo actualUser = null;

      			//Run
			try {
         				actualUser =
accountAppService.authenticateUser(account);
      			} catch (Exception e) {
         				e.printStackTrace();
         				this.fail("Unexpected Exception
reported " + e.toString());
      			}

      			//Validate
      			this.assertEquals("Unexpected UserName: ",
expectedUser.getUserName(),
                        		  actualUser.getUserName());
      			this.assertEquals("Unexpected Roles: ",
expectedRoles,
                        		  actualUser.getRoles());

      			accountDao.verify();
      			returnMock.verify();
   		}

		protected void tearDown() throws Exception {
		 	// Set everything to null
		}
	}	

	I receive this error when the accountDao.getAccount(account) method
is called above in the private getAccount 
	method of the AccountAppService.  
	
	I use the same type of return value in the expect in another test
case and I do not get any errors.  

	Any Suggestions on what this may be? 

	
          [junit] ------------- Standard Error -----------------
          [junit] java.lang.ClassCastException
          [junit]    at $Proxy0.getAccount(Unknown Source)
          [junit]    at
gov.wos.domain.account.AccountAppService.getAccount(Unknown Source)
          [junit]    at
gov.wos.domain.account.AccountAppService.authenticateUser(Unknown Source)
          [junit]    at
gov.wos.domain.account.AccountAppServiceTest.testAuthenticateUser(Unknown
Source)
          [junit]    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
          [junit]    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
          [junit]    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
          [junit]    at java.lang.reflect.Method.invoke(Method.java:324)
          [junit]    at junit.framework.TestCase.runTest(TestCase.java:154)
          [junit]    at junit.framework.TestCase.runBare(TestCase.java:127)
          [junit]    at
junit.framework.TestResult$1.protect(TestResult.java:106)
          [junit]    at
junit.framework.TestResult.runProtected(TestResult.java:124)
          [junit]    at junit.framework.TestResult.run(TestResult.java:109)
          [junit]    at junit.framework.TestCase.run(TestCase.java:118)
          [junit]    at
junit.framework.TestSuite.runTest(TestSuite.java:208)
          [junit]    at junit.framework.TestSuite.run(TestSuite.java:203)
          [junit]    at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRu
nner.java:325)
          [junit]    at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestR
unner.java:524)
          [junit] ------------- ---------------- ---------------
          [junit] Testcase:
testAuthenticateUser(gov.wos.domain.account.AccountAppServiceTest):   FAILED
          [junit] Unexpected Exception reported java.lang.ClassCastException
          [junit] junit.framework.AssertionFailedError: Unexpected Exception
reported java.lang.ClassCastException
          [junit]    at
gov.wos.domain.account.AccountAppServiceTest.testAuthenticateUser(Unknown
Source)
          [junit]    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
          [junit]    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
          [junit]    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
      


Jamie Cruz
Software Engineering 
e....@ra... 
(301)688-1430

Re: [MO-java-users] the good use of mockobjects

[Nat P. <nat...@b1...>]

On Wed, 2003-12-03 at 16:55, Mickael Vera wrote:
> Hi everybody,
> 
> I'm new to mockobjects and I try to understand to right way
> to use them.
> 
> What I understound of mockobjects is that the good way to
> use them is to know which interactions it will have with
> your tested object , then make your mockobject respond to the
> tested object requests and record them, at the end of the test
> check that what has been recorded is correct. Is it true ?

Not exactly.  Put assertions into your mocks, so that your mocks test
that they are being called correctly at the point that the call occurs. 
This will give you much more useful information when a failure occurs.

The Mock Objects jargon for an assertion in a mock object is an
"expectation": it defines what you expects to happen to the mock during
the test.


> Is it so important to test interactions with mockobjects if your
> tested method returns the values you expected ?

Yes, because the calls that an object makes to other objects around it
(its side effects) are part of its behaviour, and therefore something
that you should test.


> Is it correct sometimes to put code in your mockobject
> that does the same as the object it replaces instead of returning
> values. Sometimes it may be easier to code the functionnality than
> to emulate responses.

No.  If it is that hard to mock a response you must be doing something
wrong.  Why is it so hard to mock responses?  Let the "testability" of
your code guide its design and the code will become easier to maintain
as a result.

> In my case I test services called from a servlet, so I manipulate
> HttpRequest, HttpSession, ServletContext ... which I replaced with
> mockobjects.
> In this case I find it easier to code in the MockHttpSession the
> setAttribute
> and getAttribute methods than to guess which values will be asked if
> the service puts a lot of objects in the session and remove them.
> One service called by the servlet may have a lot of interactions
> with mockobjects and I can't use real objects as I don't have
> implementations.

It sounds like you are doing too much in one test.  In particular, it
sounds like you are trying to do integration testing rather than unit
testing.  Try testing each of those objects individually, and isolate
them using mock objects.

Cheers,
	Nat.

[MO-java-users] the good use of mockobjects

[Mickael V. <mv...@ge...>]

Hi everybody,

I'm new to mockobjects and I try to understand to right way
to use them.

What I understound of mockobjects is that the good way to
use them is to know which interactions it will have with
your tested object , then make your mockobject respond to the
tested object requests and record them, at the end of the test
check that what has been recorded is correct. Is it true ?

Is it so important to test interactions with mockobjects if your
tested method returns the values you expected ?

Is it correct sometimes to put code in your mockobject
that does the same as the object it replaces instead of returning
values. Sometimes it may be easier to code the functionnality than
to emulate responses.

In my case I test services called from a servlet, so I manipulate
HttpRequest, HttpSession, ServletContext ... which I replaced with
mockobjects.
In this case I find it easier to code in the MockHttpSession the
setAttribute
and getAttribute methods than to guess which values will be asked if
the service puts a lot of objects in the session and remove them.
One service called by the servlet may have a lot of interactions
with mockobjects and I can't use real objects as I don't have
implementations.

Do you think it is an acceptable use of mockobjects ? Or did I miss
something ? I don't want to use Cactus which forces me to deploy.
Maybe my use of mockobjects is too close to the the simulation of
a web container ?

Mickael

Re: [MO-java-users] Re: [MO-java-dev] Cretion of the dynamic mocks for classes vs. interfaces

[Steve F. <st...@m3...>]

If we get to where we want to be, we should be able to provide ordered 
mocks with some sugar code. (promises, promises)

S.

chris cottee wrote:
> I think you are right to go down the route of the API since if we still 
> want to keep our OrderedMocks we will probably just hide the use of the 
> API inside our own OrderedMock class, allowing us the best of both worlds.

Re: [MO-java-users] Re: [MO-java-dev] Cretion of the dynamic mocks for classes vs. interfaces

[chris c. <drc...@ya...>]

Hi Nat,
	I'm surprised that you found ordered Mocks brittle and unhelpful. In our 
code base we have
16 uses of OrderedMocks compared to 330 Mocks. This is a small percentage 
but I'd be loathe to give them up.
We use OrderedMocks in "transactional type" code, that is in our 
transaction manager, and in our streaming code. We have
n't found the tests were brittle and we (rewrote the error messages to be 
helpful )but looking at the code now this is plainly because the order 
that each of the methods is
called always matters in these cases.

I think you are right to go down the route of the API since if we still 
want to keep our OrderedMocks we will probably just hide the use of the 
API inside our own OrderedMock class, allowing us the best of both worlds.

Cheers,
Chris

Re: [MO-java-users] Re: [MO-java-dev] Cretion of the dynamic mocks for classes vs. interfaces

[Steve F. <st...@m3...>]

eu wrote:
> I see. That is sounds reasonable. In other words you are going to add 
> chaining of expectations but not through invocation handler. Basically 
> expectation on to be called after some other expectation. I can imagine 
> something like that.
> 
>  exp1 = mock.expect( "method1", C.args(...));
>  exp2 = mock.expect( "method1", C.after( exp1, C.args(...)));
>  exp2 = mock.expect( "method1", C.after( exp2, C.args(...)));

exactly.

> PS: what about the 1.0 release? Is anybody know the answer yet?

no promises, but we might have a little time just before xmas.

S.

Re: [MO-java-users] Re: [MO-java-dev] Cretion of the dynamic mocks for classes vs. interfaces

[eu <eu...@md...>]

Nat Pryce wrote:

>>  I faced that issue too. But my understanding was that I can and should 
>>use "match" for such calls. So all "expect"-like calls will be in order 
>>and all "match"-like calls can appear anywhere. Otherwise it will be just 
>>not possible to handle different returns for the sequential calls 
>>without or with the same parameters.
>>    
>>
>The issue with an ordered InvocationDispatcher is that it makes tests
>too brittle.  In general, one needs to specify that some calls are
>stubbed (matched in the 0.09 parlance), some are expected after others
>and some are expected but not in any order.  Requiring that *all* calls
>are expected in a fixed order makes tests easy to break when code is
>changed over time.  It is also quite a rare case -- I've only needed it
>when testing some quite baroque event announcement code. And even then
>it broke tests later!
>
>Our new approach is to provide an API that is used to specify that one
>invocation is expected to occur after another.  This has the benefits
>that it highlights the ordering in the test and allows *partial*
>ordering, which gives much needed flexibility to the test code.
>  
>
 I see. That is sounds reasonable. In other words you are going to add 
chaining of expectations but not through invocation handler. Basically 
expectation on to be called after some other expectation. I can imagine 
something like that.

  exp1 = mock.expect( "method1", C.args(...));
  exp2 = mock.expect( "method1", C.after( exp1, C.args(...)));
  exp2 = mock.expect( "method1", C.after( exp2, C.args(...)));
  ...

  This should be great.

  regards,
  Eugene

PS: what about the 1.0 release? Is anybody know the answer yet?

Re: [MO-java-users] Re: [MO-java-dev] Cretion of the dynamic mocks for classes vs. interfaces

[Nat P. <nat...@b1...>]

On Mon, 2003-12-01 at 05:53, Eugene Kuleshov wrote:
> Nat Pryce wrote:
>   I faced that issue too. But my understanding was that I can and should 
> use "match" for such calls. So all "expect"-like calls will be in order 
> and all "match"-like calls can appear anywhere. Otherwise it will be just 
> not possible to handle different returns for the sequential calls 
> without or with the same parameters.

The issue with an ordered InvocationDispatcher is that it makes tests
too brittle.  In general, one needs to specify that some calls are
stubbed (matched in the 0.09 parlance), some are expected after others
and some are expected but not in any order.  Requiring that *all* calls
are expected in a fixed order makes tests easy to break when code is
changed over time.  It is also quite a rare case -- I've only needed it
when testing some quite baroque event announcement code. And even then
it broke tests later!

Our new approach is to provide an API that is used to specify that one
invocation is expected to occur after another.  This has the benefits
that it highlights the ordering in the test and allows *partial*
ordering, which gives much needed flexibility to the test code.

Cheers,
	Nat.

Re: [MO-java-users] Re: [MO-java-dev] Cretion of the dynamic mocks for classes vs. interfaces

[Eugene K. <eu...@md...>]

Nat Pryce wrote:

>Sure, post patches to the SF patch manager.  Support for cglib is one of the
>goals after the 1.0 release.
>  
>
  Ok. I'll will do it this week. There are some minor/low-level issue 
that I'd like to investigate more.

  By the way, what is the timeframe for release 1.0?

  I really curious what kind of cglib support are you planning? New 
version of cglib have no dependency on heavy BCEL and using ASM instead, 
the beta I've used in that hack is quite stable.

>As for the OrderedInvocationDispatcher, experience has shown us that it is
>not a good idea.  No matter what ordering constraints are expected in the
>test, there are methods that can be called on an object at any time, such as
>toString.  Often these are called within the test framework when creating
>error messages and such.  If an OrderedInvocationDispatcher is used, calling
>these "out-of-order" methods will create obscure error messages. If the
>method was called while generating an error message, the final error message
>will hide the actual error, making it hard to detect what went wrong with
>the code.  So, our approach now is to use an unordered invocation dispatcher
>and to explicitly define which expected calls have a required ordering.  The
>definition of call order is not yet implemented, but will be very soon!
>  
>
  I faced that issue too. But my understanding was that I can and should 
use "match" for such calls. So all "expect"-like calles will be in order 
and all "match"-like calls can apper anywhere. Otherwise it will be just 
not possible to handle differerent returns fir the sequential calls 
without or with the same parameters.

  regards,
  Eugene

>Cheers,
>            Nat.
>_______________________
>Dr. Nathaniel Pryce
>B13media Ltd.
>http://www.b13media.com
>+44 (0)7712 526 661
>
>----- Original Message -----
>From: "Eugene Kuleshov" <eu...@md...>
>Cc: "'Mockobjects-Java-Dev'" <moc...@li...>;
>"'Mockobjects-Java-Users'" <moc...@li...>
>Sent: Sunday, November 30, 2003 4:10 PM
>Subject: [MO-java-dev] Cretion of the dynamic mocks for classes vs.
>interfaces
>
>>i,
>>
>>  I've implemented a feature that allows to pass class to Mock object
>>constructor (present functionality was only working for interfaces) and
>>even use non default constructor. That was possible because of cglib.
>>The affected class is Mock, and I've added CoreInstanceMock and
>>OrderedInvocationDispatcher.
>>
>>  Is anyone interesed?
>>
>>  regards,
>>  Eugene
>>    
>>

[MO-java-users] Re: [MO-java-dev] Cretion of the dynamic mocks for classes vs. interfaces

[Nat P. <nat...@b1...>]

Sure, post patches to the SF patch manager.  Support for cglib is one of the
goals after the 1.0 release.

As for the OrderedInvocationDispatcher, experience has shown us that it is
not a good idea.  No matter what ordering constraints are expected in the
test, there are methods that can be called on an object at any time, such as
toString.  Often these are called within the test framework when creating
error messages and such.  If an OrderedInvocationDispatcher is used, calling
these "out-of-order" methods will create obscure error messages. If the
method was called while generating an error message, the final error message
will hide the actual error, making it hard to detect what went wrong with
the code.  So, our approach now is to use an unordered invocation dispatcher
and to explicitly define which expected calls have a required ordering.  The
definition of call order is not yet implemented, but will be very soon!

Cheers,
            Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: "Eugene Kuleshov" <eu...@md...>
Cc: "'Mockobjects-Java-Dev'" <moc...@li...>;
"'Mockobjects-Java-Users'" <moc...@li...>
Sent: Sunday, November 30, 2003 4:10 PM
Subject: [MO-java-dev] Cretion of the dynamic mocks for classes vs.
interfaces


> Hi,
>
>   I've implemented a feature that allows to pass class to Mock object
> constructor (present functionality was only working for interfaces) and
> even use non default constructor. That was possible because of cglib.
> The affected class is Mock, and I've added CoreInstanceMock and
> OrderedInvocationDispatcher.
>
>   Is anyone interesed?
>
>   regards,
>   Eugene
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

[MO-java-users] Cretion of the dynamic mocks for classes vs. interfaces

[Eugene K. <eu...@md...>]

Hi,

  I've implemented a feature that allows to pass class to Mock object 
constructor (present functionality was only working for interfaces) and 
even use non default constructor. That was possible because of cglib. 
The affected class is Mock, and I've added CoreInstanceMock and 
OrderedInvocationDispatcher.

  Is anyone interesed?

  regards,
  Eugene

[MO-java-users] Java Open Source Programming book - illustrates mock objects

[Joe W. <jo...@tr...>]

Hi mock objects people,

Java Open Source Programming, is now available to buy. I'm mentioning it 
here because one of the main focal points of the book is 
test-driven-development with mock objects. As well as explaining the 
motivation and advantages of using mock objects, and of course how to 
use the Java mock objects library, it illustrates how to use the process 
behind mocks to drive the design of real world code, including with an 
MVC framework and persistence layer.

Buy the book here:
    http://www.amazon.com/exec/obidos/tg/detail/-/0471463620/

And see a review here:
    
http://www.theserverside.com/resources/article.jsp?l=JavaOpenSourceProgrammingBookReview

I apologise if you regard this message as spam - I consider it very 
on-topic ;)

cheers
-Joe Walnes (co-author)

RE: [MO-java-users] How can I test a servlet ?

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

> I looked in sources you are right, but the javadoc is wrong :

> com.mockobjects.servlet=20
> Class MockServletContext
> java.lang.Object
>   com.mockobjects.MockObject
>       com.mockobjects.servlet.MockServletContext
>=20
> All Implemented Interfaces:=20
> Verifiable=20
Probably the interface wasn't on the class path when the javadoc was
generated

>=20
> Thanks,
> Mickael
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
--=20

jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 55 478 331
phone: 44 (0) 20 77 29 45 45
email: jef...@mk...

www.mkodo.com

73 Leonard St, London, EC2A 4QS. U.K

RE: [MO-java-users] How can I test a servlet ?

[Mickael V. <mv...@ge...>]

> You could try these.
> http://www.mockobjects.com/wiki/ServletTestHelper

Thanks.

> > I don't understand how to use MockServletContext as it
> > doesn't implement the javax.servlet.ServletContext interface ?
> 
> hmm, from MockServletContext.java!
> 
> public class MockServletContext extends MockObject implements 
> ServletContext {

I looked in sources you are right, but the javadoc is wrong :

com.mockobjects.servlet 
Class MockServletContext
java.lang.Object
  com.mockobjects.MockObject
      com.mockobjects.servlet.MockServletContext

All Implemented Interfaces: 
Verifiable 

Thanks,
Mickael

Re: [MO-java-users] How can I test a servlet ?

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

On Thu, 2003-11-13 at 14:22, Mickael Vera wrote:

You could try these.
http://www.mockobjects.com/wiki/ServletTestHelper

> I don't understand how to use MockServletContext as it
> doesn't implement the javax.servlet.ServletContext interface ?

hmm, from MockServletContext.java!

public class MockServletContext extends MockObject implements ServletContex=
t {

>=20
> Mickael
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
--=20

jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 55 478 331
phone: 44 (0) 20 77 29 45 45
email: jef...@mk...

www.mkodo.com

73 Leonard St, London, EC2A 4QS. U.K

[MO-java-users] How can I test a servlet ?

[Mickael V. <mv...@ge...>]

Hi everyboy,

I don't understand how to test a servlet, all classes
of the package com.mockobjects.servlet don't implement
any interface of java servlets package.

I have a servlet, I'd like to instanciate it and send
it requests. My idea is to create a new class that inherits
from my servlet in order to add it a ServletContext.

Is it a good way ? 

I don't understand how to use MockServletContext as it
doesn't implement the javax.servlet.ServletContext interface ?

Mickael