Git is the most popular revision control system. For that reason, all the code used in this book is stored in Bitbucket (https://bitbucket.org/). If you don't have it already, install Git. Distributions for all the popular operating systems can be found at: http://git-scm.com.

Many graphical interfaces are available for Git; some of them being Tortoise (https://code.google.com/p/tortoisegit), Source Tree (https://www.sourcetreeapp.com), and Tower (http://www.git-tower.com/).

Even though they are outside the topic of this book, virtual machines are a powerful tool and a first-class citizen in a good development environment. They provide dynamic and easy-to-use resources in isolated systems so they can be used and dropped at the time we need them. This helps developers to focus on their tasks instead of wasting their time creating or installing required services from scratch. This is the reason why virtual machines have found room in here. We want to take advantage of them to keep you focused on the code.

In order to have the same environment no matter the OS you're using, we'll be creating virtual machines with Vagrant and deploying required applications with Docker. We chose Ubuntu as a base operating system in our examples, just because it is a popular, commonly used Unix-like distribution. Most of these technologies are...

With time, code tends to grow both in complexity and size. This occurs in the software industry by its nature. All products evolve constantly and new requirements are made and implemented across a product's life. Build tools offer a way to make managing the project life cycle as straightforward as possible, by following a few code conventions, such as the organization of your code, in a specific way, and by the usage of naming a convention for your classes or a determined project structure formed by different folders and files.

Some of you might be familiar with Maven or Ant. They are a great couple of Swiss army knives for handling projects, but we are here to learn so we decided to use Gradle. Some of the advantages of Gradle are its reduced boilerplate code, resulting in a much shorter file and a more readable configuration file. Among others, Google...

As many tools and technologies will be covered, we recommend using IntelliJ IDEA as the tool for code development. The main reason is that this integrated development environment (IDE) works without any tedious configuration. The Community Edition (IntelliJ IDEA CE) comes with a bunch of built-in features and plugins that make coding easy and efficient. It automatically recommends plugins that can be installed depending on the file extension. As IntelliJ IDEA is the choice we made for this book, you will find references and steps referring to its actions or menus. Readers should find a proper way to emulate those steps if they are using other IDEs. Refer to: https://www.jetbrains.com/idea/ for instructions on how to download and install IntelliJ IDEA.

In this section, two of the most used Java frameworks for unit testing are shown and briefly commented on. We will focus on their syntax and main features by comparing a test class written using both JUnit and TestNG. Although there are slight differences, both frameworks offer the most commonly used functionalities, and the main difference is how tests are executed and organized.

Let's start with a question. What is a test? How can we define it?

In the programming approach, there are several types of tests depending on their scope—functional tests, acceptance tests, and unit tests. Further on, we will explore each of those types of tests in more detail...

In the previous section, we gave an overview of what a unit test is and how it can be written using two of the most commonly used Java frameworks. Since tests are an important part of our projects, why not improve the way we write them? Some cool projects emerged, aiming to empower the semantics of tests by changing the way that assertions are made. As a result, tests are more concise and easier to understand.

Hamcrest adds a lot of methods called matchers. Each matcher is designed to perform a comparison operation. It is extensible enough to support custom matchers created by yourself. Furthermore, JUnit supports Hamcrest natively since its core is included in the JUnit distribution. You can...

The fact that we wrote tests does not mean that they are good, nor that they cover enough code. As soon as we start writing and running tests, the natural reaction is to start asking questions that were not available before. What parts of our code are properly tested? What are the cases that our tests did not take into account? Are we testing enough? These and other similar questions can be answered with code coverage tools. They can be used to identify the blocks or lines of code that were not covered by our tests; they can also calculate the percentage of code covered and provide other interesting metrics.

They are powerful tools used to obtain metrics and show relations between tests and implementation code. However, as with any other tool, their purpose needs to be clear. They do not provide information about quality, but only about which parts of our code...