from John Stoneham http://jira.codehaus.org/browse/JMOCK-256

In using JMock to test Grails classes, I'm using the 'grails interactive' mode which can repeatedly invoke test cases without shutting down the JVM. My tests all extend a common superclass that uses reflection to introspect and clear out instance variables, including my Mockery instances, so all of these instances are available for garbage collection. We're using ClassImposteriser as well.

The finalizer comes along and runs finalize() on the mocks. That invocation comes along into the proxy's callback within ClassImposteriser which gets into SingleThreadedPolicy's checkRunningOnTestThread method, but you're on the finalizer thread, not the test thread, so you get the thread-safety message.

Currently we publish to Codehaus (via Wagon, using WebDAV). Yuk.

Let's move to OSS Sonatype, it'll mean setting up a deployment PGP key for a more seamless experience. Not sure how to manage that (sharing the secret key between us).

Here's some tips (taken from another project, so take with a pinch of salt).

Links

• Sonatype Maven Repository User Guide
• Setting up PGP

Publishing to Sonatype Summary

As an abbreviated reminder, follow these steps.

1. Having added the Sonatype parent to your POM.

    <parent>
        <groupId>org.sonatype.oss</groupId>
        <artifactId>oss-parent</artifactId>
    </parent>

1. Having previously generated your PGP key, you may need to install it on the box you intend to deploy from. You will have to export it from the original keyring (where you first created the key pair) and install it along with the public key into the keyring on the machine you want to publish from.

   If you followed the steps in [Setting up PGP](https://docs.sonatype.org/displa y/Repository/How+To+Generate+PGP+Signatures+With+Maven) above, you will have published your public key to, lets say, hkp://pool.sks-keyservers.net.

2. You should just be able to publish via Maven

   mvn clean deploy

If you add the Maven PGP plugin to the pom.xml, it'll automatically sign the artifacts before publishing. You'll just need to enter your pass phrase as part of the build or install the keys into SSH.

Releasing

1. Having prepared a release (tagging etc) with the mvn release plugin.

   mvn release:clean mvn release:prepare

2. you firstly, have to stage the artifacts with Sonatype.

   mvn release:perform

3. This will upload to Sonatype's staging area where you can promote it through to a release via their GUI at https://oss.sonatype.org. Pick up the instructions for the GUI from the [User Guide](https://docs.sonaty pe.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-8.ReleaseIt).

If I try to mock a java.io.File using the ClassImposteriser, I get the following stack trace:

java.lang.IllegalArgumentException: null
        at net.sf.cglib.asm.ClassReader.<init>(Unknown Source)
        at net.sf.cglib.asm.ClassReader.<init>(Unknown Source)
        at net.sf.cglib.asm.ClassReader.<init>(Unknown Source)
        at net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
        at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
        at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
        at net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
        at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
        at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
        at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
        at org.jmock.lib.legacy.ClassImposteriser.proxyClass(ClassImposteriser.java:121)
        at org.jmock.lib.legacy.ClassImposteriser.imposterise(ClassImposteriser.java:66)
        at org.jmock.Mockery.mock(Mockery.java:148)
        at org.jmock.Mockery.mock(Mockery.java:124)
        at MockTest.testMock(MockTest.java:21)

I'm using: Java 1.8.0_40 JUnit 4.12 JMock 2.8.1

Trying to mock a java.util.Date does the same. If I use Java 1.7, it is OK. If I use JMock 2.6.0, it is OK.

My test is:

import java.io.File;

import org.jmock.integration.junit4.JUnitRuleMockery;
import org.jmock.lib.legacy.ClassImposteriser;
import org.junit.Rule;
import org.junit.Test;

public class MockTest
{
    @Rule
    public final JUnitRuleMockery _context = new JUnitRuleMockery()
    {
        {
            setImposteriser(ClassImposteriser.INSTANCE);
        }
    };

    @Test
    public void testMock()
    {
        _context.mock(File.class);
    }
}

My pom.xml is:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <version>1.00-SNAPSHOT</version>
    <groupId>test</groupId>
    <artifactId>my-project</artifactId>
    <packaging>jar</packaging>

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>3.3</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <version>2.18.1</version>
                </plugin>
            </plugins>
        </pluginManagement>

        <plugins>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>

        </plugins> 

    </build>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
                <version>4.12</version>
            </dependency>
            <dependency>
                <groupId>org.jmock</groupId>
                <artifactId>jmock</artifactId>
                <version>2.8.1</version>
            </dependency>
            <dependency>
                <groupId>org.jmock</groupId>
                <artifactId>jmock-junit4</artifactId>
                <version>2.8.1</version>
            </dependency>
            <dependency>
                <groupId>org.jmock</groupId>
                <artifactId>jmock-legacy</artifactId>
                <version>2.8.1</version>
            </dependency>
            <dependency>
                <groupId>org.hamcrest</groupId>
                <artifactId>hamcrest-core</artifactId>
                <version>1.3</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.jmock</groupId>
            <artifactId>jmock</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.jmock</groupId>
            <artifactId>jmock-junit4</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.jmock</groupId>
            <artifactId>jmock-legacy</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>


</project>

update bsh:bsh 1.3.0 to org.apache-extras.beanshell:bsh v2.0b6 (or later)

Note change of GroupID

All versions of beanshell prior to 2.0b6 are vulnerable to CVE-2016-2510

BeanShell (bsh) before 2.0b6, when included on the classpath by an application that uses Java serialization or XStream, allows remote attackers to execute arbitrary code via crafted serialized data, related to XThis.Handler.

See also beanshell on github for 2016-02-18 Security update

Additional reasons for update is that beanshell 1.3.0 has no license info, whereas 2.0b6 is Apache 2.0

Out of curiosity, tried to build an existing project (which uses 7) with Java 8 (source = 1.8, target=1.8) but I see many of these errors emitted by the Java 8 Compiler.

error: reference to with is ambiguous  both method with(Matcher<Float>) in Expectations and method with(Matcher<Double>) in Expectations match

With the latest reanimation of JMock are there any plans to add new features to JMock like partial mocking, mocking of static methods or mocking of private methods??

Especially partial mocking would be a great thing to have!

Hi,

JAX-WS is no longer part of Java 11 and this causes an error in ReturnDefaultCollectionTests:

Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.084 sec <<< FAILURE! - in org.jmock.test.unit.internal.ReturnDefaultCollectionTests
imposterisesUnsupportedMapTypes(org.jmock.test.unit.internal.ReturnDefaultCollectionTests)  Time elapsed: 0.002 sec  <<< ERROR!
java.lang.NoClassDefFoundError: javax/xml/ws/handler/LogicalMessageContext
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:190)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
        at org.jmock.test.unit.internal.ReturnDefaultCollectionTests.imposterisesUnsupportedMapTypes(ReturnDefaultCollectionTests.java:72)

Adding an explicit test dependency on jaxws-api fixes this.

Hi Jmock fits our usecase very well, and works like we want to.. But I am having a hard time convincing collegues to use a framework that seemingly are stale.. When I go to jmock.org it points at release 2.6.1 which are from 2013, however I can see that releases have been made 2017.. Mailing lists does not work either..

So what can I do to help getting the website up to date and mailinglist up and working again?

regards Nino

Hi,

considering mock objects, which are ignored via Expectations.ignoring(...):

While methods, which return an array, will return an empty array when called, methods, which return a Collection or Map, will not return an empty Collection or Map, but an ignored Collection or Map. This leads to an inconsistent Colletion/Map which returns 0 on size() but false on isEmpty().

I know, this is a special case, but I think the collection classes in java.util are so fundamental and used nearly everywhere, that it makes sense to return a consistent empty Collection/Map if a method of an ignored mock object has an according return type.

Guava's TimeoutFuture now always checks the delay of the ScheduledFuture before cancelling the task, which means that when we use it with DeterministicExecutor, it will always throw an exception before cancelling the task.

Before 2.6.x you could define your Mockery in the @Before method of a unit test, so that you had a new Mockery for every test and there was no chance of bleed over between the tests. The code might look something like:

@RunWith(JMock.class)
public class SomeTestClass {

    private Mockery context;

    @Before
    public void setUp() {
        context = new Mockery();
    }
}

Starting with 2.6.x, you need to define you Mockery before the @Before as a result of this change (https://github.com/jmock-developers/jmock-library/commit/27a0bd7e50a3cd82b26fc8ea947a65fd203088b7). So now you often have code that looks like:

@RunWith(JMock.class)
public class SomeTestClass {

    public static Mockery context;

    @BeforeClass
    public static void globalSetUp() {
        context = new Mockery();
    }
}

However, this causes mocked objects to persist between runs of the unit test, potentially resulting in errors like:

a mock with name fullScreenFrame already exists
java.lang.IllegalArgumentException: a mock with name fullScreenFrame already exists
    at org.jmock.Mockery.mock(Mockery.java:128)
    at org.jmock.Mockery.mock(Mockery.java:120)

Wouldn't it be better to hook the JMock.mockeryOf(Test) code after the test has been setup (after @Before has been called)?

As a work around, creating the Mockery in test's constructor avoids the bleed over. For example:

@RunWith(JMock.class)
public class SomeTestClass {

    private Mockery context;

    public SomeTestClass() {
         context = new Mockery();
    }
}

This was tested with JMock 2.8.3 and JUnit 4.11.

As suggested as in https://maven.apache.org/guides/mini/guide-configuring-plugins.html specify the version in the elements for each build plugins.

Signed-off-by: Niels Cölle [email protected]

Bumps maven-enforcer-plugin from 3.0.0-M2 to 3.0.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps byte-buddy from 1.10.9 to 1.11.9.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

It's (again) more than 2 years since the latest release. Important issues are already fixed on master (e.g. commit https://github.com/jmock-developers/jmock-library/commit/dad8d62e1f10464ce0d36f3bcb011a1dfe86d58f).

I'm wondering if this project is now finally retired after having returned from the dead already once or if we will see some updates at some point in time? Or at least a new release with the existing changes...

@jmock-developers (@olibye, @tobyweston, @npryce, @sf105, @PASimmons)