As discussed, updated the PR with the change to put the mockito version at the parent POM and using it on the cassandra module.
https://github.com/apache/ignite/pull/3088 Thanks. -----Original Message----- From: Denis Magda [mailto:dma...@apache.org] Sent: Wednesday, January 17, 2018 9:55 AM To: dev@ignite.apache.org; Igor Rudyak Subject: Re: Adopting mock framework (ex. Mockito) for unit tests 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. 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.
