Thanks! And yes, for only one or two expectations or verifications, Mockito syntax is shorter. But notice that Mockito requires one extra method call (”when”, “verify”) for each expectation/verification, while in JMockit there is typically only one Expectations/Verifications block for each test, no matter how many individual mock invocations the test executes.

For verifications in order, the JMockit syntax is more compact.
For example, in Mockito you would have:

InOrder inOrder = inOrder(firstMock, secondMock);
inOrder.verify(firstMock).add(”was called first”);
inOrder.verify(secondMock).add(”was called second”);

versus in JMockit:

new VerificationsInOrder() {{
firstMock.add(”was called first”);
secondMock.add(”was called second”);
}};

People assume that good documentation can be substituted by reading the javadocs and bean definitions. With inheritance this type of documentation becomes even more complex.

Another problem is that people misunderstand functional, procedural, object based and object oriented programming.

Frameworks such as swing, spring, joda, hibernate, etc should all use object orientation. Applications should then then develop using composition instead of inheritance. Again, there might be key concept that makes the application unique and a well designed object oriented structure makes sense - Object orientation is about extensible behavior.

Back to the original problem, it sounds like your complaint is about documentation.


FileTemplate mockFileTemplate; // declared as field or test parameter
...
CopyFileRule rule = new CopyFileRule("src.txt", "dest.txt");

new Expectations(rule) {{
rule.createFileTemplate("TYPE1"); returns(mockFileTemplate);
}};
...
new Verifications() {{
mockFileTemplate.copy("src.txt", "dest.txt");
}};


Works for all kinds of methods (even final and static) and also constructors. The real “rule.createFileTemplate” is not called.

I feel Java based design patterns and OO concepts lead to a lot of waste while writing code - it has got cruft. On the other hand, the OO model of JavaScript (and probably Ruby) is quite clean. Check them out. Functional programming solves lot of these problems by shrinking the abstraction down to a function level (equivalent to a Java “final” interface having exactly one method). Example: Clojure and Erlang. Erlang solves a lot of JVM-design issues as well.

com.sun.corba.se.spi.orb.ORB extends com.sun.corba.se.org.omg.CORBA.ORB extends org.omg.CORBA_2_3.ORB extends org.omg.CORBA.ORB

Coding is part science and part art. The overuse of inheritance may be scientifically sound but it is cumbersome for humans to read. Code, like art, should be pleasing to the eye.

I know programmers who pride themselves in the obfuscation of their code in the name of job security. These people should not be in the industry.