What is the best way to make jmockit & cofoja a happy couple?

71 views
Skip to first unread message

Igor

unread,
May 24, 2013, 4:06:15 PM5/24/13
to cof...@googlegroups.com
Hello,

I've found one issue during integration of Cofoja into a project - that's unit testing using jmockit. Assume I wanna mock this interface:

interface Foo
{
  @Ensures("result != null")
  Object method();
}

and I have a test for:

@Mocked Foo foo;
@Test
public void test() {
  new NonStrictExpectations() {{
      foo.method(); result = new Object();
  }};
  // ...
}

As a result jmockit cannot handle his expectations due to foo.method() violates the contract because of jmockit's stub class created on the fly where Foo.method() simply returns null. Cofoja is in classpath, i.e. during such compilation the contract was applied and it looks fair.

The first idea that comes is to disable Cofoja's annotation processor upon testing start, but a question is how and whether Cofoja itself can provide something simple for that.

Do you have any idea/suggestion?

Thanks in advance.

Nhat Minh Lê

unread,
May 27, 2013, 11:37:24 AM5/27/13
to cof...@googlegroups.com, ig...@interlink-ua.com
Hi,

If I understand correctly, you want to disable contract checking on
some classes, since they are generated via JMockit, right?
If you just want to disable all contracts, just don't include the Java
agent when testing?

But there's also a mostly undocumented feature of Cofoja that lets you
bypass contracts on classes matching a given import pattern (e.g.,
com.google.*). There are various methods in RuntimeContractEnvironment
that let you set up your filters; you get an object of that class as
part of Cofoja initialization, if you provide the runtime with a
com.google.java.contract.configurator JVM property.

So, step by step:

1. Write a configurator class, which is loaded and called when Cofoja
is initialized; the most basic example of one can be found in
com.google.java.contract.tests.Cofoja; it needs to implement
com.google.java.contract.ContractEnvironmentConfigurator.

2. Pass the fully-qualified name of that class to the Java agen as the
com.google.java.contract.configurator JVM property. If you're using
the command-line, it should be:
-Dcom.google.java.contract.configurator=your.company.package.YourClass

3. In the configurator's configure() method, you'll get an environment
argument that you can use to disable contracts on classes of your
choice. You want to call
com.google.java.contract.core.runtime.RuntimeContractEnvironment.ignore()
with the pattern of the class names jmockit generates.

The only problem being I don't know whether jmockit generates classes
with reliable class names to blacklist.

Nhat
> --
> You received this message because you are subscribed to the Google Groups
> "cofoja" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cofoja+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Igor

unread,
May 28, 2013, 3:16:02 PM5/28/13
to cof...@googlegroups.com, ig...@interlink-ua.com
Hello,

Thanks for your attention and detailed response.

I see that JMockit is more tricky and he does the magic upon class loading using different class loaders, i.e. I don't see explicit separate java file generation. Unfortunately, it's quite intuitive for now, I have to dig into details of Cofoja and JMockit to get clear picture of their behaviour to see what can be done.
Reply all
Reply to author
Forward
0 new messages