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 <voze...@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 < > kukushkinale...@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. > > >
