weirddev

Open full view…

Spock without Mockito

stigmaleon
Sat, 16 Sep 2017 09:02:33 GMT

Hi. Is it possible add template for groovy spock without mockito?

Yaron
Sat, 16 Sep 2017 15:26:18 GMT

Hi stigmaleon, I would like to give the users the option to create new templates, possibly from existing ones and customize them as they wish. I don't think I can push that feature any time soon. As a short term solution, if you would like to add support for a different mocking framework, please let me know. I might be able to pull it off quickly. Adding a template with no mocking support seems less appealing to me. I think that adding an option to avoid mock generation when the user invokes any template might be useful and may address your needs. By the way, mocks should not be generated by any template, if there is no need to. Identifying when there is a need to generate mocks can be tricky and not all users may agree if a mock should or should not be generated for a given use case. If you find a use case where you think its obvious that mocks should not be generated for, please let me know.

kriegaex
Wed, 26 Sep 2018 06:20:16 GMT

What do you mean by "template without mocking support"? Spock has its own built-in mocking features. Not using Mockito is the default case for Spock users, thus this question makes a lot of sense IMO. I think @stigmalion likes to get Spock mocks generated instead of Mockito mocks.

Yaron
Wed, 26 Sep 2018 12:12:53 GMT

Thanks for the clarification @kriegaex! Yes this defiantly makes sense. I may have misunderstood the request to swap the mocking framework ( _Spock MockingApi_ instead of _Mockito_) as a request to ditch the mocking functionality from generated Spock tests. I'll prioritize this feature request. The main difficulty here is to replace Mockito's auto injection functionality (using @InjectMocks ) with explicit initialization of the tested class, while trying to support various initialization patterns ( setters, constructors, private members - injected by DI frameworks or static factory methods)

dotJack / Kristjan
Wed, 29 May 2019 08:02:14 GMT

Hey, I'm also very interested in this. I use the testMe spock with mockito as my base for all tests and then just manually remove all the Mockito stuff and replace it with Spock specific implementations. Also, for since 1.2 or 1.3, we have @SpringBean which you can use to inject a mock into the context (if you boot it up with Spring), this allows @Autowired to just inject your mocks into whatever.

Yaron
Thu, 30 May 2019 07:46:10 GMT

Great feedback dotjack, I've been considering the effort supporting a Sprint integration test on a Junit+Java/Groovy stack. I wasn't aware of the new features in Spock for testing Spring beans. A Spock+Spring test template definitely seems appealing. Such implementation will probably require an optional dependency on IJ Spring plugins, from the Ultimate edition I also took note that there's a demand for a template based on Spock mocks rather than Mockito. Effort wise, I'm not sure I can provide a proper support for this within a short development iteration. So perhaps a "thin" featured template, as an intermediate solution, that will at least provide a better startup point and won't force you to waist time on getting rid of the generated Mockito artifacts - will still have some value.

dotJack / Kristjan
Thu, 30 May 2019 12:38:20 GMT

That would be amazing especially if this can be grown further because every shop has their own setup logic, having a customisable template system would be amazing. Even inside one company, there are loads of differences between teams - from just general setup guides to massive stack differences.

mhuelfen
Tue, 02 Jul 2019 13:27:41 GMT

I would also make heavy use of this feature, exspecially in connection with Spring.

Yaron
Tue, 02 Jul 2019 14:57:39 GMT

mhuelfen, dotjack - it's well noted. Supporting customizable templates and adding a pure spock template - are the top priorities for the next release/s by popular demand. Thanks for the feedback

Yaron
Tue, 06 Oct 2020 21:45:54 GMT

mhuelfen, dotJack / Kristjan, kriegaex, stigmaleon, uweschaefer, - Many thanks to all of you, for raising these issues. The configuration option to customize the generated test code - the test templates - had been added in the new plugin version - v4.0.0. Theres a short doc page about it - https://weirddev.com/testme/custom-templates/. Hope this helps somehow. Sorry it took so long :) I just couldn't find the time

kriegaex
Sat, 10 Oct 2020 02:43:55 GMT

First of all, thanks for the option to define custom templates. Sorry for criticising again, but the two default templates for Spock are still using Mockito. 99% of Spock use cases will never use Mockito because Spock has its own mocks integrated into the framework, like I said before. So as nice as it is to be able to define my own templates, your extension should create tests without Mockito for Spock, otherwise no Spock user will adopt your solution.

Yaron
Sat, 10 Oct 2020 08:54:39 GMT

Thanks for the feedback kriegaex, I took a note that there's need to provide proper support for Spock mocking framework out of the box. Will try to prioritize this going forward

rain_hu
Wed, 15 Feb 2023 02:50:45 GMT

FYI with no mockito template: #parse("TestMe macros.groovy") #set($hasMocks=$MockitoMockBuilder.hasMockable($TESTED_CLASS.fields)) #if($PACKAGE_NAME) package ${PACKAGE_NAME} #end import spock.lang.* #parse("File Header.java") class ${CLASS_NAME} extends Specification { #foreach($field in $TESTED_CLASS.fields) #if($MockitoMockBuilder.isMockable($field) && !${field.isStatic()}) def ${field.name}Mock = Mock($field.type.canonicalName) #end #end def $StringUtils.deCapitalizeFirstLetter($TESTED_CLASS.name) = new ${TESTED_CLASS.name}(#foreach($field in $TESTED_CLASS.fields) #if($MockitoMockBuilder.isMockable($field) && !${field.isStatic()}) ${field.name}Mock, #end #end) #foreach($method in $TESTED_CLASS.methods) #if($TestSubjectUtils.shouldBeTested($method)) def "test #renderTestMethodNameAsWords($method.name)"() { given: // todo mock dependency methods when: // todo fill params,and get result def result = $StringUtils.deCapitalizeFirstLetter(${TESTED_CLASS.name}).${method.na me}() then: // todo verify result result != null } #end #end }

Yaron
Thu, 23 Feb 2023 19:51:01 GMT

Thanks for contributing this. I think the main thing currently lacking in TestMe to support this template - is locating the most relevant test subject constructor.

kriegaex
Fri, 24 Feb 2023 07:10:45 GMT

Thanks for the contribution. I have not tried yet, because currently I am not using the plugin due to its long-standing lack of proper Spock templates. Just a quick question for my technical understanding: I still see Mockito references in the macro. To me it looks as if Mockito is used internally to determine whether fields are non-static and mockable. If so, regular Spock mocks are created. I.e., Mockito is just a depencency of this plugin, not necessary to run the generated Spock tests. Is that correct?

Yaron
Sat, 25 Feb 2023 21:08:36 GMT

the _MockitoMockBuilder_ util, being used in the Velocity file template above, has some methods that are generic. If another mock library would be supported, will need to change that, it's confusing. Tests can be generated without Mockito

kriegaex
Mon, 27 Feb 2023 06:38:59 GMT

I reinstalled the plugin, copied the code pasted here, somewhat tediously fixed several bugs caused by it having been inserted as normal text instead of as a code block, and tested it. It does not work well, i.e. inserting non-existing all arguments constructors and trying to mock final fields. As the TODO comments in the snippet imply, it is also and not generating much helpful test code. But thanks for the contribution, it is a good first step.

kriegaex
Mon, 27 Feb 2023 07:02:20 GMT

Like I said, this macro is not helping me much, but if someone wants to take it from here, copy the following code block: ``` #parse("TestMe macros.groovy") #set($hasMocks=$MockitoMockBuilder.hasMockable($TESTED_CLASS.fields)) #if($PACKAGE_NAME) package ${PACKAGE_NAME} #end import spock.lang.* #parse("File Header.java") class ${CLASS_NAME} extends Specification { #foreach($field in $TESTED_CLASS.fields) #if($MockitoMockBuilder.isMockable($field) && !${field.isStatic()}) def ${field.name}Mock = Mock($field.type.canonicalName) #end #end def $StringUtils.deCapitalizeFirstLetter($TESTED_CLASS.name) = new ${TESTED_CLASS.name}(#foreach($field in $TESTED_CLASS.fields) #if($MockitoMockBuilder.isMockable($field) && !${field.isStatic()}) ${field.name}Mock, #end #end) #foreach($method in $TESTED_CLASS.methods) #if($TestSubjectUtils.shouldBeTested($method)) def "test #renderTestMethodNameAsWords($method.name)"() { given: // todo mock dependency methods when: // todo fill params,and get result def result = $StringUtils.deCapitalizeFirstLetter(${TESTED_CLASS.name}).${method.na me}() then: // todo verify result result != null } #end #end } ```

Yaron
Thu, 02 Mar 2023 18:27:38 GMT

Thanks kriegaex, this is indeed helpful for start. with better support from the Build Util's, it may eventually meet your requirements