David M. Karr (64) [Avatar] Offline
#1
I haven't read any of the available sections yet, but I looked at the TOC, and I have some concerns.

I have a strong feeling that many people considering this book will be looking at it for writing tests for Gradle plugins. There may be development teams whose primary uses of Groovy are for their custom Gradle plugins and (hopefully) their Spock tests.

Make sure that you have several examples of different kinds of Gradle plugins, and effective tests for those plugins.
Kostis Kapelonis (53) [Avatar] Offline
#2
Hello dkarr

The book is aimed at Java developers that have zero Groovy experience. A whole chapter is devoted to teaching Groovy just enough for Spock tests.
It seems to me that people who are writing Gradle plugins are not Groovy beginners (correct me If I am wrong). The book also does not use or require Gradle.

I am thinking whether I need to include a chapter on how to test Groovy code (instead of Java) with Spock.

So to sum up the book is much more generic and has a wider audience than writing Gradle plugins. The TOC is still work in progress (especially
the last chapters are very fuzzy at the moment) but introducing Gradle as a required knowledge would certainly limit the book audience (something that
I am against at).

Can you point me to some tutorials on Gradle plugin testing that you like?Is there something fancy that they do with Spock that needs more explanation?

Have you also looked at "Gradle in Action" by Manning? I think it contains some testing for Gradle plugins (can't remember if it is with Spock or JUnit)

Kostis
David M. Karr (64) [Avatar] Offline
#3
Kostis Kapelonis wrote:Hello dkarr

The book is aimed at Java developers that have zero Groovy experience. A whole chapter is devoted to teaching Groovy just enough for Spock tests.
It seems to me that people who are writing Gradle plugins are not Groovy beginners (correct me If I am wrong). The book also does not use or require Gradle.

The last Rebel Labs developer survey found that Gradle was the one technology that most developers were interested in learning. From what I could see, this number was even higher than Groovy. There will be developers whose first involvement with Groovy is from trying to learn Gradle and write custom Gradle plugins, and the tests for those plugins.

I'm not suggesting that the book should require Gradle, but I'm telling you that a large percentage of the people thinking about this book will be new to many of these technologies, but they will likely be initially driven there because of their desire to learn Gradle.
Kostis Kapelonis wrote:
I am thinking whether I need to include a chapter on how to test Groovy code (instead of Java) with Spock.

So to sum up the book is much more generic and has a wider audience than writing Gradle plugins. The TOC is still work in progress (especially
the last chapters are very fuzzy at the moment) but introducing Gradle as a required knowledge would certainly limit the book audience (something that
I am against at).

Can you point me to some tutorials on Gradle plugin testing that you like?Is there something fancy that they do with Spock that needs more explanation?

Have you also looked at "Gradle in Action" by Manning? I think it contains some testing for Gradle plugins (can't remember if it is with Spock or JUnit)

Kostis

Sure, I looked at GiA, but it had very rudimentary coverage in this area.
Kostis Kapelonis (53) [Avatar] Offline
#4
There is a difference between using Gradle and creating custom Gradle plugins. The latter requires obviously more Groovy knowledge.

Let me put it in another way. Assume that I include an example with testing a Gradle plugin as you suggest. This means that the reader must know

1)Java (because the core code is written in Java)
2)Groovy (in order to understand Gradle code)
3)Gradle API, plugin writing (in order to write the plugin code)

before even getting to the Spock part. I think that all this knowledge needs more than one book.

As it is now, I assume knowledge of the first list item only.

But I am still curious, is Spock testing a Gradle plugin really that special from vanilla Spock testing? Why do you think that strong focus is needed on this?
If I already know everything about Spock, what stops me from testing a Gradle plugin (other than understanding the Gradle API)?

(Also note that in the same survey you mention, JUnit dominates unit testing and Spock is a minority. So if something needs advertising to Java developers
then that is Spock and not Gradle).

Kostis
344590 (1) [Avatar] Offline
#5
One of my motivation for buying this MEAP book is to understand how to write tests for gradle plugins, because I see that gradle plugin developers use Spock. For example the axion-release-plugin, or the some of the nebula plugins.
Kostis Kapelonis (53) [Avatar] Offline
#6
Hello

The book is about Spock. So if you want to learn how Spock works in general (blocks, parameterized tests, mocking/stubbing, integration tests, functional tests etc), then you are welcome to read it. You can then apply this knowledge to ANY project (including gradle plugins)

If you specifically want to target Gradle plugins (which is one of the many things that can be tested by Spock) and you want to learn about the Gradle API, then you should also buy a Gradle book (such as Gradle in action) that explains Gradle internals and gives hints on how to test plugins.

Here is the URL http://www.manning.com/muschko/

So to sum up, if you want to test Gradle using Spock, I think that you should read two books (one on each subject).

Hope that helps.
Kostis Kapelonis (53) [Avatar] Offline
#7
For your information

I asked a question regarding the topic of Gradle testing with Spock in the official Gradle forum.

Lots of new things are in the pipeline for that matter.

https://discuss.gradle.org/t/writing-unit-integration-tests-for-gradle-plugins/10492/2

Kostis