Java Peanuts

12 August 2015

So it is: three months ago I joined a new job position, switching from a big company to a little, agile one, after more than eight years of distinguished service :-).

Furthermore: I switched from a Java and JEE - centric technological environment to a more rich and various one - yet .NET and C# oriented.

So, my Java Peanuts will maybe become in the future C# Peanuts (or Node.js Peanuts, who knows...) or, more generally, Programming Peanuts: for the moment I'm still planning a little post series about my way from Java to .NET, so... if you are interested... stay tuned!

29 October 2012

I like TDD and testing automation and I'm used to consider essential a toolset providing automation for unit, integration, system tests and for code coverage analysis.

Switching from Java to JavaScript development, I tried to put together a Maven-based toolset that resembles the classic automation tools for Java: a testing framework (with a runner which I can run through mvn clean test) and a code coverage tool (which I can for example run through mvn verify, obtaining a graphical coverage report).

29 May 2012

A year ago I started to use mocking libraries (e.g., Mockito, EasyMock, ...), both for learning something new and for testing purpose in hopeless cases.

Briefly: such a library makes it possible to
dynamically redefine the behaviour (return value, thrown exceptions) of
the methods of the class under test, in order to run tests in a
controlled environment. It makes it possible even to check behavioural
expectations for mock objects, in order to test the Class Under Test's interactions with its collaborators.

A few weeks ago a colleague asked me: "[How] can I mock a static method, eventually using a mock library?".

In detail, he was looking for a way to test a class whose code was using a static CustomerLoginFacade.login(String username, String password) method provided by an external API (an authentication custom API by a customer enterprise).

Mockito (my preferred [Java] mocking library at the moment) doesn't support static method mocking, because Mockito prefers object orientation and dependency injection over static, procedural code that is hard to understand & change (see official FAQ). The same position appears even in a JMock-related discussion. PowerMock provides a Mockito extension that supports static methods mocking.

So, thanks to my colleague, I will analize the more general question "Ho can I handle external / legacy API (e.g., static methods acting as service facade) for testing purposes?".
I can identify three different approaches:

mocking by language: we can refer to the features of a dynamically typed programming language to dynamically change external / legacy
API implementation / behaviour. E.g., the login problem discussed
earlier can be solved in Groovy style, using the features of a language
fully integrated with the Java runtime:

CustomerLoginFacade.metaClass.'static'.login = {
return true;
};

Such an approach can be successfully used when CustomerLoginFacade.login's client code is Groovy code, not for old Java client code.

Architectural approach: mocking by design. This approach refers to a general principle: hide every external (concrete) API behind an interface (i.e.: coding on interfaces, not on concrete implementation). This principle is commonly knows as dependency inversion principle.

So, we can solve my colleague's problem this way: first, we define a login interface:

Ultimately, the interface defines an abstract gateway to the external authentication API: changing the gateway implementation, we can set up a testing environment fully decoupled from real customer' authentication provider
.

IMHO, i prefer the last mocking approach: it's more object oriented, and after all... my colleague called me once the more OO person I know :-).
I find this approach more clean and elegant: it's built only upon
common features of programming languages and doesn't refer to external
libraries nor testing-oriented dynamic languafe features.
In terms of design, too, I
think it's a more readable and more reusable solution to the problem,
which allows a clearer identification of responsibilities of the various
pieces of code: MyLoginService defines an interface, and every implementation represents a way to implement it (a real-life (i.e.: production) implementation versus the fake one).

However, method mocking (by library or by language, doesn't matter) is in
certain, specific situations a very useful technique, too, especially when code that suffers static dependencies (ClassUnderTest in our example) is an example of legacy code, designed with no testing in mind, and is eventually out of developer control.

[Incidentally: the solution adopted by my colleague was just that I have proposed (i.e., mocking by design)]

Credits: thanks to Samuele
for giving me cause to analyze such a problem (and for our frequent and
ever interesting design-related discussion). Thanks to my wife for hers
valuable support in writing in pseudo-English

24 May 2012

Interesting and useful guide to Javascript, whose "opinionate" approach
can reconcile with this loved-heated language. I found extremely interesting
the sections about functional programming and object oriented
programming: finally I've found a systematic presentation of OOP in
Javascript!