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

Re: [MO-java-users] ATG Dynamo rewrite

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

I've responded to this on mockobjects-java-dev. Anyone out there want to 
get involved in this?

S.

Will Sargent wrote:
> I've got pretty huge patches to the mockobjects-atg codebase.  I've
> added a mock repository, ant build script, unit tests for the mock
> repository, and I've cleaned up the code so it has consistent formatting
> and headers.
> 
> Should I just send in the zip file, or would it be better to send a cvs
> diff on all the files?  The ATG Dynamo stuff doesn't have any
> attribution, so it's difficult to know who did what.

[MO-java-users] Testing multiple sequential SQL statements in one call.

[<rog...@vo...>]

Hi,

I (Roger) have a similar problem like Keith using multiple sequential SQL
statements.

The code fragment to be tested is:

				rs.next();
		
	
customerAddress.setStreetName(rs.getString("STREET_NAME"));
				logger.debug("Street name: " +
customerAddress.getStreetName());
	
customerAddress.setHouseNumberExtension(rs.getString("HOUSE_NO_EXT"));
	
customerAddress.setHouseNumber(rs.getInt("HOUSE_NO"));
	
customerAddress.setPostcode(rs.getString("POSTCODE"));
	
customerAddress.setCity(rs.getString("CITY"));
	
customerAddress.setCountry(rs.getString("COUNTRY"));
	
customerAddress.setType(rs.getString("TYPE"));


The test code is:

		// FORM STATEMENTS SETUP
		mockSingleRowResultSet.addExpectedNamedValues(new String[]
			{
				"ID", "OUTLET_CODE", "STATE",
"DECLINE_REASON", "ADVISOR",
				"CREATED", "LAST_CHANGED", "FORM_TYPE",
"FORM_DESCRIPTION",
				"SHORT_FORM_DESCRIPTION",
"SUPPORTS_MULTIPLE_MSISDN",
				"PROCESSING_TIME", "PROCESSING_TIME_UNIT",
				"AUTOMATIC_PROCESSING",
"ADVISOR_AUTHORIZATION_REQ",
				"PRINT_CONTRACT_ON_SUBMIT", "BUSINESS_NAME",
"PHONE_NUMBER",
				"PHONE_NUMBER_CS", "FAX_NUMBER", "WEBSITE",
"EMAIL",
				"CONTACT_TITLE", "CONTACT_FIRST_NAME",
"CONTACT_INITIALS",
				"CONTACT_MIDDLE_NAME", "CONTACT_LAST_NAME",
"STREETNAME_VISITOR",
				"HOUSENO_VISITOR", "HOUSENO_EXT_VISITOR",
"POSTCODE_VISITOR",
				"CITY_VISITOR", "COUNTRY_VISITOR",
"ADDRESS_TYPE_VISITOR",
				"STREETNAME_MAIL", "HOUSENO_MAIL",
"HOUSENO_EXT_MAIL",
				"POSTCODE_MAIL", "CITY_MAIL",
"COUNTRY_MAIL",
				"ADDRESS_TYPE_MAIL"
			},
			new Object[]
			{
				"15667", "00822048",
				"blah",
				new Integer(1), "AdvisorName",
				new java.sql.Timestamp(new
java.util.Date().getTime()), // created
				new java.sql.Timestamp(new
java.util.Date().getTime()), // last_changed
				"blah",
				"Formulieromschrijving",
"KorteOmschrijving", "Y",
				new Integer(11), "Minuten", "Y", "Y", "Y",
"BusinesSName",
				"PhoneNo", "PhoneNoCS", "FaxNo",
"http://WEbsite.nl",
				"my...@my...", "", "", "", "", "",
"StreetVisitor",
				new Integer(12), "HouseNoExtVisitor",
"9999VV", "CityVisitor",
				"CountryVisitor", "AddrTypeVisitor",
"StreetMail",
				new Integer(13), "HouseNoExtMail", "9999MM",
"CityMail",
				"CountryMailr", "AddrTypeMail"
			});
		mockPreparedStatement.addResultSet(mockSingleRowResultSet);

	
mockConnection.setupAddPreparedStatement(JDBCFormService.QUERY_FORM,
			mockPreparedStatement);

		// CUSTOMER_FORM STATEMENTS SETUP
		
		MockPreparedStatement mockPreparedStatement = new
MockPreparedStatement();
		MockSingleRowResultSet mockSingleRowResultSet = new
MockSingleRowResultSet();
		
		mockSingleRowResultSet.addExpectedNamedValues(new String[]
			{
				"FORM_ID", "MSISDN", "BUSINESS_NAME",
"FIRST_NAME", "INSERTIONS", 
				"LAST_NAME", "CUSTOMER_NUMBER", "PASSWORD",
"TYPE", "STREET_NAME",
",      msisdn" +
				"HOUSE_NO", "HOUSE_NO_EXT", "POSTCODE",
"CITY", "COUNTRY"
			},
			new Object[]
			{
				"15667", "0612345678", "BusinessName",
"FirstNAme", "Insertions"
			,	"LastName", new Integer(19283745), "pwd",
"VISITOR", "StreetName"
			,	new Integer(5), "a", "9999ZZ", "MESTREECH",
"NL0"
			});
			
		mockPreparedStatement.addResultSet(mockSingleRowResultSet);

		mockConnection.setupAddPreparedStatement(
			JDBCCustomerFormService.GET_ALL_CUSTOMER_INFO_SQL 
			, mockPreparedStatement);

		formService.setConnection(mockConnection);

		returnedXML = formService.getFormData("24").getXML();


When I run this code, the following assertion fails:

junit.framework.AssertionFailedError: CommonMockSingleRowResultSet.SqlRow
keys did not receive an expected item
Unexpected:HOUSE_NO
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.assertTrue(Assert.java:20)
	at
com.mockobjects.ExpectationSet.checkImmediateValues(ExpectationSet.java:17)
	at
com.mockobjects.AbstractExpectationCollection.addActual(AbstractExpectationC
ollection.java:17)
	at com.mockobjects.ExpectationMap.get(ExpectationMap.java:25)
	at
com.mockobjects.sql.ExpectationSqlRow.get(ExpectationSqlRow.java:53)
	at
com.mockobjects.sql.CommonMockSingleRowResultSet.getObject(CommonMockSingleR
owResultSet.java:186)
	at com.mockobjects.sql.MockResultSet.getInt(MockResultSet.java:216)
	at
nl.vodafone.dss.dataservices.jdbc.JDBCCustomerFormService$2.convert(JDBCCust
omerFormService.java:408)
	at
nl.vodafone.mercury.dataservices.jdbc.JDBCHelper.callSql(JDBCHelper.java:100
)
	at
nl.vodafone.mercury.dataservices.jdbc.JDBCHelper.performQuery(JDBCHelper.jav
a:64)
	at
nl.vodafone.dss.dataservices.jdbc.JDBCCustomerFormService.populate(JDBCCusto
merFormService.java:442)
	at
nl.vodafone.dss.dataservices.jdbc.JDBCCustomerFormService.getForm(JDBCCustom
erFormService.java:320)
	at
nl.vodafone.dss.dataservices.jdbc.JDBCCancelFormService.getForm(JDBCCancelFo
rmService.java:67)
	at
nl.vodafone.dss.dataservices.jdbc.JDBCCancelFormService.getFormData(JDBCCanc
elFormService.java:46)
	at
nl.vodafone.dss.dataservices.jdbc.JDBCCancelFormServiceTest.testLoadFormWith
ID(JDBCCancelFormServiceTest.java:296)
	at java.lang.reflect.Method.invoke(Native Method)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:392)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:276)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:167)


The problem is that it seems the "HOUSE_NO" column does not exist in the
second SQL statement, but then again, how could it ever find the
"STREETNAME" column (in fact every other column) but not the "HOUSE_NO"? I
suspect that the mockobjects does not handle multiple SQL statements very
well, though obviously I do not exclude an error in the way of thinking by
myself.

Help! I'm lost; this has taken excessive time already and I still cannot
work around it. I have - as displayed in the test code - tried initiating
new instances of preparedstatement and singlerowresultset, but even that
fails.

Kind regards,

Roger Stoffers

[MO-java-users] ATG Dynamo rewrite

[Will S. <wil...@ya...>]

Hi all,

I've got pretty huge patches to the mockobjects-atg codebase.  I've
added a mock repository, ant build script, unit tests for the mock
repository, and I've cleaned up the code so it has consistent formatting
and headers.

Should I just send in the zip file, or would it be better to send a cvs
diff on all the files?  The ATG Dynamo stuff doesn't have any
attribution, so it's difficult to know who did what.

Will.

[MO-java-users] Undeliverable mail

[<Pos...@qu...>]

Your message was not delivered to the following recipients:

             cl...@an...: 

[MO-java-users] Undeliverable mail

[<Pos...@qu...>]

Your message was not delivered to the following recipients:

                    bo...@ak...: 

[MO-java-users] Undeliverable mail

[<Pos...@qu...>]

Your message was not delivered to the following recipients:

           br...@to...: 

RE: [MO-java-users] Making Mock Objects for Static Members

[Anuj B. <AB...@La...>]

Right, I think I get it now. Should have been obvious I guess :-)

-----Original Message-----
From: Ilja Preuss [mailto:pr...@di...]
Sent: 05 February 2004 12:35
To: 'Anuj Bhatia'; moc...@li...
Subject: RE: [MO-java-users] Making Mock Objects for Static Members


moc...@li... wrote:
> Subject: [MO-java-users] Making Mock Objects for Static Members
> 
> 
> Hi,
> 
> I have a class that I want to test but I'm having trouble
> creating MockObjects for the classes referenced by my class. Consider
> the code below: 
> 
> public class MyClassToTest
> {
>    private ClassA a = ClassAFactory().instance().getGlobalClassA()
> 
>    public MyClassToTest()
>    {   }
> 
>    public myMethodToTest()
>    {
>       ClassB classBInst = new ClassB();
>    }
> }
> 
> I want to mock ClassA and ClassB. ClassA internally accesses
> a database and ClassB makes a JNDI lookup and both classes
> read configuration info from a properties file. Actually most
> of my classes read config from properties files using something like:
>     private static final Properties PROPERTIES =
> PropertiesLoader.load(PROPERTIES_FILE_NAME);
> This is another thing that I want to mock.
> 
> But how do I get the Mocks for ClassA and ClassB to
> MyClassToTest? The only way to do it seems to me to pass
> instances of ClassA and ClassB to the class constructor and
> to the method as parameters. But this changes the public
> interface of my class and I don't want the clients of this
> class to be burdened with the details of creating ClassA and
> ClassB. So how can I effectively test MyClassToTest?

For ClassA, you could make the ClassAFactory configurable. The test
would configure it so that instance() returns a mock implementation.
(That's what factories are for, aren't they???)

For ClassB, you could enhance the interface by a myMethodToTest(ClassB),
and the method without the parameter could simly delegate to it (so that
it's dumb enough to not need testing at all).

Does that help?


________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

RE: [MO-java-users] Making Mock Objects for Static Members

[Ilja P. <pr...@di...>]

moc...@li... wrote:
> Subject: [MO-java-users] Making Mock Objects for Static Members
> 
> 
> Hi,
> 
> I have a class that I want to test but I'm having trouble
> creating MockObjects for the classes referenced by my class. Consider
> the code below: 
> 
> public class MyClassToTest
> {
>    private ClassA a = ClassAFactory().instance().getGlobalClassA()
> 
>    public MyClassToTest()
>    {   }
> 
>    public myMethodToTest()
>    {
>       ClassB classBInst = new ClassB();
>    }
> }
> 
> I want to mock ClassA and ClassB. ClassA internally accesses
> a database and ClassB makes a JNDI lookup and both classes
> read configuration info from a properties file. Actually most
> of my classes read config from properties files using something like:
>     private static final Properties PROPERTIES =
> PropertiesLoader.load(PROPERTIES_FILE_NAME);
> This is another thing that I want to mock.
> 
> But how do I get the Mocks for ClassA and ClassB to
> MyClassToTest? The only way to do it seems to me to pass
> instances of ClassA and ClassB to the class constructor and
> to the method as parameters. But this changes the public
> interface of my class and I don't want the clients of this
> class to be burdened with the details of creating ClassA and
> ClassB. So how can I effectively test MyClassToTest?

For ClassA, you could make the ClassAFactory configurable. The test
would configure it so that instance() returns a mock implementation.
(That's what factories are for, aren't they???)

For ClassB, you could enhance the interface by a myMethodToTest(ClassB),
and the method without the parameter could simly delegate to it (so that
it's dumb enough to not need testing at all).

Does that help?

[MO-java-users] Making Mock Objects for Static Members

[Anuj B. <AB...@La...>]

Hi,

I have a class that I want to test but I'm having trouble creating
MockObjects for the classes referenced by my class. Consider the code below:

public class MyClassToTest
{
   private ClassA a = ClassAFactory().instance().getGlobalClassA()

   public MyClassToTest()
   {   }

   public myMethodToTest()
   { 
      ClassB classBInst = new ClassB();
   }
}

I want to mock ClassA and ClassB. ClassA internally accesses a database and
ClassB makes a JNDI lookup and both classes read configuration info from a
properties file. Actually most of my classes read config from properties
files using something like:
    private static final Properties PROPERTIES =
PropertiesLoader.load(PROPERTIES_FILE_NAME);
This is another thing that I want to mock.

But how do I get the Mocks for ClassA and ClassB to MyClassToTest? The only
way to do it seems to me to pass instances of ClassA and ClassB to the class
constructor and to the method as parameters. But this changes the public
interface of my class and I don't want the clients of this class to be
burdened with the details of creating ClassA and ClassB. So how can I
effectively test MyClassToTest?

Thanks
Anuj

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

[MO-java-users] Re: Mockobjects-java-users digest, Vol 1 #160 - 1 msg

[Keith Q. <ke...@qm...>]

Hi

Further to my post I have tracked down the reason for the initial Assertion
failure which was due to setting the tablename to "person" rather than
"Person". However, I still had the problem of verifying that the requests
were executed in the a certain order within the method under test. From
examining parts of the source code (ExpectationSet) it was obvious that what
was being checked was whether the object was present in the HashSet and no
ordering is associated with this.

I have managed to get the test to succeed however, I cannot assert the order
in which the statements are executed. Is there any way to achieve this?

Regards
Keith

Ps: the modified testcase: -

   public void testInsertNewRegistration(){

        setExpectationsForNextVal("Person");
        setExpectationsForInsertRegistration();
        person.setLogger(logger);
        person.setId(0); //forces insert ie: id only assigned on insert
        person.persist(mockConnection, today);
        verifyJDBC();

    }

    private void setExpectationsForInsertRegistration(){
        
mockConnection.setupAddPreparedStatement(PersonImpl.INSERT_NEW_REGISTRATION_
SQL,mockPreparedStatement);
        mockConnection.setupStatement(mockStatement);
           
mockPreparedStatement.addExpectedSetParameters(INSERT_NEW_REGISTRATION_ROW);
//todo: only add set expectations once. Factor out
        mockPreparedStatement.addUpdateCount(1);
        mockPreparedStatement.setExpectedCloseCalls(2);
        mockConnection.setExpectedRollbackCalls(0);
        mockConnection.setExpectedCommitCalls(0);
    }

    private void setExpectationsForNextVal(String tableName){
        
mockConnection.setupAddPreparedStatement(SELECT_NEXTVAL_SQL,mockPreparedStat
ement);
        mockConnection.setupStatement(mockStatement);
        mockPreparedStatement.addExpectedSetParameter(1,tableName);
        //set resultset to return value of PERSON_ID == 1
//todo: check if there is a better way of doing this!
        Object[][] rs = new Object[][] {{Integer.valueOf("1")},{}};
        mockResultset.setupRows(rs);
        mockPreparedStatement.addResultSet(mockResultset);
    }

[MO-java-users] Mocking away the database - multiple executes

[Keith Q. <ke...@qm...>]

Greetings from the North,

I have a question with regards to multiple executes within a method under
test.=20

LET ME EXPLAIN, I have a Person instance that I wish to make persistent and
I therefore invoke Person.persist() passing in the database connection. The
persit() method determines from its current state if this is an insert or a=
n
update and accordingly persists the associated data into the relational
database. When this is a simple update there is no problem. See extract fro=
m
test case: -

//extracts from testCase
public class TestPerson extends TestCaseMo{

    public TestPerson(String name) {
        super(name);
    }

    private MockConnection2 mockConnection =3D new MockConnection2();
    private MockPreparedStatement mockPreparedStatement =3D new
MockPreparedStatement();
    private MockStatement mockStatement =3D new MockStatement();
    private MockLogger logger =3D new MockLogger();       //mocks the logger
interface setting all levels active


  public void testUpdatePerson() throws SQLException {
        setExpectationsForUpdatePerson();
        person.setLogger(logger);
        person.setFirstName(FIRSTNAME2);
        person.persist(mockConnection);
        verifyJDBC();
    }

    private void setExpectationsForUpdatePerson() {

       =20
mockConnection.setupAddPreparedStatement(PersonImpl.UPDATE_PERSON_SQL,mockP=
r
eparedStatement);
        mockConnection.setupStatement(mockStatement);
        mockPreparedStatement.addExpectedSetParameters(UPDATE_PERSON_ROW);
        mockPreparedStatement.addUpdateCount(1);
        mockPreparedStatement.setExpectedCloseCalls(1);
        mockConnection.setExpectedRollbackCalls(0);
        mockConnection.setExpectedCommitCalls(0); //commit is by calling
method not persist(Connection con)!
    }


    private void verifyJDBC() {
        mockConnection.verify();
        mockStatement.verify();
        mockPreparedStatement.verify();
    }
}

However, when I test the more complicated case =B3insert=B2 this approach fails=
.

Insert creates multiple objects using a unique sequence ID from the
associated person table as a reference. See additional extract: -

   public void testInsertNewRegistration(){

        //note that insert new person also invokes getNextval as this is
required for the FK in
        //associated tables. Therefore need to test for Select NextVal also
        setExpectationsForPersonNextVal();
        setExpectationsForInsertRegistration();
        person.setLogger(logger);
        person.setId(0);
        person.persist(mockConnection);
        verifyJDBC();
    }

    private void setExpectationsForInsertRegistration(){
       =20
mockConnection.setupAddPreparedStatement(PersonImpl.INSERT_NEW_REGISTRATION=
_
SQL,mockPreparedStatement);
        mockConnection.setupStatement(mockStatement);
       =20
mockPreparedStatement.addExpectedSetParameters(INSERT_NEW_REGISTRATION_ROW)=
;
        mockPreparedStatement.addUpdateCount(1);
        mockPreparedStatement.setExpectedCloseCalls(1);
        mockConnection.setExpectedRollbackCalls(0);
        mockConnection.setExpectedCommitCalls(0); //commit is by calling
method not persist(Connection con)!
    }

    private void setExpectationsForPersonNextVal(){
       =20
mockConnection.setupAddPreparedStatement(SELECT_NEXTVAL_SQL,mockPreparedSta=
t
ement);
        mockConnection.setupStatement(mockStatement);
        mockPreparedStatement.addExpectedSetParameter(1,"seq_person");
        mockPreparedStatement.addUpdateCount(1);
    }
}

//run
junit.framework.AssertionFailedError:
CommonMockPreparedStatement.setParameters did not receive an expected item
Unexpected:1=3Dseq_Person
    at=20
com.mockobjects.ExpectationSet.checkImmediateValues(ExpectationSet.java:17)
    at=20
com.mockobjects.AbstractExpectationCollection.addActual(AbstractExpectation=
C
ollection.java:17)
    at=20
com.mockobjects.sql.CommonMockPreparedStatement.setObject(CommonMockPrepare=
d
Statement.java:237)
    at=20
com.mockobjects.sql.CommonMockPreparedStatement.setString(CommonMockPrepare=
d
Statement.java:172)
    at com.nowfollowme.core.Utils.getNextSeqValue(Utils.java:603)
    at com.nowfollowme.account.PersonImpl.persist(PersonImpl.java:867)
    at=20
com.nowfollowme.account.TestPerson.testInsertNewRegistration(TestPerson.jav=
a
:818)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at=20
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3=
9
)
    at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp=
l
.java:25)
    at com.intellij.rt.execution.junit2.JUnitStarter.main(Unknown Source)

This seems to be due to prepairedStatement being overwritten with the secon=
d
set of expectations. What I would ideally like is the facility to push
multiple sets of expectations and have them popped/verified in the order
that they were specified. Is this possible or have I missed the point
somewhere along the line.

The reason that persist() has this problem is that when a record is inserte=
d
into the database persist() first gets the next available sequence value fo=
r
the person table and persist() uses this value (personId) as a foreign key
into other associated records thereby calling multiple executes on the
connection.

Any ideas?
Keith

Re: [MO-java-users] expectAndReturn troubles

[Bryce F. <br...@be...>]

Thanks to everyone who responded. Your responses helped me greatly

> Steve Freeman said:
> You need to tell the mock about the two input parameters, otherwise it 
> can't tell which method you're referring to. There are some helper 
> methods in the C class.

That's where I was confused. I thought that specifying nothing in the
parameters meant you didn't care what was passed. Now it makes more
sense. Thanks.

> Nat said:
> If you want to ignore the exact values, you can do:
> 
>     expectAndReturn( "validateLogin", C.ANY_ARGS, Boolean.TRUE );

Which just confirmed it, and gave me what I thought I was originally
doing.

> Nat also said:
> I would also suggest that you use "self describing values" for your username
> and password parameters:
> 
>     addRequestParameter("username", "THE-USERNAME");
>     addRequestParameter("password", "THE-PASSWORD");

Thanks for the tip. I will definitely consider doing that.

Thanks again for all your help.

-- 
Bryce Fischer <br...@be...>

Re: [MO-java-users] expectAndReturn troubles

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

Calling expectAndReturn( method, result ) tells it to expect the method with
NO parameters.  Since the actual call happens with two parameters, the call
will not match the expectation.  The actual expectation should be:

    expectAndReturn( "validateLogin", C.args(C.eq(username),
C.eq(password)), Boolean.TRUE );

If you want to ignore the exact values, you can do:

    expectAndReturn( "validateLogin", C.ANY_ARGS, Boolean.TRUE );

The behaviour is confusing, I admit.  The next version will force tests to
be explicit by always requiring the arguments parameter to expectXxx and
stubXxx calls.

I would also suggest that you use "self describing values" for your username
and password parameters:

    addRequestParameter("username", "THE-USERNAME");
    addRequestParameter("password", "THE-PASSWORD");

This will make error messages easier to read.

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

----- Original Message -----
From: "Bryce Fischer" <br...@be...>
To: <moc...@li...>
Sent: Wednesday, January 07, 2004 1:56 AM
Subject: [MO-java-users] expectAndReturn troubles


Noob here.

Having a problem with getting dynamocks to work. I must be missing
something important here.

I'm getting the followin assertion failure:
junit.framework.AssertionFailedError: mockSecurityManagerDelegate:
validateLogin()
was expected but not called
at com.mockobjects.dynamic.Mock.verify(Mock.java:107)
at
com.berzerkersoft.bisweb.web.services.ValidateLoginTest.tearDown(ValidateLog
inTest.java:42)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:395)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:279)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:171)

Here's my Test Code:
public void testSuccessfulLogin() {
mockSecurityManager.expectAndReturn("validateLogin", true);

setRequestPathInfo("/validateLogin");
addRequestParameter("username", "bryce");
addRequestParameter("password", "bryce");
getRequest().setAttribute(SecurityManagerDelegate.class.getName(),
securityManager);

actionPerform();

verifyForward("success");
}

and here's the call my class is making:

...
...
if (manager.validateLogin(username, password)) {
actionForward = mapping.findForward(FORWARD_loginSuccessful);
...
...

I thought that calling expectAndReturn without any contstraint matchers
would accept any call regardless.. Maybe I'm wrong. Hopefully someone
can set me right.

TIA.

--
Bryce Fischer <br...@be...>



-------------------------------------------------------
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_id78&alloc_id371&op=ick
_______________________________________________
Mockobjects-java-users mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

Re: [MO-java-users] expectAndReturn troubles

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

You need to tell the mock about the two input parameters, otherwise it 
can't tell which method you're referring to. There are some helper 
methods in the C class.

S.

Bryce Fischer wrote:
> Here's my Test Code:
> 	public void testSuccessfulLogin() {
> 		mockSecurityManager.expectAndReturn("validateLogin", true);
> and here's the call my class is making:
> 	if (manager.validateLogin(username, password)) {

[MO-java-users] expectAndReturn troubles

[Bryce F. <br...@be...>]

Noob here.=20

Having a problem with getting dynamocks to work. I must be missing
something important here.

I'm getting the followin assertion failure:
junit.framework.AssertionFailedError: mockSecurityManagerDelegate: validate=
Login()
was expected but not called
	at com.mockobjects.dynamic.Mock.verify(Mock.java:107)
	at com.berzerkersoft.bisweb.web.services.ValidateLoginTest.tearDown(Valida=
teLoginTest.java:42)
	at junit.framework.TestCase.runBare(TestCase.java:130)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteT=
estRunner.java:395)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRu=
nner.java:279)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestR=
unner.java:171)

Here's my Test Code:
	public void testSuccessfulLogin() {
		mockSecurityManager.expectAndReturn("validateLogin", true);
	=09
		setRequestPathInfo("/validateLogin");
		addRequestParameter("username", "bryce");
		addRequestParameter("password", "bryce");
		getRequest().setAttribute(SecurityManagerDelegate.class.getName(), securi=
tyManager);
	=09
		actionPerform();
	=09
		verifyForward("success");
	}

and here's the call my class is making:

=2E..
=2E..
	if (manager.validateLogin(username, password)) {
		actionForward =3D mapping.findForward(FORWARD_loginSuccessful);
=2E..
=2E..

I thought that calling expectAndReturn without any contstraint matchers
would accept any call regardless.. Maybe I'm wrong. Hopefully someone
can set me right.

TIA.

--=20
Bryce Fischer <br...@be...>

Re: [MO-java-users] MockDirContext.setExpectedSearch(...) not useful due to SearchCon trols.equals()

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

speaking entirely off the cuff...

I see two options: add equals (and hashCode) methods to the test version 
of the SearchControls object so that it matches, or control the creation 
of the SearchControl object, perhaps through a passed-in factory, so 
that you can pass the same instance around.

The dynamic jmock library we're working on includes support for more 
flexible constraints than just equals.

S.


Demyanovich, Craig - Apogent wrote:
> I'm having problems using MockDirContext.setExpectedSearch(...).  Both my
> test and my code create a SearchControls instance and configure it with the
> same properties, i.e., two separate instances that are logically equal.
> However, the test fails with this message:
> 
> junit.framework.AssertionFailedError: mySearchControls did not receive the
> expected Value.
> 
> I learned that MockDirContext.verify(), inherited ultimately from
> MockObject, relies on the equals() implementation of the various expected
> and actual fields of MockDirContext.  I then decided to test the equals()
> implementation of SearchControls, and I discovered that it is inherited from
> java.lang.Object.  Therefore, it provides only reference equality and not
> logical equality.
> 
> Consequently, MockDirContext.setExpectedSearch(...) doesn't work as desired.
> If anyone does not agree with my analysis, please correct me.  Otherwise,
> has anyone taken any steps to address this with the Java team in general or
> the JNDI team in particular?

[MO-java-users] MockDirContext.setExpectedSearch(...) not useful due to SearchCon trols.equals()

[Demyanovich, C. - A. <cde...@ap...>]

Greetings,

I'm having problems using MockDirContext.setExpectedSearch(...).  Both my
test and my code create a SearchControls instance and configure it with the
same properties, i.e., two separate instances that are logically equal.
However, the test fails with this message:

junit.framework.AssertionFailedError: mySearchControls did not receive the
expected Value.

I learned that MockDirContext.verify(), inherited ultimately from
MockObject, relies on the equals() implementation of the various expected
and actual fields of MockDirContext.  I then decided to test the equals()
implementation of SearchControls, and I discovered that it is inherited from
java.lang.Object.  Therefore, it provides only reference equality and not
logical equality.

Consequently, MockDirContext.setExpectedSearch(...) doesn't work as desired.
If anyone does not agree with my analysis, please correct me.  Otherwise,
has anyone taken any steps to address this with the Java team in general or
the JNDI team in particular?

Thanks,
Craig

<<<<<<<<<<<<<   >>>>>>>>>>>>>
Craig Demyanovich
Software Developer
Apogent Technologies, Inc.
Tel:  269-544-7514
Fax:  269-544-7409
cdemyanovich @ apogent dot com

[MO-java-users] DynaMock question

[James H. <jw...@al...>]

I've just started using DynaMock objects in my testing and for the most 
part I really like them.  I've run into a situation that I would like to 
test with a dynamic Mock object, but I'm not sure if a dynamic Mock object 
can do what I want.  I'm trying to test an object that has the following 
behavior:

1. My test object registers itself with a model object to be notified of 
changes in the model.
2. A method is invoked on the test object which causes the test object to 
store a value into the model object.
3. The model object notifies interested parties that something about it 
has changed.

I've created a dynamic Mock object for the model such that it expects to 
have its notification registration method called with a particular type of 
object.  The mocked model also expects to have one of its setters called 
with a specific value.  What I haven't figured out how to do is test the 
model notification behavior.  What I would like to be able to do is ask 
the Mock for the object which was sent to it for the registration method.  
I could then simulate a call on that handler method and verify that the 
handler did the things it was supposed to do.  Something like this:

Mock mockModel = new Mock(Model.class);
mockModel.expectAndCapture("addValueChangeHandler", new 
IsInstanceOf(AspectChangeHandler.class));
...
AspectChangeHandler configuredHandler = 
mockModel.capturedValueFor("addValueChangeHandler");
configuredHandler.aspectChanged();
...

I'm contemplating making some extensions to a new subclass of Mock to 
handle this situation, but I'm wondering if there is some other way to 
accomplish the same thing using the standard dynamic mock capabilities.  
Of course, I could always code up a MockModel class to work the way I 
want, but if I can do something with dynamic mock objects I would like to 
use it.

On a related note, are there any good examples of dynamic mock usage?  I'm 
looking for examples which might show how to fully exploit its power.

Thanks.

-- 
James Howe

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

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

J. Xue wrote:
> Sometimes, it does make sense to define an abstract interface between
> a client and its vendor, but not all the time, especially when the
> usage of the vendor requires strong assumptions.  In this castor
> case, castor's (rather intrusive) usage paradigm has made a lot of
> impact on my code, e.g., all the classes handled by the marshalling
> engine must have either public getters/setters or have their own
> castor-dependent handlers.  Another example is that I had to make
> special wrapper classes simply because the XML unmarshaller cannot 
> effectively unmarshal a map.  From the design point of view, it would
> be just illusional to have an "un/marshaller interface" and pretend
> to have the ability to "plug in" another un/marshaller.

that's true, I think we were talking about a higher level interface that
has meaning in your domain. It might even be worth distinguishing
between "Castor" objects which are wrapped by "domain" objects.
Actually, that's not a bad idea given that the Castor objects have this
marhshalling baggage. Alternatively, you might want to have some kind of
common factory object that gets passed around and wraps the castor
infrastructure.

> Well, my question is, then, do mock objects drive, or do they
> actually *force* the design? Following this pattern, wouldn't I have
> to define interfaces for every 3rd party class I use that does not
> support a factory, in order to be able to plug in my own mocked
> version of those classes?

See above, maybe there's a thin veneer that converts between state 
(managed by Castor) and behaviour (which is yours).

S.

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

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

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

> Your object should make use of interfaces that make sense to it, not
> that are defined by technology that you have chosen.  This is what mock
> objects are good for: in TDD they drive the design of an object's
> *required* interfaces.

Sometimes, it does make sense to define an abstract interface between a client 
and its vendor, but not all the time, especially when the usage of the vendor 
requires strong assumptions.  In this castor case, castor's (rather intrusive) 
usage paradigm has made a lot of impact on my code, e.g., all the classes 
handled by the marshalling engine must have either public getters/setters or 
have their own castor-dependent handlers.  Another example is that I had to 
make special wrapper classes simply because the XML unmarshaller cannot 
effectively unmarshal a map.  From the design point of view, it would be just 
illusional to have an "un/marshaller interface" and pretend to have the ability 
to "plug in" another un/marshaller.

Well, my question is, then, do mock objects drive, or do they actually *force* 
the design? Following this pattern, wouldn't I have to define interfaces for 
every 3rd party class I use that does not support a factory, in order to be 
able to plug in my own mocked version of those classes?

--J.X.

> 
> Your object needs to unmarshall some data from some input stream.  The
> interface should express that.  An implementation of the interface can
> use the castor API.  But if you drive the design of the interface from
> the needs of your object, not from your choice of castor, then it will
> be easy to change your choice of XML API later if you want.  Using mock
> objects to drive the design of the interactions between your objects
> will naturally lead to such "flex points" in your design.
> 
> Cheers,
> 	Nat.
> 
> 
> 
> -------------------------------------------------------
> 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?

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

On Wed, 2003-12-17 at 23:02, J. Xue wrote:
> my code has had some strong assumption on the usage of castor. 
> Would it then still be architecturally reasonable and natural to introduce an 
> adapter that essentially duplicates the castor unmarshaller interface for the 
> sole purpose of plugging in MO's?

Your object should make use of interfaces that make sense to it, not
that are defined by technology that you have chosen.  This is what mock
objects are good for: in TDD they drive the design of an object's
*required* interfaces.

Your object needs to unmarshall some data from some input stream.  The
interface should express that.  An implementation of the interface can
use the castor API.  But if you drive the design of the interface from
the needs of your object, not from your choice of castor, then it will
be easy to change your choice of XML API later if you want.  Using mock
objects to drive the design of the interactions between your objects
will naturally lead to such "flex points" in your design.

Cheers,
	Nat.

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

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

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

> It is possible to do that in the current (non-dynamic) API.  Just turn
> off immediate verification on your expectation objects.

Are you referring to setFailOnVerify()?  I read through the javadoc, which 
seems to suggest that setFailOnVerify only defers the reporting of failures but 
not verification itself.

Thanks.
--J.X.

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

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

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

> Of course you can do that, but that's a different technique. How much 
> this matters depends on your task, what you should be avoiding is the 
> sort of test that fails at the end but you can't quite see where, so you 
> have to step it through in the debugger. An advantage of MO tests is 
> that they fail when the error occurs.

You (and Nat as he pointed out the same) definitly have a good point.

> There are also interesting questions about how the test drives the code. 
> MO tend to push you towards defining types that talk about the 
> relationshps between objects, state tests push you towards exposing 
> state in your objects. Your call...

That sure is thought-provoking. One thing I have kept pondering on is *how 
much* I would like (or, rather, can afford) the test to drive the code. e.g., 
in this case, my code has had some strong assumption on the usage of castor. 
Would it then still be architecturally reasonable and natural to introduce an 
adapter that essentially duplicates the castor unmarshaller interface for the 
sole purpose of plugging in MO's?

--J.X.

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

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

It is possible to do that in the current (non-dynamic) API.  Just turn
off immediate verification on your expectation objects.

But do you really want to?  It's much harder to work out what went wrong
after the fact because all the state that existed when the error
occurred has been lost.  If the mock fails as soon as it detects an
error it can generate better error messages and you can make the
debugger break into the program when it fails, so letting you examine
your live objects to find the error.

Cheers,
	Nat.



On Wed, 2003-12-17 at 16:37, J. Xue wrote:
> 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.
> 
> 
> -------------------------------------------------------
> 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...>]

J. Xue wrote:
> 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. 

Of course you can do that, but that's a different technique. How much 
this matters depends on your task, what you should be avoiding is the 
sort of test that fails at the end but you can't quite see where, so you 
have to step it through in the debugger. An advantage of MO tests is 
that they fail when the error occurs.

There are also interesting questions about how the test drives the code. 
MO tend to push you towards defining types that talk about the 
relationshps between objects, state tests push you towards exposing 
state in your objects. Your call...

S.

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