New check idea OnlyMockIntefacesCheck

10 views
Skip to first unread message

Paul Campbell

unread,
Jul 30, 2016, 2:08:29 PM7/30/16
to Sevntu Checkstyle
Hi,

I'm interested in developing a rule to prevent me from attempting to mock(), @Mock or spy() a class in my unit tests. I'd like to only allow mocking of interfaces.

I think this would work well with the DesignForExtension rule which promotes final methods in classes. This does, however, making those classes difficult to mock. Unfortunately, when using the DesignForExtension rule, the real final method is called in the unit test and there are now explicit warnings that the class hasn't been mocked as expected.

Can checkstyle even be configured to check tests?

Assuming it can, I'd imagine specifying a default set of methods, from the various mocking libraries, to check against. e.g. org.mockito.Mockito.mock(), org.mockito.Mockito.spy(), org.mockito.Mock, org.easymock.EasyMock.mock(), etc to verify the usage of.

Any advice on where to where to start would be greatly appreciated.

Thanks,
Paul Campbell

Roman Ivanov

unread,
Aug 4, 2016, 8:14:04 AM8/4/16
to sevntu-c...@googlegroups.com
Hi Paul,

before any implementation please make sure that you understand limitations of Checkstyle

it is hard for checkstyle to reliably distinguish methods with the same name. We have no type information during validation process. We could rely only on names and some naming standards.

Look like you want to violate usage of some methods from certain types.
Example: type="org.mockito.Mockito", method="spy()".

Your Check could validate imports to detect type usage and after that traverse all method calls for "spy()" method call.

Problems: 
1) how to define arguments of methods in configuration (in other case there will be a lot of false-positives on overloaded methods)
2) Static imports.
3) false-positives on methods that are named the same way but hosted in different type (imagine imports of mock and Easymock in the same UT).

All of that problems are resolvable, and it is possible to make some custom to your code solution. There are bunch of examples of checkstyle extensions , example - https://github.com/sevntu-checkstyle/sevntu.checkstyle .

Let me know if you need some other advise or help. 

thanks,
Roman Ivanov

Paul Campbell

unread,
Aug 4, 2016, 9:44:36 AM8/4/16
to sevntu-c...@googlegroups.com
Hi Roman,

It's not looking promising that Checkstyle can do what I wanted. I did eventually find the limitations page and felt that the last two points sank my idea. Can't determine the inheritance of a class and only having access to a single file at a time. I hadn't realised that Checkstyle was looking at the uncompiled source files; so resolved type information for parameters isn't available.

I imagine custom code could read in a referenced import to see if it was an interface or not, but it wouldn't be able to do that with interfaces or classes from a dependency.

For now, I'll investigate other avenues. I'm thinking just now of creating a maven plugin using ASM to examine the bytecode. I've not used ASM or dealt with bytecode before, so I could be setting myself on a wild goose chase. But I'll see what I learn on the way.

Thanks for your reply.

Paul Campbell

--
You received this message because you are subscribed to the Google Groups "Sevntu Checkstyle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sevntu-checkst...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Roman Ivanov

unread,
Aug 5, 2016, 4:53:48 AM8/5/16
to sevntu-c...@googlegroups.com

Please take a look at other java static analysis tools , it might be better to extend them for your task , rather than do all from scratch.

Look at our pom.xml and CIs , we use almost all known tools.

Pay attention to forbiddenapis tool.


To unsubscribe from this group and stop receiving emails from it, send an email to sevntu-checkstyle+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sevntu Checkstyle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sevntu-checkstyle+unsubscribe@googlegroups.com.

Paul Campbell

unread,
Aug 5, 2016, 4:55:38 AM8/5/16
to sevntu-c...@googlegroups.com
I will do. Thanks for the pointers.

Paul

To unsubscribe from this group and stop receiving emails from it, send an email to sevntu-checkst...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sevntu Checkstyle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sevntu-checkst...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sevntu Checkstyle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sevntu-checkst...@googlegroups.com.

Paul Campbell

unread,
Aug 7, 2016, 6:39:52 AM8/7/16
to sevntu-c...@googlegroups.com
It's a pity AbstractTypeAwareCheck is deprecated. Given it is used by tests such as JavadocMethod, is it's deprecated because it will eventually `go away` or just to discourage creating checks based on it as they would be 'unstable'?

For my check idea, an unstable test that, hopefully, worked most of the time would be better than no check.

Roman Ivanov

unread,
Aug 7, 2016, 9:27:36 AM8/7/16
to sevntu-c...@googlegroups.com
yes it is deprecated , as current implementation is extremely fragile and produce more problem than solve.

yes it is go away, as we start reimplementing javadoc checks, to parse javadoc reliably by javadoc grammar - http://checkstyle.sourceforge.net/writingjavadocchecks.html , it will be deleted from library at all.

just to discourage creating checks based on it as they would be 'unstable'?

I highly recommend to stay away from it, or do it on your own risk and reason.


To unsubscribe from this group and stop receiving emails from it, send an email to sevntu-checkstyle+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sevntu Checkstyle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sevntu-checkstyle+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sevntu Checkstyle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sevntu-checkstyle+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sevntu Checkstyle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sevntu-checkstyle+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages