ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Adopting mock framework (ex. Mockito) for unit tests
Date Tue, 16 Jan 2018 19:52:39 GMT
Agree with Igor’s opinion. If it simplifies Cassandra integration testing cycles and maintenance
then we should go for it for *this* component only. No need to push it to all the component
we have.


> On Jan 16, 2018, at 10:24 AM, Igor Rudyak <irudyak@gmail.com> wrote:
> It will be good to clarify what do you mean by adopt? Can't we just start
> using it as is for specific cases?
> I understand that there are some cases which probably not the best scenario
> for Mockito. At the same time there are lot's of other cases (like in
> IGNITE-6853 <https://issues.apache.org/jira/browse/IGNITE-6853>) when tests
> could be significantly simplified using mock framework.
> May be it makes sense to introduce mock framework at the parent POM and
> then just reuse it at specific modules for the test cases where appropriate?
> Igor
> On Tue, Jan 16, 2018 at 4:27 AM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
>> Mocking is a good testing technique, but over years we failed to adopt it
>> in Ignite. The reason is high project complexity, when a lot of components
>> are interact with each other, and it is very hard to extract clean
>> interfaces out of it. We definitely could do better with our OOP, but you
>> should remember that good OOP comes at costs - more code, more time, worse
>> performance (due to lot's of various wrappers). I think of it as a normal
>> case based on my experience - I worked with a lot of code bases (Postgres,
>> MySQL, Cassandra, Hazelcast, to name a few) - and none of them are clean
>> enough to adopt mocking easily. You hardly find clean code in
>> performance-demanded projects.
>> TDD is also controversial approach for complex projects. It works good when
>> you work on concrete specification of the task and know the outcome in
>> advance. But it doesn't work for Ignite - typically we do not know outcomes
>> of our activities in advance. Things could change dramatically during
>> developments, so TDD for us is waste of time.
>> On the other hand, today we are able to "mock" a lot of internal components
>> by hands to test various complex cases. E.g. one can easily add his own IO
>> manager to test message drops. You can do virtually everything you need.
>> For this reason I doubt mocking is the right approach we should think of
>> for core development. But it may do great job for integration with
>> 3rd-party products.
>> Vladimir.
>> On Tue, Jan 16, 2018 at 1:34 PM, Alexey Kukushkin <
>> kukushkinalexey@gmail.com
>>> wrote:
>>> Hi Jason,
>>> I heartily support unit testing practices and introducing a mocking
>>> framework into ignite development environment. Today I can hardly find a
>>> single unit test in Apache Ignite, which does not allow me to use the
>> best
>>> TDD and CI/CD practices like running tests on every commit (or even on
>>> every "save file"!).
>>> I recently started developing an isolated component based on Apache
>> Ignite
>>> and, since I use TDD and write lots of unit tests, I had to add a mocking
>>> framework to my project. I started from Mockito (version 1.something) and
>>> found I could not do some things with Mockito due to Ignite currently not
>>> designed for unit testing. I believe I could not find a way to mock some
>>> private initialisation block with Mockito.
>>> Thus, I switched to JMockit - it allowed me to mock what I wanted and it
>>> seems you can mock virtually everything with JMockit.
>>> I know that a situation when you have to mock something private or static
>>> indicates not very modular and extendable design but you do not have much
>>> of a choice with Ignite since you already have huge amount of code and it
>>> would be really hard to refactor everything to make it testable since
>>> Ignite development process is heavy and your project could be stuck
>> waiting
>>> for Ignite changes.
>>> Did you consider JMockit over Mockito? It seems JMockit supports both
>>> record-replay-verity and setup-run-verify models as well as BDD semantics
>>> API.

View raw message