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.
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.
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)
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.
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.
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.
I would also make heavy use of this feature, exspecially in connection with Spring.
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
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
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.
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