Re: [incquery-dev] Tests using Mockito

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Hi,

we should focus on the frameworks already in Orbit, as they are clean for the Eclipse IP (http://download.eclipse.org/tools/orbit/downloads/drops/R20130827064939/).

EasyMock 2.4.0, jmock 1.2.0 and Mockito 1.8.4 are available; from that we have some (limited) in-house experience with Mockito that is really easy to use.

About structuring: I would very much put (real) unit tests and integration tests into separate bundles because they are to be executed differently.

Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2013.09.29., at 21:45, Istvan Rath <rath@xxxxxxxxxx> wrote:

> Hi,  
> 
> I tend to agree with the argumentation behind using a mocking framework for complex tests such as the ones (presumably) required by something like the EVM.
> 
> However, the followings should be considered if we decide to move forward in this direction:
> - which mocking framework to use? Mockito, jMock, easymock, etc? Why?
> - how should the tests be structured? e.g. should mock tests be factored out to a separate test bundle?
> 
> Istvan  
> 
> --
> Istvan RATH, PhD
> Research fellow
> Budapest University of Technology and Economics
> Fault Tolerant Systems Research Group
> 
> 
> 
> On Sunday, September 29, 2013 at 6:49 PM, Dávid István wrote:
> 
>> Hi Zoli,
>> 
>> Thanks for the quick reply.
>> 
>>> can you convince us that it is worth to have it?
>> In general: I just find it hard to imagine a proper test package without test cases requiring mocking, stubbing, etc. Sure, it depends on the complexity of the product itself, but IncQuery is probably way beyond the level of being easy-to-test w/o supplementary frameworks like Mockito, EasyMock, perhaps PowerMock.
>> 
>> In this specific case: a conflict resolver has to be tested, which requires Activation instances in a ConflictSet. With Mockito, it goes like this:
>> Activation<?> mock1 = mock(Activation.class);
>> How would you that w/o a mock framework? Of course, a handful of clever util methods (a.k.a. "the custom testing framework" :) ) could handle this, and maybe there are such methods somewhere deep in IncQuery, but a) I wasn't able to locate them; and b) I just don't see the point to maintain another codebase just for that given the pretty wide selection of quite cool testing frameworks.
>> 
>> Let me mention projects Artop and Sphinx here as the perfect examples in this question. These two are very nicely covered with unit and integration tests, although there is just a ridiculously enormous amount of code dealing with instantiating mock, stub, dummy and fake objects, which could have been clearly avoided by using the proper tools. So I guess it's worth to at least think about employing Mockito or Easymock in a long-term perspective.
>> 
>> Cheers,
>> Steve
>> 
>> 
>> 2013/9/29 Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx (mailto:ujhelyiz@xxxxxxxxxx)>
>>> Hi,
>>> 
>>> in general, non-eclipse.org (http://non-eclipse.org) dependencies at least require extra administrative work, at worst require the qualification of external projects (more specifically legal approval is required for their entire code base). The simple case is if the dependency was already requested and approved for another project, then we could "hijack" their CQ, and also ask for our project.
>>> 
>>> According to the current case, I have looked at the IPZilla, and have found a use of Mockito 1.8.4 already approved for SWTBot. This means, if we _want_ to use Mockito, we could _request_ it via a "piggy-back" CQ ("simple way").
>>> 
>>> The question is: what are the benefit of using Mockito (in our current case - in general, it is a nice test framework to use :) )? What issue does it solve that is hard to overcome otherwise? István (Dávid): can you convince us that it is worth to have it? I am not exactly opposed to it, but I would like to see the benefits before starting the required administration to solve this.
>>> 
>>> In the meanwhile, Mockito (and any other non-eclipse.org (http://non-eclipse.org) dependency not required by Xtext) is not available in the target platform (by design).
>>> 
>>> Cheers,
>>> Zoli
>>> -- Zoltán Ujhelyi
>>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>>> 
>>> Fault Tolerant Systems Research Group
>>> Budapest University of Technology and Economics
>>> 
>>> On 2013.09.29., at 17:38, Dávid István <davidi@xxxxxxxxxxxxxx (mailto:davidi@xxxxxxxxxxxxxx)> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I just created an item in the Bugzilla for a LIFO conflict
>>>> resolver<https://bugs.eclipse.org/bugs/show_bug.cgi?id=418274>and
>>>> submitted a patch containing my implementation.
>>>> Also wrote some tests and placed them into plugin *
>>>> org.eclipse.incquery.runtime.tests*. However, they require Mockito which
>>>> isn't declared as a plugin dependency yet and don't know whether the target
>>>> platform the stuff is being built upon does provide it or not. Guess I
>>>> should just attach the tests regardless and someone will deal with the rest
>>>> of it on your side - could someone plz second this?
>>>> 
>>>> Cheers,
>>>> Steve
>>>> _______________________________________________
>>>> incquery-dev mailing list
>>>> incquery-dev@xxxxxxxxxxx (mailto:incquery-dev@xxxxxxxxxxx)
>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>> 
>>> _______________________________________________
>>> incquery-dev mailing list
>>> incquery-dev@xxxxxxxxxxx (mailto:incquery-dev@xxxxxxxxxxx)
>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>> 
>> _______________________________________________
>> incquery-dev mailing list
>> incquery-dev@xxxxxxxxxxx (mailto:incquery-dev@xxxxxxxxxxx)
>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>> 
>> 
> 
> 
> _______________________________________________
> incquery-dev mailing list
> incquery-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/incquery-dev