inner test question

Development
1

So I’ve started writing tests for the VASSAL Engine. I figured I’d start with something simple–test that for all traits, trait = deserialize(serialize(trait))

I’ve done ActionButton and more or less have it working, but there’s something that doesn’t look right.

I’m serializing by calling button.getType() which will throw a NullPointerException unless inner is set. Following the example of the TriggerActionTest that someone else already wrote, I did this to setInner:

button.setInner(new BasicPiece())

The problem is that if button.description = “foo” then when I deserialize by calling new ActionButton(type, basicPiece), the description of the new ActionButton is “foo piece”.

Which breaks my expectation that trait = deserialize(serialize(trait)).

Have I got it backwards? Should I instead be instantiating something else and then setting ActionButton to be inner to it, and then testing serialize/deserialize on the outer thing? If so, what should that outer thing be?

Or am I misunderstanding something more fundamental?

Ken

P.S. Initially, I didn’t think this was a big deal until I wrote a similar test for CalculatedProperty with an expression of “x+1” and found that for the deserialized serialized piece the expression came out “x + 1 piece” which definitely doesn’t look right…

2

Never mind. Found the solution. I just realized that new ActionButton() calls mySetType() not setType(), so I was doing an asymmetrical operation. If I serialize using button.mySetType() everything works fine.

-K

3

Hi Ken,

Sounds like you have it worked out.

The test for Trigger Action was my first ever JUnit test. I needed an instantiated piece to test regression of a specific bug. You can’t test much on a trait if it does not have an Inner trait and the best way is to create one with a default BasicPiece().

Yes, myGetType is the opposite of mySetType, Good idea to test for equivalency.

I have added equals() and hashCode() methods to Expression which should do for all Expressions. Note that everything to do with Expressions is in need of serious testing :slight_smile:

B.

“fil512” wrote:

…
I’m serializing by calling button.getType() which will throw a
NullPointerException unless inner is set. …

Never mind. Found the solution. I just realized that new
ActionButton() calls mySetType() not setType(), so I was doing an
asymmetrical operation. If I serialize using button.mySetType()
everything works fine.

-K

4

Pretty impressive for your first ever test!

It looks like the test you wrote is connected to a bug, which is an excellent practice I would strongly advocate. VASSAL will become a much more stable code base if every time we find a bug, we first write a test that reproduces the bug, get the test to fail, code the fix, and see the test pass. This has 2 immediate benefits: 1) You confirm that your change actually fixed a bug. 2) It guarantees that the bug will never happen again.

That is assuming that we developers have a shared understanding that we’re not allowed to commit code unless all tests pass. Is this something we could agree to?

I have to say it’s been a while since I’ve seen “xyzzy”. Made me smile. You’re dating yourself…

I’m on my 7th serialization test now–I’ve had to add a bunch of hashCode() and equals() methods to core classes to support the tests–model classes should implement these methods anyways. If you’re interested to see how I handled the GameModule.init() dependency, you can have a look in the svn branch called kstevens. I used a tool called jmock which is really good at handling stuff like this. The core of it looks like this:

		final GameModule module = context.mock(GameModule.class);
		context.checking(new Expectations() {
			{
				oneOf(module).setGpIdSupport(with(any(GameModule.class)));
				oneOf(module).build();
				oneOf(module).getDataArchive();
				oneOf(module).getComponentsOf(with(any(Class.class)));
				oneOf(module).sliceLargeImages();
			}
		});
		GameModule.init(module);

-K

5

Thus spake fil512:

That is assuming that we developers have a shared understanding that
we’re not allowed to commit code unless all tests pass. Is this
something we could agree to?

I’m happy to work this way on the trunk. Off the trunk (and maintenance
branches, like 3.1), this practice could make it hard to store unfinished
work.

I’m on my 7th serialization test now–I’ve had to add a bunch of
hashCode() and equals() methods to core classes to support the
tests–model classes should implement these methods anyways. If you’re
interested to see how I handled the GameModule.init() dependency, you
can have a look in the svn branch called kstevens. I used a tool called
jmock which is really good at handling stuff like this. The core of it
looks like this:

Maybe look at using org.apache.commons.lang.builder.HashCodeBuilder for your
hashCode methods. You’ll write a lot less code that way.

I’ve been slowly converting things to use Apache Commons stuff whenever
we can, since it’s then less code for us to maintain.

–
J.

6

That is assuming that we developers have a shared understanding that
we’re not allowed to commit code unless all tests pass. Is this
something we could agree to?

Sounds good to me.

I have to say it’s been a while since I’ve seen “xyzzy”. Made me smile.
You’re dating yourself…

:slight_smile:

I used a tool called jmock which is really good at handling stuff like this.

How does this compare to Mockito, which we had started using. We should standardize on one or the other.

Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au

7

I do all my development in eclipse (which I would highly recommend. It has a menu-option for generating hashCode and equals (probably uses the apache tool).

That is awesome. Ideally, all Vassal code would only be concerned with Vassal things. Other infrastructure/framework type stuff we should be able to get from jars. (Glances at zipfs code…)

-Ken

8

Thus spake fil512:

“uckelman” wrote:

Maybe look at using org.apache.commons.lang.builder.HashCodeBuilder
for your
hashCode methods. You’ll write a lot less code that way.

I do all my development in eclipse (which I would highly recommend.
It has a menu-option for generating hashCode and equals (probably uses
the apache tool).

No, Eclipse is not using HashCodeBuilder, it has some sort of complex code
template that it dumps on you.

What you’d have it you were using HashCodeBuilder is this,

public int hashCode() {
return new HashCodeBuilder().append(a).append(b).append(c).toHashCode();
}

which is also tons more readable, since the calculations are abstracted out.

(You will pry Vim from my cold, dead hands, BTW. I have yet to see a reason
I find compelling enough for me to code in Eclipse. I’ll use it as a
debugger, but I won’t write code in it.)

–
J.

9

That is certainly cleaner than what Eclipse generates. At the same time, I feel reassured when I use Eclipse generate hashCode() and equals() for me that they will be in contractual compliance with one another.
[quote=“uckelman”
(You will pry Vim from my cold, dead hands, BTW. I have yet to see a reason
I find compelling enough for me to code in Eclipse. I’ll use it as a
debugger, but I won’t write code in it.)
[/quote]
Heh. I felt the same way about emacs for years. Making the transition from keyboard to mouse and keyboard was particularly painful. However, having watched Eclipse power-users work, and picking up their best practices, for me there is no going back now. I am now convinced that writing code in Eclipse is not only faster, but also results in much higher quality code. It took me a while (and a lot of frustration) to get there, but I finally did.

I felt the same way about unit tests for the longest time. I thought they were a complete waste of time for many years. And then I started working on projects that had 75% test coverage and my eyes were opened. Wow. There is nothing quite like the rush you get from being able to do a major code cleanup without having to worry about whether your changes broke anything.

-K

10

How does this compare to Mockito, which we had started using.
We should standardize on one or the other.

There’s a nice short summary of the difference here

old.nabble.com/Differences-betwe … 23576.html

where it says

“jmock is highly opiniated tool specifically designed as a tool to design
object protocols and discover role interfaces, mockito is designed to simply
isolate external dependecies and make testing easier.”

A more comprehensive comparison is here

rrees.wordpress.com/2009/04/12/t … e-mockers/

where it says

“I feel that Mockito is a framework for Test Driven Development and JMock is
a framework for Test Driven Design… One thing that making you type out
your Expectations in JMock does is make you think, really think, about the
way your code is collaborating.”

Jmock is more widely used that mockito. It’s hard to back up a claim like
that, but here are a couple of numbers I measured:

Google mockito 52,000
Google jmock 580,000

Amazon mockito 1 book
Amazon jmock 9 books

One interpretation of these numbers is that your average developer will be
10 times more likely to be familiar with jmock than mockito. In the java
circles my colleagues and I travel in (JavaOne conference, Agile development
conference, Jboss World) I see and hear a lot more about jmock than mockito.

That being said, given that VASSAL is a legacy code base that is already
saddled with some pretty major design issues (e.g. cycles and high
complexity), and given that VASSAL isn’t really designed with a Service
Oriented Architecture at all, I think the value we get from using jmock over
mockito is pretty low considering the extra overhead jmock introduces.

As the guy writing the tests, I’m happy to go either way. Let me know if
you have a preference and I’ll use that one.

Ken

11

Ken,

As the guy writing the tests, I’m happy to go either way. Let me know
if you have a preference and I’ll use that one.

No preference at all. I have written exactly one test using Mockito and I think Joel is about the same. It will be easy to change those over. You are more familiar, so you choose.

B.

12

Thus spake “Brent Easton”:

Ken,

As the guy writing the tests, I’m happy to go either way. Let me know
if you have a preference and I’ll use that one.

No preference at all. I have written exactly one test using Mockito and I thi
nk Joel is about the same. It will be easy to change those over. You are more
familiar, so you choose.

You’re giving me too much credit: I’ve written zero tests with Mockito.

I would like to have a chance to read the stuff Ken posted about the two
systems before we commit ourselves, though.

–
J.

13

I’ve localized all the mocking stuff into 2 small classes, so it’s a small
change when you decide.

-----Original Message-----
On Behalf Of Joel Uckelman

Thus spake “Brent Easton”:

Ken,

As the guy writing the tests, I’m happy to go either way. Let me
know if you have a preference and I’ll use that one.

No preference at all. I have written exactly one test using Mockito
and I thi nk Joel is about the same. It will be easy to change those
over. You are more familiar, so you choose.

You’re giving me too much credit: I’ve written zero tests with Mockito.

I would like to have a chance to read the stuff Ken posted about the two
systems before we commit ourselves, though.

–
J.

14

Thus spake “Ken Stevens”:

How does this compare to Mockito, which we had started using.
We should standardize on one or the other.

One thing which jumps out at me is the stuff about mocking concrete
classes. Am I correct in understanding that you can’t do this in jMock?
I see that they want you to have interfaces, but what happens if you
have a method you want to test which isn’t part of any interface?

Say, e.g., you want to test a private method. Now, I can anticipate that
you might say that you shouldn’t be testing private methods, but to me
that sounds like saying that private methods don’t need to work properly.

So, I’d like to hear your thoughts on this.

–
J.

15

If you have a look at my test code you will see that I am mocking a concrete
class. That capability exists in jmock. Perhaps it wasn’t available in
jmock when that article was written.

I’m tempted to use mockito because I always like learning new tools, but I
worry a bit about how much more widely used jmock is than mockito–you want
to pick technologies that are here to stay…

-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of Joel Uckelman
Sent: August 27, 2010 12:47 PM
To: messages@vassalengine.org
Subject: Re: [messages] Mockito vs. Jmock

Thus spake “Ken Stevens”:

How does this compare to Mockito, which we had started using.
We should standardize on one or the other.

One thing which jumps out at me is the stuff about mocking concrete classes.
Am I correct in understanding that you can’t do this in jMock?
I see that they want you to have interfaces, but what happens if you have a
method you want to test which isn’t part of any interface?

Say, e.g., you want to test a private method. Now, I can anticipate that you
might say that you shouldn’t be testing private methods, but to me that
sounds like saying that private methods don’t need to work properly.

So, I’d like to hear your thoughts on this.

–
J.

16

Thus spake “Ken Stevens”:

If you have a look at my test code you will see that I am mocking a concrete
class. That capability exists in jmock. Perhaps it wasn’t available in
jmock when that article was written.

I’m tempted to use mockito because I always like learning new tools, but I
worry a bit about how much more widely used jmock is than mockito–you want
to pick technologies that are here to stay…

I’m inclined to go woth jMock, since at least one of us is already familiar
with it and it sounds like it does what we need. Make it so.

–
J.