Re: 2.5.1 Released

Nat Pryce wrote:

> We've just released jMock 2.5.1, a bug-fix release that improves error messages.

Maven artifacts uploaded too.  Will be sync-ed to maven central repo 
shortly.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Mocking Objects

Mocking Objects

2.5.1 Released

We've just released jMock 2.5.1, a bug-fix release that improves error messages.

The changelog is at:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10336&styleName=Html&version=14527

--Nat

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

a question on jMock use

How to obtain current state of state-machine?

Hi.

Firstly; I'm very new to jMock so I apologize for any obvious oversights.

I'm using States but I can find no way to verify the final state at the end
of the test?  The only workaround I have found is declaring an (irrelevant)
method call in the desired state and making that call at the end of the test
to force a failure if the state is incorrect.

Thoughts?
--

-- 
View this message in context: http://www.nabble.com/How-to-obtain-current-state-of-state-machine--tp18809870p18809870.html
Sent from the jMock - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

JMock 2.5.0 maven artifacts uploaded

Hi,

I've uploaded maven artifacts for release 2.5.0

Just follow instructions from http://jmock.org/maven.html replacing 
2.4.0 -> 2.5.0.

Note that new module jmock-script has been added.

Any issues with it please let me know.

Cheers

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

new naming scheme generates ~almost always~ unique names from the caller stack trace

Hi,

As recently switching to JMock 2.5 from 1.x have found it strange that 
jmock complains about non-unique method names. While I understand that 
good mock names are important for identifying the mock, I think most of 
the time it would be enough if the caller test-method name would become 
automatically part of the mock name.

For example, you have this test method (note line numbers below):

10    // my test method
11    public void testMath() {
12      firstMath = context.mock(Math.class);
13      secondMath = context.mock(Math.class);
14      ...more...
15    }

Then using the following naming scheme you will automatically get the 
math(testMath:12) and math(testMath:13) generated names for firstMath 
and secondMath mocks.  Feel free to use this:
Cheers,
Zoltan

    /**
     * Mock object naming scheme generates unique names, by putting the 
caller's stack trace in the name.
     */
    public class UniqueStackTraceMethodNamingScheme implements 
MockObjectNamingScheme {

        private MockObjectNamingScheme delegate;

        /**
         * Default constructor, uses {@link CamelCaseNamingScheme} for 
generating the name.
         */
        public UniqueStackTraceMethodNamingScheme() {
            this(new CamelCaseNamingScheme());
        }

        /**
         * Constructor with a delegate naming scheme.
         * @param delegate The delegate
         */
        public UniqueStackTraceMethodNamingScheme(MockObjectNamingScheme 
delegate) {
            this.delegate = delegate;
        }

        /* (non-Javadoc)
         * @see 
org.jmock.lib.CamelCaseNamingScheme#defaultNameFor(java.lang.Class)
         */
        public String defaultNameFor(Class<?> typeToMock) {
            String name = delegate.defaultNameFor(typeToMock);
            StackTraceElement st = findCallerStackTraceElement();
            String nameFromStackTrace = st == null ? "" : 
                "(" + /*st.getClassName() + "." +*/ st.getMethodName() + 
":" + st.getLineNumber() +")";
            return name + nameFromStackTrace;
        }

        /**
         * Find the caller method, which is used for name generation.
         * @return
         */
        protected StackTraceElement findCallerStackTraceElement() {
            StackTraceElement[] stElements = (new 
Exception()).getStackTrace();
            StackTraceElement callerStackTraceElem = null;

            for (StackTraceElement stackTraceElement : stElements) {
                if (acceptStackTrace(stackTraceElement)) {
                    callerStackTraceElem = stackTraceElement;
                    break;
                }
            }
            return callerStackTraceElem;
        }

        /**
         * Check if this is the real caller method. Override this to do 
custom finding for method name
         * @param element
         * @return
         */
        protected boolean acceptStackTrace(StackTraceElement element) {
            // ignore all stack trace elements on this class
            String cname = this.getClass().getName();
            if (element.getClassName().equals(cname)) {
                return false;
            }
            // ignore all jmock classes
            if (element.getClassName().startsWith("org.jmock")) {
                return false;
            }
            return true;
        }
    }

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

problem downloading jmock dependencies using maven2

mocking concrete classes with final toString method

Hi there,

I'm using jmock 2.5.0RC1. When trying to mock concrete classes with final 
toString methods, I'm getting:

java.lang.IllegalArgumentException: 
ClassNameHere has a final toString method

Looking through jira and the changelogs, this is a direct result of this 
bug:
 	http://jira.codehaus.org/browse/JMOCK-150
and was implemented in changeset:
 	http://fisheye.codehaus.org/changelog/jmock?cs=1152

Is there a middle ground somewhere? I'm working with 3rd party classes 
where I have no control over their class structure. JMOCK-150 seems like 
squashing a bug with a hammer.

The original bug reporter mentioned that:

 	* an un-expected exception during the assertIsSatisfied() check
           (got the exception when tring to describe the mocked class using
           the final toString() which uses other methods from the original
           class)

Could the code in Mockery.assertIsSatisfied() look for the fact that a 
ClassImposteriser is being used and to bypass the toString method in case 
it is final? pseudo-code follows:

new ExpectationError("not all expectations were satisfied",
 	!toStringMethodIsFinalAndUsingClassImposteriser(dispatcher) ?
 	dispatcher :
 	dispatcher.getClass().getName()
);

Cheers,
--
Haroon Rafique
<haroon.rafique@...>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

JMock 2.5.0 Released

JMock 2.5.0 has been released.

The full changelog is at:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10336&styleName=Html&version=13840

--Nat

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email