Kostis Kapelonis

Hello Deepak

Here are my questions

1) At the moment there are several "distributions" of Kubernetes and I see that your book covers already a lot of them (Openshift, GCE, Tectonic). At the moment Kubernetes is fairly new and it is easy to move applications from
one vendor to the next. As time progresses, I have a fear that companies will add their own incompatible "extensions" to their K8s distributions in order to lock-in customers and not allow them to move freely between competitors.

What is your view on this? Do you see this happening in the future?

2) There is a great deal of documentation on K8s vs Docker swarm and K8s vs Mesos. However there is very little information on K8s vs Hashicorp Nomad. Any thoughts on this?

3) I don't see any chapter that deals with K8s Security. Do you cover this in your book? What should I do if I want to run a PCI compliant application on K8s today? How can I approach this problem?

Thanks

Kostis

Hello Harry

I found the solution!

First of all chapter 7 has only Spock tests. I used chapter1 that has both JUnit and Spock tests.

The solution is the following
1)Install the Groovy plugin in Sonar. Login as admin/admin and go to administration->System->update center tab
2)Add the following property in the pom file <sonar.tests>src/test/groovy,src/test/java</sonar.tests>

If you do this both Spock and JUnit tests are shown correctly!
See attached screenshot


Enjoy!

Hello Harry

You are correct. I verified this issue. However when I wrote the book I used an older version of Sonar so things might have changed since then.

I have seen that you posted the same question in stack overflow. I will post there if I find any solution to this.

http://stackoverflow.com/questions/41886878/integrate-spocks-test-with-sonar

To tell you the truth, Sonar is changing so much between each version that I find it frustrating to keep up. Even their LTS versions are not as stable as they should be.

Kostis

Congratulations to everybody!

I will visit this forum from time to time to see if you have any more questions.

There is also the official Manning forum for the same purpose.

https://forums.manning.com/forums/java-testing-with-spock

Happy reading! :-)

Yes

If the team does not have business analysts, then maybe things are different. :-)

Glad to learn that you are already using Spock and Geb and that it has improved the way you work!

Kostis

Hello both.

To Junilu
Yes I know the situation you describe. I call it the "company waste". It is the extra needless effort that happens in big companies where people do not think outside of their roles.
I try to avoid office politics, and frankly sometimes I just accept the situation (until I change company that is). I don't think that this problem is particular to cucumber. It always happens when new tools are "adapted" on an existing
process, rather than changing the full process from scratch.

If you ask me, I would prefer it if business analysts wrote directly the skeleton of Spock tests (i.e. the given, when,then descriptions) and then devs just filled the code. This way everybody would talk about Spock tests as you suggest.
But is this really realistic? Do you know a company that does this? :-)

To Sundar:
Well, I believe that the human factor is more important than tools. If all the team members work together (regardless of their role) and everybody agrees on a sound process, then tools are secondary.
The problem with developers and testers/analysts is that the former usually think of a system from inside/out while the latter think of the outer shell only (they don't care about internals)
I am always amazed with testers that find strange bugs in my code because they have a different way of thinking than me (when I was writing the code).
Yes, as I already mentioned it would be good if the whole team revolved around the Spock tests. At least in the companies I have worked so far, this has never been the case. :-(

Kostis

Hello Krystian

Yes, mocks in Spock are "nice". Nothing bad will happen if you called a method that was not stubbed.
You will just get an empty value (whatever empty means in that context)

Enjoy!

Hello Sundar

I don't have much experience with the Ruby world, so I cannot really comment on RSpec. As far as I can remember, RSpec is one of the frameworks that have influenced Spock, so any similarities might be on purpose.

Regarding Cucumber.
I like to think Cucumber as the full BDD solution. By full, I mean as a whole process where devs, testsers, analysts, PMs are involved and you all follow the "cucumber way" of doing things.
If you are lucky to work in a big company and have convinced your whole team to use/learn Cucumber, I really envy you.

But for simpler cases (e.g. startups), using Cucumber just within the development team is not that different from using Spock.

So I would say that Spock is a lightweight BDD solution (geared towards developers) while Cucumber is the heavyweight BDD solution (geared towards everybody)

The comparison comes down to people instead of technical differences.

I have tried in the past to convince my company to use cucumber and failed because not all people were onboard.
With Spock things are easier, since you get value even if it is just used by developers (parameterized tests, mocking/stabbing, extra annotations etc)

Kostis

Basics

Q. What is the Spock web page?
A. https://github.com/spockframework

Q. Where can I find examples of Spock code?
A. https://github.com/spockframework/spock-example

Q. Where is the documentation?
A. http://spockframework.github.io/spock/docs/1.0/index.html

Q. What is the Javadoc?
A. http://spockframework.github.io/spock/javadoc/1.1-SNAPSHOT/index.html


Compatibility

Q. Can I add Spock tests to a Java project that already has JUnit tests?
A. Yes. JUnit tests are in src/test/java while Spock tests are in src/test/groovy

Q. Can I run Spock tests along with JUnit tests?
A. Yes they can both run at the same time. No need to throw away existing JUnit tests

Q. Can I use Spock with Intellij?
A. Yes. Spock using the same infrastructure as JUnit.

Q. Can I use Spock with Eclipse?
A. Yes. Spock using the same infrastructure as JUnit.

Q. Can I use Spock with Maven?
A. Yes. Spock using the same infrastructure as JUnit.

Q. Can I use Spock with Gradle?
A. Yes. Spock using the same infrastructure as JUnit.

Q. Can I use Spock with Jenkins?
A. Yes. Spock using the same infrastructure as JUnit.

Q. Can I use Spock with Sonar?
A. Yes you get code coverage like JUnit. (e.g. with Jacoco). Your Sonar can work with Spock out of the box.

Spock and Groovy

Q. Is Spock tied to Groovy?
A. No. Spock can test Java code as well.

Q. Is Spock tied to Grails?
A. No. Spock can work with any Java project and technology.

Q. Is Spock tied to Gradle?
A. No, Spock works fine with Maven

Spock tests

Q. What is the characteristic of a Spock test class?
A. A class should extend spock.lang.Specification

Q. What is the characteristic of a Spock test method?
A. A Spock test method should have Spock blocks (given:, when:, then: etc)

Q. What is the programming language used in Spock tests?
A. Groovy. 99.9% of Java code is valid Groovy. This means that you can still use Java code in Spock tests.

Q. What is the naming scheme of Spock tests?
A. Most people name the tests with a *Spec ending. But this is for convenience. There is no technical requirement.

Integrations

Q. Can I use Spock and Spring?
A. Yes. There is an extension for this.
https://github.com/spockframework/spock/tree/master/spock-spring

Q. Can I use Spock and Mockito?
A. In theory you could. But there is no need for this as Spock has its own mocking capabilities.

Q. Can I use Spock and Hamcrest matchers?
A. Yes. Here is an example
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter4/src/test/groovy/com/manning/spock/chapter4/structure/HamcrestMatchersSpec.groovy

Q. Can I use Spock and Guice?
A. Yes there is an extension for this
https://github.com/spockframework/spock/tree/master/spock-guice

Q. Can I use Spock and Arqullian?
A. Yes there is an extension for this.
https://github.com/arquillian/arquillian-testrunner-spock


And most importantly

Q. Where can I find a good book on Spock?
A. Here https://www.manning.com/books/java-testing-with-spock
:-)

Hello Sundar

Yes I agree with you. TDD is a suggestion and not a strict rule. Rules are great for beginners, but experts know when to bend or break the rules.

I have seen companies who think that TDD is the only way forward, often following it in a religious manner without truly understanding its goals.
I think that both ways are applicable.

Sometimes I write the code first and then the tests if it makes sense. Sometimes I write multiple tests that succeed directly after the first run.

A particular area where I think TDD is not that helpful, is when I am prototyping something. There are no clear specs so it is very hard to write unit tests if the details are blurry.

Finally, while TDD helps you write testable code, a Java guru can write testable code (i.e. with good design, SOLID principles, IOC etc) without actually writing any unit tests first.
Not all people can do it, but there are some who can (and no, I do not claim I am that good)

I think TDD has great value in big teams where team members have uneven Java knowledge. But blindly assuming that TDD is always the solution is obviously wrong.

So yes, both ways are applicable in different circumstances exactly as you say.

Kostis

Hello Carlos

It is not about Spock versus Arquillian but instead Spock AND Arquillian as they can both work together.

Spock is not competitor of Arquillian but rather a competitor of JUnit.

There is a Spock-Arquillian extension that makes the two work together
https://github.com/arquillian/arquillian-testrunner-spock

My advice would be to understand first what Spock does on its own, then what Arquillian offers on its own, and finally use them together.

Enjoy!

Kostis

Hello John

You didn't tell me which Grails version you are using. Spock is the default test framework in Grails 2.3+ onwards, so it makes sense to use it as all documentation would refer to it.

Now regarding your confusion, I feel your pain! I had the same problem as well. I was constantly looking at my imports in order to understand which features come from grails.test. * and which from spock.lang.*

The main thing to remember with Grails test is the following:
Grails has this huge advantage of dynamic methods in domain objects (book.findbyNameAndAuthor) which are very handy in development but very difficult to test with plain unit tests. Therefore a lot of Grails testing support
comes from the need to "re-create" this dynamic environment where objects are fetched with dynamic queries. A lot of Grails test annotations are needed for this test environment.

Because Groovy is a very powerful language it already offers several features (that do not appear in Java) already offered by Spock. For example, Spock contains a mocking mechanism on its own, but it very easy to mock
things in Grails/Groovy as well, using mocks, metaclass, expandos etcs.

This means that there are too many ways to combine Spock/Groovy/Grails features on unit tests and thus a lot of documentation you find online has a different view on what a good Grails test is.

My advice (or best practices if you wish) on Grails testing is to talk with your team and decide on ONE way of using all features.

For example, it is perfectly normal to ignore the Spock mocking capabilities and use just normal Groovy and/or Grails mocks. But it is important that all your team member agree on this and all unit tests are written with this way.

I have to admit though, that even if Spock is a revolution for Java/Junit projects it is not as ground-breaking in Groovy/Grails. If you are a seasoned Groovy/Grails developer and have already mastered Grails tests in JUnit, there is no need to rewrite
everything in Spock. You can use Spock just for new tests and keep your old tests.

I have a feeling that Groovy developers are already aware of Spock and will gradually use in their projects. My book is an attempt to convince the Java masses to switch over :-)

Also, apart from JUnit, what other framework have you used in your Grails tests? Did you have something specific in mind?

Kostis

Hello

Yes! Actually this is the scenario I had in mind when I wrote the book. This is also the way I have used Spock in my own projects.

First of all, because Spock tests can be run with existing tools (IDE's and build systems) it is very easy to have both Spock and JUnit tests in the same project and run them together.
This allows you to experiment with Spock without throwing away your JUnit tests.

Mockito versus Spock

Compared to Mockito, Spock has some nice features.

For example, when using argument matchers in Mockito you have to use them for all arguments of a method.
There is a big warning "If you are using argument matchers, all arguments have to be provided by matchers." in the Mockito docs

http://docs.mockito.googlecode.com/hg/org/mockito/Mockito.html

Spock does not suffer from this limitation and you can mix and match argument matchers and specific values as you wish.
Also I find the syntax of argument catchers in Mockito very confusing compared to the Spock way (that uses Groovy closures)

Here are some examples from chapter 6 (which is devoted to mocking and Stubbing with Spock)
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter6/src/test/groovy/com/manning/spock/chapter6/mocks/ArgumentVerificationSpec.groovy

Mockito versus JUnit

Compared to JUnit the advantages are too many to list in a single post (actually that is the whole content of the book)
The biggest revolution I think is the way Spock handles parameterized tests and all the options is offers (chapter 5 of the book)

For comparison here is a parameterized test in JUnit
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter3/src/test/java/com/manning/spock/chapter3/nuclear/NuclearReactorTest.java

and the same one in Spock (notice the number of statements)
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter3/src/test/groovy/com/manning/spock/chapter3/nuclear/NuclearReactorSpec.groovy


Also Spock gains a lot of points just from using Groovy

Here is an example of test data creation in Java (for a JUnit test)
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter2/src/main/java/com/manning/spock/chapter2/assets/SampleShipRegistry.java

and the same in Groovy (for a Spock test)
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter2/src/main/groovy/com/manning/spock/chapter2/assets/GraphBuilderDemo.groovy


I will let you decide which versions you prefer :-)

Anyway, let's just say that all the cases where I have used Spock were existing legacy projects with Mockito and JUnit exactly as you describe. The only case where I used Spock on brand new code was on a small Grails project (so I had full freedom)

Kostis

Hello Omar

As explained in my "Sonar vs JUnit" post, Spock works beautifully with Sonar as it uses internally the JUnit runner. This means that Sonar and Maven can run Spock tests and "see" them as JUnit tests.
Code coverage works like JUnit.

An example is shown in chapter 7 of the book.
The code uses the Jacoco plugin, Maven and nothing else. There is no Spock-specific configuration that you need in Sonar.

Here is the pom file
https://github.com/kkapelon/java-testing-with-spock/blob/master/chapter7/spring-standalone-swing/pom.xml

And here is the screenshot from Sonar from this example (attached on this post)

Kostis

Hello all

While this week there is a promotion for the Spock book by Manning I would like to offer some more insight on the what the book covers and the mindset behind its content.
Also since I started writing the book I have gathered a lot of questions from readers so I have a good feeling on some of the first questions you are thinking when learning about Spock.

Now first things first

If you are a seasoned Java developer and know your way around JUnit the best short resource would be my presentation the directly compares JUnit and Spock
It is in PDF format here http://codepipes.com/presentations/spock-vs-junit.pdf

If you want the full story on JUnit versus Spock, the best resource would be Chapter 3 of the book. It is freely available in PDF format as well
https://manning-content.s3.amazonaws.com/download/3/d90f946-9baf-46eb-859c-fb7a56608320/SampleChapter-03.pdf

The chapter contains some almost-realistic examples and compares what happens with JUnit and Spock (and why Spock is better)

If you are a Java beginner or don't know too much about testing frameworks, then Chapter 1 is a very gentle introduction to testing with Spock. This chapter is also available for free
https://manning-content.s3.amazonaws.com/download/e/82672af-9245-44a7-9542-a9855972700c/SampleChapter-01.pdf

Now here is a small FAQ for Spock (one question in the forum is already contained in the FAQ)

The creators of Spock knew that JUnit is very well entrenched in the Java ecosystem and therefore when they created Spock they made the smart decision to use the JUnit runner.
The JUnit runner (without getting into many details) is the way other tools run JUnit tests. When you run a JUnit test from Eclipse, Intellij, Maven, Gradle etc you call the JUnit runner.

Spock is using the JUnit runner internally instead of introducing a completely new way of running tests. This has the effect that all Spock tests "appear" as normal JUnit tests to existing tools.
This means that the answer to the following questions:

How do I include Spock tests in my project?

How do I run Spock tests?

How do I debug Spock tests?

How do I get code Coverage?

How do I integrate with Sonar?

...is the same: You did the same things you did before as with JUnit

If you run JUnit tests by right clicking on the IDE, you can run Spock tests by right clicking on the IDE
If you run JUnit tests via Gradle, you can run Spock tests via Gradle
If you use Sonar for code coverage in JUnit tests, you still use Sonar for code coverage in Spock tests.

On the other hand with Spock you gain

Less code (because Groovy is more concise than Java)

Mocking and Stubbing for free with no need for an external library

Code blocks to organize semantically you unit tests

Data pipes, tables and generators for parameterized tests

and many more features that are described in the book

Kostis