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 <[email protected]> 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 <[email protected]> > 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 < >> [email protected] >>> 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. >>> >>
