Comments for Helmut Rubasch

Comment on JAOO – Day 1 by Tammo Freese

Tammo Freese — Sun, 22 Oct 2006 13:10:52 +0000

Hello Helmut,

The extra replay() step in EasyMock is there by design, not by requirement.
It would be possible to do implement something like expect(mock).aMethod()
meaning the expect gives back an object which allows the definition of expected method calls for te mock. When I implemented EasyMock 2 last year, I opted against it for two reasons. First, it is harder to read, since the parentheses look misplaced. Second, it is not possible to chain responses, like in expect(mock.aMethod()).andReturn(“avalue”) – and this means that type checking for return values would not work. However, this decision may change in a future version of EasyMock.

Comment on JAOO – Day 1 by Helmut Rubasch

Helmut Rubasch — Thu, 12 Oct 2006 19:31:53 +0000

I am quite aware of the advantages of using pure language constructs (that the compiler can check and the IDE can autocomplete) in contrast to pure strings (that are of course not checked in any way during compile time) – in fact, this is one of the main reasons why we are using EasyMock in a project.
Still, some things are rather hard to get used to.
EasyMock’s record mechanism is really clever: everything is done at language level, no meta-language (Strings) necessary. Unfortunately this implies, that you need this extra replay step before you can really use the mock. I don’t know how many times I forgot to replay my mocks – still, you usually find out when trying to break your test, and it just won’t break because the mock is still in recording mode (or does mock.verify() even throw an exception if the mock has not been replayed?).
The ArgumentMatchers are also a very interesting way to accomplish their tasks (unfortunately hard to understand at first, too). Still jMock’s Constraints are slightlier more compact to use (no additional static method necessary).
So each, EasyMock and jMock, has some things that it can do a little better or easier than the other. In a perfect world we could take the best from both camps and build some kind of JEasyMock (to be pronounced like CheesyMock), but the two concepts are just too different for this to work. Even worse, the two base concepts of the two mock libs are in fact the reason for the shortcomings they have: with EasyMock it just won’t be possible to simply provide an ArgumentMatcher to the mock’s method call (the compiler would complain), and with jMock you’ll never have some more compile time verification. There is just no other way to do these things in their world.
After talking so much about the “problems” of those two mock libs: it’s still great to have fabulous tools like these. I could not imagine testing without something like this.

Comment on JAOO – Day 1 by Tammo Freese

Tammo Freese — Thu, 12 Oct 2006 10:03:01 +0000

“This of course poses a problem when you refactor your classes, but the key point is that your test will fail if you provide an invalid method name (jMock checks if a method with the provided name really exists). So you will find out if you did anything wrong.”

As the author of EasyMock, I also think this is one of the main points, but for another reason: Your tests *pass* first, then you apply a *refactoring*, and then your tests *fail*. So automated refactoring does not work correctly when using jMock mock objects.

Using method calls to define expectations in EasyMock provides more benefits than refactoring safety: Both autocompletion and generation work.

As an example for autocompletion, consider we have a String stored in the variable login, and an object of type User stored in the variable user. Now we like to check that User mock.someMethod(String) is called with the String stored in login, and we like our mock to return the object stored in the variable person.

jMock:
mock.expects(once()).method(“someMethod”).with( eq(login) ).will(returnValue(person));
EasyMock 2:
expect(mock.someMethod(login)).andReturn(person);

With jMock, autocompletion would not work on someMethod, and the autocompletion for login and person would be cluttered with other completions, as the type is not checked.

With EasyMock, autocompletion would work everywhere, and the autocompletion for login and person would not be cluttered with other completions, as the type is checked, i.e. the autocompletion at ‘someMethod(‘ would only show strings, and the completion at ‘andReturn(‘ would only show user objects.

As an example of code generation, let’s say you specify a call to a method which does not exist yet on the mocked interface:

jMock:
mock.expects(once()).method(“notYetExistingMethod”).with( eq(42) );
EasyMock:
mock.notYetExistingMethod(42);

With jMock, you have to run your tests to see that the method is missing, and then to define it by hand in the interface. With EasyMock, modern IDEs generate the method automatically for you.

Comment on JAOO – Day 2 by Helmut Rubasch

Helmut Rubasch — Thu, 05 Oct 2006 15:59:20 +0000

Hi Mario!

JAOO is still great, although the main part (the conference) is already over and “only” some tutorials are left (last one is tomorrow’s tutorial on “Crystal Clear” by the Master himself).
Well, and let’s put it this way: the Tuborg is better than I had remembered

see you soon back in Linz,
heli

Comment on JAOO – Day 2 by Mario Hochreiter

Mario Hochreiter — Wed, 04 Oct 2006 11:32:05 +0000

Hi Helmut!

I hope you enjoy your stay at JAOO. We are all looking forward to hear a report from your visit soon (especially about the quality and taste of danish beer

Best Regards
Mario

Comment on It ain’t easy to be simple by Helmut Rubasch

Helmut Rubasch — Tue, 08 Aug 2006 20:34:24 +0000

Very good point, Mario. Simplicity has to start way before implementation, design or even architectural planning takes place. It is already the phase of gathering and analysing requirements and planning the overall functionality of the system where a lot of emphasis should be put on making everything as simple as possible. You mentioned the problem that customers and developers live in two different worlds. The customer knows his domain and business and he knows which problem he wants solved (though he usually does not know how to solve it). The developers know their business, which in most cases has not much in common with their customer\'s. This commonly called impedance mismatch makes it difficult for these groups to communicate efficiently, which may be a reason why they usually don\'t communicate (another reason is of course that the customer cannot be expected to answer questions of hundreds of developers). Even bridging this gap with someone like a business analyst does not necessarily solve this problem. This person has to translate the problem from the customer\'s domain so that the developers understand it. He also translates questions from the developers and asks them to the customer. Aside from the rare case that this person is an expert in both domains, information loss is imminent. Enter simplicity. If the problem domain is simplified (or abstracted) as much as possible, the business analyst is much more likely to understand exactly what the customer wants. On the other hand it\'s much easier to convey the real problem to the developers without all of this white noise around. In a perfect world, the customers and developers might even use the same abstractions or metaphors for the same thing. Hey, in this perfect world they might even talk face to face with each other!

Comment on It ain’t easy to be simple by Mario Hochreiter

Mario Hochreiter — Sat, 05 Aug 2006 09:06:11 +0000

Hi Heli!

I agree with you that Software Engineering should follow the KISS principle and that software architecture and classes should be describable with a few words.
Albert Einstein also said that people who do not have proper and deep understanding about the topic they are talking tend to complicate things. The problem in software engineering is that the customer mostly do not understand the topic he is speaking about. Also the complexity of requirements and user expectations have increased over the last years. This leads to the problem that the probability of failures increases due to size and complexity. Take Microsoft’s Vista for example, the orignial requirements for Vista were to ambitious that even a company like Microsoft could not realize.

I think to avoid or reduce complexity for an overall system is only possible in an isolated environment or with an adequate amount of time. The only possiblity in my opinion to reduce complexity is to invest a lot of time to define and priortize the requirements with the customer. As we all know this causes expenses nobody wants to pay. In most commercial projects the policy maker are economic people with no proper understanding in the field of software engineering. Furthermore, the software engineer mostly has no knowledge in the domain of the customer. Add the challenge of rapid ongoing change in the environment of software engineering. To compete this challenges i think you need a very motivated and talented team that gets support from business processes.