Adam Murray

I am trying to write jUnit tests for a Java external I am working on. Unfortunately, many methods in my external call the outlet() method, and I get this error when trying to run a unit test:

    at com.cycling74.max.MaxObject.doOutlet(Native Method)

    at com.cycling74.max.MaxObject.outlet(MaxObject.java:1425)

    at ajm.test.TestSeq.testReverse(TestSeq.java:16)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Which makes sense because outlet uses a native method provided by the Max environment. Is there a way I can work around this problem without completely reworking my code to decouple the logic I want to test from the calls to outlet()?

I am hoping I can make a fake stub for the doOutlet() native call, but I am not familiar with JNI so some help would be much appreciated.

java.lang.UnsatisfiedLinkError: doOutlet
	at com.cycling74.max.MaxObject.doOutlet(Native Method)
	at com.cycling74.max.MaxObject.outlet(MaxObject.java:1425)
	at ajm.seq.reverse(seq.java:145)
	at ajm.test.TestSeq.testReverse(TestSeq.java:16)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	...

unit-testing-java-externals-that-call-outlet

Also, I tried subclassing a test version of my class that overrides the outlet() methods to do nothing, but MaxObject declares the outlet() methods as final so this is not possible :(

I think I am just going to have to encapsulate all calls to outlet() inside my own output() method, and then override that to do nothing for my tests.

I guess this is not really that difficult but if there is a simpler way let me know...

On 11 Aug 2007, at 22:30, Adam Murray wrote:

> I think I am just going to have to encapsulate all calls to outlet 

> () inside my own output() method, and then override that to do 

> I think I am just going to have to encapsulate all calls to outlet 
> () inside my own output() method, and then override that to do  
> nothing for my tests.

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.loadbang.net


On 12 Aug 2007, at 10:24, Nick Rothwell wrote:

(That should read "Have" and would, of course, have been caught by a 

(That should read "Have" and would, of course, have been caught by a  
unit test.)

You don't even have to make a jni stub.just make your own version of 

MaxObject that implements any of the methods your mxj class might be 

calling.Include this class in your project instead of max.jar.

You don't even have to make a jni stub.just make your own version of 
MaxObject that implements any of the methods your mxj class might be 
calling.Include this class in your project instead of max.jar.


Quote: nick rothwell / cassiel wrote on Sun, 12 August 2007 02:24

----------------------------------------------------

I just spent some time with JMock and can't get it to do what I need. Since the objects I am dealing with are not interfaces, I was looking at this: 

http://www.jmock.org/mocking-classes.html.

 But when I use a ClassImposteriser, it seems like any calls I make to the mock object don't actually do anything. I believe it replaced my class with a empty stub class that does nothing. I need this to happen on the superclass, not my class.

Maybe I just don't understand JMock yet but I do not think it is a good solution for me. Here is all I want to do:

2. Call some methods on my external that transform it's internal state (these simulate incoming max messages)

3. Use a getter to access the internal state on my external and compare that against an expected value.

In order to accomplish this, I have to prevent MaxObject from doing what it normally does in the runtime environment. Besides the JNI calls, I am also running into an issue where I want to call System.out.println() for debugging and I can't because it is tied to some output stream for the runtime that does not exist when unit testing.

I don't see how JMock would let me easily swap in a fake MaxObject implementation, and even if it did, I don't need or want to deal with JMocks system of expectations. jUnit's asserts() already do everything I need.

Quote: nick rothwell / cassiel wrote on Sun, 12 August 2007 02:24
----------------------------------------------------
>
> [Have] you looked at JMock?
>
>

I just spent some time with JMock and can't get it to do what I need. Since the objects I am dealing with are not interfaces, I was looking at this: http://www.jmock.org/mocking-classes.html. But when I use a ClassImposteriser, it seems like any calls I make to the mock object don't actually do anything. I believe it replaced my class with a empty stub class that does nothing. I need this to happen on the superclass, not my class.

Maybe I just don't understand JMock yet but I do not think it is a good solution for me. Here is all I want to do:
1. Instantiate my mxj external
2. Call some methods on my external that transform it's internal state (these simulate incoming max messages)
3. Use a getter to access the internal state on my external and compare that against an expected value.

Quote: topher lafata wrote on Sun, 12 August 2007 04:32

> You don't even have to make a jni stub.just make your own version of 

> MaxObject that implements any of the methods your mxj class might be 

> calling.Include this class in your project instead of max.jar.

I may end up doing this. It's a little annoying because there are a lot of methods in MaxObject to implement, and I am slightly concerned I may implement a method improperly. I don't know if this is realistic, but what if some day I have code that relies on getName() or getAttr() to make a decision, but my implementation always returns null or some bogus string. I really just want to change the behavior of the problem methods...

I also don't like that I'll probably have to do this more than once: for MspObject and who knows what else.

If I can figure out how to do it, the easiest solution may be to instrument max.jar when unit testing, and alter the bytecode such that problem calls like outlet() don't do anything. I believe I could use something like AspectJ to insert a return statement into the top of any method I want.

Are other people running into these problems or do most people not bother to write unit tests? Can anyone describe a setup where unit testing is working inside the IDE?

Quote: topher lafata wrote on Sun, 12 August 2007 04:32
----------------------------------------------------
> You don't even have to make a jni stub.just make your own version of 
> MaxObject that implements any of the methods your mxj class might be 
> calling.Include this class in your project instead of max.jar.
>
----------------------------------------------------

Are other people running into these problems or do most people not bother to write unit tests? Can anyone describe a setup  where unit testing is working inside the IDE?

On 12 Aug 2007, at 23:47, Adam Murray wrote:

> I just spent some time with JMock and can't get it to do what I 

> need. Since the objects I am dealing with are not interfaces, I was 

Indeedy - JMock can mock interfaces, not actual classes, which is a 

bit of a pain until/unless you're willing to do a bit of refactoring 

to accomodate. In this case, you'd have to design some kind of facade 

IMaxObject interface (say), and then program against that (and then 

link it into the real MaxObject somehow, perhaps via another concrete 

subclass of MaxObject which implements IMaxObject).

Yes, it's a hassle; probably not worth it for a one-off (old-skool 

stubs are easier), but perhaps worth thinking about for some big- 

> I just spent some time with JMock and can't get it to do what I  
> need. Since the objects I am dealing with are not interfaces, I was  
> looking at this: http://www.jmock.org/mocking-classes.html.

Indeedy - JMock can mock interfaces, not actual classes, which is a  
bit of a pain until/unless you're willing to do a bit of refactoring  
to accomodate. In this case, you'd have to design some kind of facade  
IMaxObject interface (say), and then program against that (and then  
link it into the real MaxObject somehow, perhaps via another concrete  
subclass of MaxObject which implements IMaxObject).

Yes, it's a hassle; probably not worth it for a one-off (old-skool  
stubs are easier), but perhaps worth thinking about for some big- 
project agile/extreme goodness.

If anyone else is wondering how to test their Java externals, here's what I ended up doing:

I made my own method output() that is the only code in my external allowed to call outlet(). This turns out to have some benefits, because I can make overloaded forms of output() that handle different internal message formats and convert them into the format needed for outlet() (like Atom[]).

Then, in my unit tests, I have a class that subclasses the external I am testing, and overrides output() to do nothing. All my tests instantiate the subclass instead of the real external class. The only downside is this has to be done for each external, but it's not much work unless you need to refactor existing code that has outlet() calls all over the place.

There are definitely some other good ideas in this thread, but this approach seemed to be the easiest and most straightforward.

Also, in an earlier post I mentioned an issue with calling System.out. This can easily be corrected by doing this when the unit test initializes:

And then use "out" for any debugging purposes. Same applies to System.err. I think as soon as you construct any MaxObject, these streams will be "stolen".

I made my own method output() that is the only code in my external allowed to call outlet(). This turns out to have some benefits, because I can make overloaded forms of output() that handle different internal message formats and convert them into the format needed for outlet() (like Atom[]). 

There are definitely some other good ideas in this thread, but this approach seemed to be the easiest and most straightforward. 

Also, in an earlier post I mentioned an issue with calling System.out. This can easily be corrected by doing this when the unit test initializes:
PrintStream out = System.out;
And then use "out" for any debugging purposes. Same applies to System.err. I think as soon as you construct any MaxObject, these streams will be "stolen".

Unit testing Java externals that call outlet()