Java Testing with Spock: A good (and sometimes Groovy) guide to using this powerful testing framework – #programming #java

Java Testing with Spock

Konstantinos Kapelonis

Manning, paperback


Spock, the author states, is “a comprehensive testing framework for Java (and Groovy) code that can help you automate the boring, repetitive, and manual process of testing a software application. Spock is comprehensive because it’s a union of existing testing libraries”—specifically JUnit, Mockito and JBehave. It also is influenced by several others.

What is Spock’s main advantage in test scenarios? “When things go wrong,” Konstantinos Kapelonis notes, “Spock gives as much detail as possible on the inner workings of the code at the time of the failure.”

Spock is written in Groovy, and just mentioning that language, as well as the Gradle build tool, may give a little heartburn to hardcore Java developers who don’t want to learn them. But others find Groovy refreshingly efficient and Gradle easy to use. In any case, using Groovy (and Gradle) with this book is “optional,” the author emphasizes. As noted in Appendix A, “It’s perfectly possible to use Spock in your Java project without installing Groovy itself.”

To emphasize that point, Kapelonis shows how to use Spock with the Maven build tool first, before he delves into how to use Spock with the Gradle build tool.

The book is divided into three major parts: (1) Foundations and brief tour of Spock; (2) Structuring Spock tests; and (3) Spock in the Enterprise.

Two appendices deal with installing and using Spock, plus getting your IDE set up, and using the book’s example files.

Java Testing with Spock is a comprehensive guide to learning how to do Java (and Groovy) testing with Spock, and it is generally well written and adequately illustrated.

I chose to try the Groovy-Gradle approach, with Eclipse as my IDE. And I did run into some awkward moments trying to get Eclipse Mars.2 to play correctly. The Groovy-Gradle plug-in from the Eclipse Marketplace was for earlier versions of Eclipse, and so was the Spock plug-in. After some tinkering and reconfiguring, I was able to get things working together and do some Java and Groovy tests. To be fair, I was doing this on a kludged-together Windows 10 machine that definitely is no development powerhouse. And I did not have time to try out the Maven approach, but I have used Maven in the past, and the author’s instructions and examples for Maven look solid.

Java Testing with Spock is a good, helpful how-to book for anyone who wants to know more about putting the Spock testing framework to good use at all levels of Java development.

Si Dunn

Groovy in Action, Second Edition – A hefty how-to guide newly updated for Groovy 2.4 – #programming #bookreview

Groovy in Action, Second Edition

Dierik König and Paul King, with Guillaume Laforge, Hamlet D’Arcy,
Cédric Champeau, Eric Pragt and Jon Skeet

Manning – paperback

Groovy in Action, Second Edition, is not light reading. Indeed, the printed book weighs nearly three and a half pounds and has 880 pages. But it is great reading for anyone who wants to learn, or get better at, the increasingly popular Groovy scripting language that works very smoothly with Java. Indeed, Java’s creator, James Gosling, has hailed Groovy’s “smooth and efficient” integration with Java and called Groovy “an effective implementation language in its own right.” He also has praised the Groovy in Action book as “a clear and detailed exposition of what is groovy about Groovy.”

The Second Edition‘s two main authors and five assisting authors are members of the Groovy core team. And their book spent a lot of time being reviewed and tested by readers in the Manning Early Access Program (MEAP) before it was formally released. So it likely has a better preparation record than many programming books currently on the market.

Groovy in Action‘s front flap indicates that the book covers Groovy 2.4. Groovy recently was up to version 2.4.3, but the programming language has maintained a good track record for supporting backward compatibility. Indeed, I tested random selections of the book’s code samples using version 2.2.0 and its Groovy Console, and programs compiled and ran without problem.

However, if you own the first edition of Groovy in Action, you likely will want to upgrade to the new book. It is, the authors state, “a full rewrite,” with several new chapters, plus  “a few hundred additional pages of genuinely new content.” (And yes, I am upgrading my Groovy installation from 2.2.0 to 2.4.3.)

Despite its heft, the book is nicely structured and easily approached. And its many code examples are mercifully compact, for the most part, and available online, if you prefer. (I actually enjoy keying reasonably short code examples into the Groovy Console.)

The 20 chapters are organized into three major parts:

  • The Groovy Language
  • Around the Groovy Library
  • Applied Groovy

“The Groovy Language” introduces the reader to the language’s basics: its “syntax, grammar, and typical idioms,” plus how to use dynamically typed Groovy as a static language, if desired. The “Around the Groovy Library” reference section focuses on such topics as working with builders and the Groovy Development Kit (GDK), as well as Groovy’s support for database programming and the handling of JSON and XML. And “Applied Groovy” looks at “typical uses cases for Groovy,” including “a thorough exposition of how to use Groovy for test automation,” how to put Groovy to work on multi-core machines in concurrent programming situations, and “using Groovy for domain specific languages.”

In short, there is no shortage of useful content in Groovy in Action, Second Edition.

Si Dunn

Get Groovy in Action, Second Edition here, at no extra cost.

Gradle in Action – Had enough of Maven and Ant? Try this powerful Java build tool – #programming #bookreview

Gradle in Action

Benjamin Muschko

(Manning, paperback)

Apache Maven and Apache Ant are perhaps the two best-known and most widely used Java build tools. But Gradle is gainmuschkoing users and aficionados ( if, indeed, there can be “fans” of software build tools). And this well-prepared new book likely will help Gradle achieve even wider acceptance and employment in the workplace.

“Gradle,” writes Benjamin Muschko, “is the next evolutionary step in JVM-based build tools. It draws on lessons learned from established tools like Ant and Maven and takes their best ideas to the next level. Following a build-by-convention approach, Gradle allows for declaratively modeling your problem domain using a powerful and expressive domain-specific language (DSL) implemented in Groovy instead of XML. Because Gradle is a JVM native, it allows you to write custom logic in the language you’re most comfortable with, be it Java or Groovy.”

Muschko has a strong bias toward Gradle, of course. He is a member of the Gradleware engineering team and has written several popular Gradle plugins.

Nonetheless, his well-written, 15-chapter, 456-page book makes a compelling case for Java developers to add Gradle to their build-tool cabinet and list of skills.

“Over the course of years,” Muschko contends, Maven and Ant “[have] significantly improved and extended their feature set. But even though both are highly popular and have become industry standards, they have one weak point: build logic has to be described in XML. XML is great for describing hierarchical data, but falls short on expressing program flow and conditional logic. As a build script grows in complexity, maintaining the build code becomes a nightmare.”

To use Gradle, you do have to learn parts of yet another programming language, Groovy. But, if you already know Java, you are much of the way there.  “The language [Groovy] integrates with existing Java classes and libraries, which makes it easy for Java developers to learn it.” Muschko stresses. “Not only does Groovy build upon the strengths of Java, it also provides powerful programming features inspired by those of Ruby, Python, and others. Groovy can be used as a scripting language without having to compile the code. Alternatively, Groovy code can be compiled to Java bytecode.” (Both approaches are used in the book.)

“Gradle’s core functionality is built with Java,” Muschko points out. “On top of this functionality sits a domain-specific language (DSL) written in the dynamic programming language Groovy. When writing a Gradle build script, you automatically use the language constructs exposed by this DSL to express the desired build instructions. Gradle build scripts are executable Groovy scripts, but they can’t be run by the Groovy runtime. When the need to implement custom logic arises, you can use Groovy’s language features to build out the desired functionality directly in the Gradle build script.”

Gradle in Action uses some Groovy in most of its code examples. But you are not expected to have experience with that language. Instead, Muschko gradually introduces Groovy and shows how it is used in the build processes, while keeping the book’s focus on Gradle and Gradle’s advantages over Maven and Ant (with Ivy). (You can run many of the book’s code examples from the Gradle command line and also, as I did, try out some of the Groovy code snippets using Groovy’s console. And Chapter 10 describes Gradle’s IDE plug-ins for Eclipse and NetBeans.)

“This book is primarily for developers and build automation engineers who want to implement a repeatable build that’s easy to read and extend,” Muschko says.

Muschko’s book is organized into three parts:

  • Part 1, Introducing Gradle
  • Part 2, Mastering the Fundamentals
  • Part 3, From Build to Deployment.

Part 1 includes an introduction to project automation and illustrates the differences in how builds are put together in Maven, Ant, and Gradle. It also shows how to write and execute a simple Gradle script, run Gradle on the command line, and build a Gradle project by example.

Part 2 delves into more advanced topics such as dependency management, testing an application with Gradle, extending a build with plugins, and other subjects, such as multiproject builds. It also digs deeper into testing, Gradle’s extension mechanism, and “how to translate existing build logic from one tool to another, identify integration points, and depict migration strategies.”

Part 3  emphasizes how to use Gradle in deployment. “In times of increased pressure to deliver software quickly and frequently,” Muschko writes, “automating the deployment and release process is extremely important. In part 3, you’ll learn how to use Gradle to its fullest in the context of continuous delivery.”

Meanwhile, Appendix A provides a closer look at how to use Gradle’s Command Line Interface, while Appendix B, titled “Groovy for Gradle users,” provides an introduction to what the author terms “Groovy’s most important language features,” with recommendations to help you learn more Groovy on your own. 

“For years, builds had the simple requirements of compiling and packaging software,” Muschko says. “But the landscape of modern software development has changed, and so have the needs for build automation. Today, projects involve large and diverse software stacks, incorporate multiple programming languages, and apply a broad spectrum of testing strategies. With the
rise of agile practices, builds have to support early integration of code as well as frequent and easy delivery to test and production environments. Established build tools continuously fall short in meeting these goals in a simple but customizable fashion.”

So, will it be Gradle to the rescue? In some settings, perhaps yes. In other environments, you may need to know how to use Maven, Ant and Gradle, plus some other build tools. And in still other work settings, the powers that be may insist on Maven or Ant or something else.

In any case, if you work with Java software builds, you may want to consider learning Gradle (and, by default, some Groovy, too). If so, give serious consideration to Benjamin Muschko’s excellent new how-to book.  In its foreword, Hans Dockter, the founder of Gradle and Gradleware, terms Gradle in Action “the authoritative guide.”

Si Dunn