Just thought I'd share - after a second pass at this I was able to avoid
PowerMock when modifying the class under test to use constructor DI. I
think initially I was a bit reluctant to modify the production code here
but on a second look I think it was the right thing to do. Just wanted to
share
I don't think you necessarily need to redo your work Ryan. I just think
something has been left behind by the test. It looks like a mock made
its way into the JMX "Server" in the log4j code.
On 11/14/18 10:57 AM, Ryan McMahon wrote:
I will write up a story to address the use of PowerMock in
I've created a Jira to track the elimination of PowerMock from these tests
in particular, which will probably involve doing the major refactoring
mentioned in item #4 in my previous email.
https://issues.apache.org/jira/browse/GEODE-6052
On Wed, Nov 14, 2018 at 10:57 AM Ryan McMahon
wrote:
> I
I will write up a story to address the use of PowerMock in these JMX tests
in particular. I remember attempting to avoid PowerMock when writing this
test, because I agree that it should be avoided. I just want to explain my
thinking so that we can discuss what would have been a better approach.
I'm running into the same PowerMock problem that Kirk hit. I can find
only one test that uses PowerMock and invokes registerMBean -
MBeanJMXAdapterTest. This is a new test that was checked in mid-October.
commit 76420dcd93e17f009aa73ca8188d135158358323
Author: Ryan McMahon
Date: Wed Oct 17
I think we should try really hard to avoid using PowerMock. If you have
some code that you need to use PowerMock to make it testable, please
consider refactoring the code to a) avoid statics, b) pass all dependencies
in via the constructor.
The following was spit out by one of my unit test runs. N
