jkube
jkube copied to clipboard
eclipse-jkube
[EPIC] Migrate to Mockito mocking framework from JMockit in unit tests
Description
Right now we're using JMockit in our tests for mocking the behavior of classes. We're discussed this in past as well but never got any chance to create an issue for this. We should try to move to Mockito which is a more modern mocking framework.
Goals
- Remove JMockit dependency
- JMockit expectations should be replaced by when() statements (Mockito mocks)
- JMockit verifications should be replaced by verify() statements (Mockito verifications)
- Assertions should be replaced by AssertJ
- Tests should be evaluated and refactored if applicable
Since this can be a big task, I think we should try doing it step by step removing Jmockit from each module and using mockito instead. Here are the modules which use Jmockit:
- build/api https://github.com/eclipse/jkube/issues/1585
- build/service/docker https://github.com/eclipse/jkube/issues/1586
- build/service/jib https://github.com/eclipse/jkube/issues/1587
- common-test https://github.com/eclipse/jkube/issues/958
- common https://github.com/eclipse/jkube/issues/1545
- config/image https://github.com/eclipse/jkube/issues/1584
- config/service https://github.com/eclipse/jkube/issues/1588
- enricher/api https://github.com/eclipse/jkube/issues/1589
- enricher/generic https://github.com/eclipse/jkube/issues/1591
- enricher/specific https://github.com/eclipse/jkube/issues/1592
- generator/api https://github.com/eclipse/jkube/issues/1593
- generator/java-exec https://github.com/eclipse/jkube/issues/1594
- generator/karaf https://github.com/eclipse/jkube/issues/1595
- generator/webapp https://github.com/eclipse/jkube/issues/1596
- jkube-kit-micronaut https://github.com/eclipse/jkube/issues/1597
- jkube-kit-quarkus https://github.com/eclipse/jkube/issues/1598
- jkube-kit-spring-boot https://github.com/eclipse/jkube/issues/1599
- jkube-kit-thorntail-v2 https://github.com/eclipse/jkube/issues/1600
- jkube-kit-vertx https://github.com/eclipse/jkube/issues/1601
- jkube-kit-wildfly-jar https://github.com/eclipse/jkube/issues/1602
- resource/helm https://github.com/eclipse/jkube/issues/1603
- resource/service https://github.com/eclipse/jkube/issues/1604
- watcher/api https://github.com/eclipse/jkube/issues/1605
- watcher/standard https://github.com/eclipse/jkube/issues/1606
- kubernetes-maven-plugin https://github.com/eclipse/jkube/issues/1607
- openshift-maven-plugin https://github.com/eclipse/jkube/issues/1608
We should try refactoring each of these modules one by one in order to achieve this migration.
@rohanKanojia, I have experience in writing unit tests using Mockito and would love to contribute to this migration. Thank you
@praneethjreddy : awesome, Thanks a lot. I wanted to get Marc's opinion on this one(He's on PTO right now and would be back next week). I think you can pick this up once he approves.
As we previously discussed, this is something we want to do. However, this can't be started until we merge the current work on Gradle Plugins. And also, individual issues should be open for classes, suites, modules or whatever we want to break down this task into. It would be too hard and would take too long to accomplish this in a single PR.
We should try to move to Mockito which is a more modern mocking framework.
Also, this is not the argument for switching to Mockito. For Gradle plugins we required some features specific to Mockito in order to keep things simple. In addition, the newer versions of Mockito don't require the use of PowerMock for special use cases and mock declaration is much more readable than JMockit. Since for Gradle we require Mockito and everything we have implemented using JMockit can be reimplemented with Mockito too, we should move everything to Mockito for consistency.
Umm, okay I'm fine with waiting till we merge feat/gradle-plugin into master branch. I thought we can take help from community members to achieve this since and resolving conflicts would not be that difficult even if we start now.
I thought we can take help from community members to achieve this since and resolving conflicts would not be that difficult even if we start now
Yes, sure, but we don't have the CQ approved for this and we will have some conflicts in the pom.xml since this is a new dependency (Mockito dependency was added in scope of #31). ----> It's hard maintaining a separate branch that affects completely separate modules, if we start adding changes to poms, it will get harder and harder.
In addition, just like we are doing with the Hamcrest to AssertJ replacement (e.g. #792) we need to create individual tasks for this, so that more than one contributor can work on the same goal at once.
@rohanKanojia @manusa I'm interested in working on this. Can i go ahead and create a issues for any of the child module and start working on it ?
Hello, I want to contribute to open source and I found this project beginner friendly. Can anyone guide me?
@nabeelkhan10 : Sorry but @baruKreddy would be working on this Epic under Google Summer of Code this summer. If you want I can create some other good first issue for you.
@nabeelkhan10 : Sorry but @baruKreddy would be working on this Epic under Google Summer of Code this summer. If you want I can create some other good first issue for you.
Yes that would be great
Perhaps we can create sub issues/tasks under this PR to start working on @manusa @rohanKanojia.
Perhaps we can create sub issues/tasks under this PR to start working on @manusa @rohanKanojia.
Yes, we're working on this
hey there! I am a newbie here and I have used Eclipse a lot and still using it, after a long thought I finally decided to start contributing to open source and Eclipse will be my first. So guys please suggest to me how can I get started in contributing. Any help and resource will be much valuable to me. Thanks in advance
@rohanKanojia @manusa Hii! I am new to open-source contribution. I have sound knowledge of JAVA and IntelliJ and I have been using it since long. It would be really helpful if you guys could guide me and suggest me some good resources.
@baruKreddy : Shall I assign this issue to you?
I also want to contribute as my first open source contribution can you assign me one too?
I believe this once can be closed now. @baruKreddy congrats for completing the project! Best of luck in your future endeavors, and I hope they involve in one way or another contributing to free/libre open source software :rocket:
