Looks we came to a consensus. Jason, please change the PR the way you say > I will change my PR to add the dependency at parent POM level and use it only > for my test in ignite-cassandra.
Igor should review it shortly. — Denis > On Jan 16, 2018, at 5:33 PM, Jason Man, CLSA <jason....@clsa.com> wrote: > > Agree with Vladimir/Denis/Igor on using it for specific tests/components. > > What I meant by 'adopt' is to be able use it to facilitate testing of Ignite > code somewhere. It doesn’t mean we should change our overall testing > approach overnight and try to use it everywhere. > > In the case of testing code that integrates 3rd party tools (Postgres, MySQL, > Cassandra), I think it definitely simplifies the test development effort as > well as the time it takes to run the tests. > > @Alexey, I haven't explored using JMockit, but Mockito was just a very > popular mocking framework and widely used so it would be less of a learning > curve for most developers: > https://trends.google.com/trends/explore?q=jmockit,mockito > > I will change my PR to add the dependency at parent POM level and use it only > for my test in ignite-cassandra. > > Jason > > -----Original Message----- > From: Denis Magda [mailto:dma...@apache.org] > Sent: Wednesday, January 17, 2018 3:53 AM > To: dev@ignite.apache.org > Subject: Re: Adopting mock framework (ex. Mockito) for unit tests > > 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. > > — > Denis > >> On Jan 16, 2018, at 10:24 AM, Igor Rudyak <irud...@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 >> <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. >>>> >>> > > The content of this communication is intended for the recipient and is > subject to CLSA Legal and Regulatory Notices. > These can be viewed at https://www.clsa.com/disclaimer.html or sent to you > upon request. > Please consider before printing. CLSA is ISO14001 certified and committed to > reducing its impact on the environment.
