Test-Driven Development, Build Automation, Continuous Integration
$11.99
Minimum price
$16.99
Suggested price

Test-Driven Development, Build Automation, Continuous Integration

with Java, Eclipse and friends

About the Book

The main subject of this book is software testing. The main premise is that testing is a crucial part of software development. You need to make sure that the software you write behaves correctly. You can manually test your software. However, manual tests require lots of manual work and it is error-prone.

On the contrary, this book focuses on automated tests, which can be done at several levels. In the book, we will see a few types of tests, starting from those that test a single component in isolation to those that test the entire application. We will also deal with tests in the presence of a database and with tests that verify the correct behavior of the graphical user interface.

In particular, we will describe and apply the Test-Driven Development methodology, writing tests before the actual code.

Throughout the book, we will use Java as the main programming language. We use Eclipse as the IDE. Both Java and Eclipse have a huge ecosystem of "friends", that is, frameworks, tools, and plugins. Many of them are related to automated tests and perfectly fit the goals of the book. We will use JUnit throughout the book as the main Java testing framework.

it is also important to be able to completely automate the build process. In fact, another relevant subject of the book is Build Automation. We will use one of the mainstream tools for build automation in the Java world, Maven.

We will use Git as the Version Control System and GitHub as the hosting service for our Git repositories. We will then connect our code hosted on GitHub with a cloud platform for Continuous Integration. In particular, we will use GitHub Actions. With the Continuous Integration process, we will implement a workflow where each time we commit a change in our Git repository, the CI server will automatically run the automated build process, compiling all the code, running all the tests and possibly create additional reports concerning the quality of our code and of our tests.

The code quality of tests can be measured in terms of a few metrics using code coverage and mutation testing. Other metrics are based on static analysis mechanisms, inspecting the code in search of bugs, code smells, and vulnerabilities. For such a static analysis we will use SonarQube and its free cloud version SonarCloud.

When we need our application to connect to a service like a database, we will use Docker a virtualization program, based on containers, that is much more lightweight than standard virtual machines. Docker will allow us to configure the needed services in advance, once and for all, so that the services running in the containers will take part in the reproducibility of the whole build infrastructure. The same configuration of the services will be used in our development environment, during build automation, and in the CI server.

Most of the chapters have a "tutorial" nature. Besides a few general explanations of the main concepts, the chapters will show lots of code. It should be straightforward to follow the chapters and write the code to reproduce the examples. All the sources of the examples are available on GitHub.

The main goal of the book is to give the basic concepts of the techniques and tools for testing, build automation, and continuous integration. Of course, the descriptions of these concepts you find in this book are far from being exhaustive. However, you should get enough information to get started with all the presented techniques and tools.

About the Author

Lorenzo Bettini
Lorenzo Bettini

Lorenzo Bettini is an Associate Professor in Computer Science at the Dipartimento di Statistica, Informatica, Applicazioni "Giuseppe Parenti", Università di Firenze, Italy. Previously, he was a researcher in Computer Science at Dipartimento di Informatica, Università di Torino, Italy.

He has a Masters Degree summa cum laude in Computer Science (Università di Firenze) and a PhD in "Logics and Theoretical Computer Science" (Università di Siena).

His research interests cover design, theory, and the implementation of statically typed programming languages and Domain Specific Languages.

He is the project lead of the Eclipse projects EMF Parsley, https://www.eclipse.org/emf-parsley/, and Xsemantics, https://projects.eclipse.org/projects/modeling.xsemantics. He is also a committer of the Eclipse projects Xtext, https://www.eclipse.org/Xtext/, and SWTBot, https://www.eclipse.org/swtbot/.

He is the author of the two editions of the book "Implementing Domain-Specific Languages with Xtext and Xtend", published by Packt Publishing (2013 and 2016).

He is also the author of about 90 research papers published in international conferences and international journals.

Table of Contents

  • About the author
  • Introduction
    • Conventions
    • Code of examples
    • Errata
    • Install the JDK
  • Book structure
  • 1. Testing
    • 1.1 Automated tests
    • 1.2 Advantages of automated tests
    • 1.3 Test-Driven Development (TDD)
      • 1.3.1 Behavioral-Driven Development (BDD)
  • 2. Eclipse
    • 2.1 Eclipse workspace
    • 2.2 Perspectives and views
    • 2.3 Projects
      • 2.3.1 Importing an existing project
      • 2.3.2 Creating a new Java project
      • 2.3.3 Open projects and closed projects
      • 2.3.4 Automatic building
    • 2.4 IDE tools
      • 2.4.1 Content Assist
      • 2.4.2 Quick Fix
      • 2.4.3 Quick Assist
      • 2.4.4 Editable proposals
      • 2.4.5 The Source menu
    • 2.5 Eclipse Preferences
    • 2.6 Find Actions
    • 2.7 Eclipse Shortcuts
      • 2.7.1 Quick Search
    • 2.8 Eclipse Run configurations
    • 2.9 Browsing code
      • 2.9.1 Outline
      • 2.9.2 Navigate
      • 2.9.3 Local History
    • 2.10 Code Mining
  • 3. JUnit
    • 3.1 Structure of a test
    • 3.2 A first example
      • 3.2.1 Exception testing
      • 3.2.2 Other tests
      • 3.2.3 Revising
    • 3.3 External collaborators (dependencies)
      • 3.3.1 Alternative implementations
    • 3.4 Testing private methods?
    • 3.5 Keep your tests clean and readable
      • 3.5.1 Beware of code duplication removal in tests
    • 3.6 Other testing libraries
      • 3.6.1 Using Hamcrest matchers
      • 3.6.2 Using AssertJ
    • 3.7 Keeping test code separate from main code
      • 3.7.1 Export a runnable JAR
    • 3.8 JUnit 5
  • 4. TDD
    • 4.1 Introduction to TDD
      • 4.1.1 The Red-Green-Refactor cycle
      • 4.1.2 The three laws of TDD
      • 4.1.3 Remove duplication
    • 4.2 The Transformation Priority Premise
      • 4.2.1 A first example of TDD
    • 4.3 Three strategies for the green state
      • 4.3.1 The factorial example with TDD
    • 4.4 Small or big steps?
    • 4.5 Tests and induction (part 1)
    • 4.6 TDD with JUnit 4 Parameterized Tests
    • 4.7 TDD with JUnit 5 Parameterized Tests
    • 4.8 Testing abstract classes?
    • 4.9 Writing a test that succeeds
  • 5. Code coverage
    • 5.1 JaCoCo and EclEmma
    • 5.2 How code coverage can help
    • 5.3 Code coverage percentage
  • 6. Mutation Testing
    • 6.1 The first example with PIT
    • 6.2 Enabling additional mutators
    • 6.3 Further experiments with PIT
      • 6.3.1 Tests and induction (part 2)
      • 6.3.2 Mutations and iterative solutions
      • 6.3.3 Mutation testing on the MyStringUtils example
      • 6.3.4 Mutation testing on the Bank example
    • 6.4 Narrowing mutations
  • 7. Maven
    • 7.1 Introduction to Maven
    • 7.2 Maven installation
    • 7.3 Let’s get started with a Maven archetype
      • 7.3.1 Create a Maven project from the command line
      • 7.3.2 Import a Maven project in Eclipse
      • 7.3.3 Create a Maven project from Eclipse using an archetype
    • 7.4 Structure of a Maven project
    • 7.5 Java settings
    • 7.6 Dependencies
      • 7.6.1 Maven coordinates (GAV)
      • 7.6.2 Dependencies in the POM
      • 7.6.3 SNAPSHOT
      • 7.6.4 Version ranges
    • 7.7 Eclipse m2e
    • 7.8 Properties
    • 7.9 Resources
      • 7.9.1 Layout of an Eclipse project
      • 7.9.2 Create a Maven project from Eclipse without an archetype
    • 7.10 The Eclipse m2e pom.xml multi-tab editor
    • 7.11 The bank example as a Maven project
    • 7.12 Build with Maven
      • 7.12.1 Maven lifecycles
      • 7.12.2 Run Maven from the command line
      • 7.12.3 Run Maven goals
      • 7.12.4 Run Maven from Eclipse
      • 7.12.5 Offline mode
      • 7.12.6 Updating dependencies
    • 7.13 Maven packaging
      • 7.13.1 Packaging “jar”
      • 7.13.2 Packaging “pom”
    • 7.14 Parent and modules
      • 7.14.1 Let’s create a parent project and a module project
      • 7.14.2 Effective POM
      • 7.14.3 Project aggregation and project inheritance
      • 7.14.4 Build a single module
      • 7.14.5 Dependency management
      • 7.14.6 Bill of Material (BOM)
      • 7.14.7 How Eclipse resolves the projects in the workspace
    • 7.15 Configuring a Maven plugin
      • 7.15.1 Configuring the Maven compiler plugin
      • 7.15.2 Generate source and javadoc jars
      • 7.15.3 Configuring the generated jar
      • 7.15.4 Creating a FatJar
      • 7.15.5 Plugin management
      • 7.15.6 Configuring the PIT Maven plugin
      • 7.15.7 Configuring the JaCoCo Maven plugin
    • 7.16 Maven profiles
      • 7.16.1 Don’t abuse profiles
    • 7.17 The bank example as a multi-module project
      • 7.17.1 The bank BOM
      • 7.17.2 The bank parent POM
      • 7.17.3 The bankaccount project
      • 7.17.4 The bank project
      • 7.17.5 The bank report project
      • 7.17.6 The bank app project
      • 7.17.7 The aggregator project
    • 7.18 JUnit 5 and Maven
    • 7.19 Maven deploy
    • 7.20 Maven wrapper
    • 7.21 Beyond Java 8
    • 7.22 Reproducibility in the build
  • 8. Mocking
    • 8.1 Testing state and testing interactions
    • 8.2 Mockito: an overview
      • 8.2.1 Creating a mock
      • 8.2.2 Method stubbing
      • 8.2.3 Interaction verification
    • 8.3 Mockito: a tutorial
      • 8.3.1 Spy
      • 8.3.2 Spying and stubbing
      • 8.3.3 Stubbing and exceptions
      • 8.3.4 Subsequent stubbing
      • 8.3.5 Argument matchers
    • 8.4 Alternative ways of initializing mocks and other elements
    • 8.5 Mockito BDD style
    • 8.6 Mockito and JUnit 5
    • 8.7 Stubbing with answers
      • 8.7.1 Another example: Transactions
    • 8.8 Fakes
    • 8.9 What to mock
  • 9. Git
    • 9.1 Let’s start experimenting with Git
      • 9.1.1 Create a git repository
      • 9.1.2 Git configuration
      • 9.1.3 States of the working tree
      • 9.1.4 Perform a commit
      • 9.1.5 Commit history
      • 9.1.6 Ignore files and directories
      • 9.1.7 Branches
      • 9.1.8 Reset
      • 9.1.9 Cherry-pick
      • 9.1.10 Stash
    • 9.2 Remote repositories
      • 9.2.1 Bare repository
      • 9.2.2 Adding a remote repository
      • 9.2.3 Initialize an empty remote repository
      • 9.2.4 Cloning a remote repository
      • 9.2.5 Push and fetch
      • 9.2.6 Rebasing
      • 9.2.7 Pull requests
    • 9.3 EGit (Git in Eclipse)
      • 9.3.1 Add an Eclipse project to a new Git repository
      • 9.3.2 The Git Repositories view
      • 9.3.3 Importing an existing project
      • 9.3.4 Branch operations
      • 9.3.5 Cloning from Eclipse
    • 9.4 GitHub
      • 9.4.1 Create a repository on GitHub
      • 9.4.2 GitHub pull requests
      • 9.4.3 Contributing to other projects
  • 10. Continuous Integration
    • 10.1 Our running example
    • 10.2 GitHub Actions
      • 10.2.1 Caching dependencies
    • 10.3 Build matrix
      • 10.3.1 Building using different JDKs
      • 10.3.2 Building using different operating systems
      • 10.3.3 Configuring the build matrix
    • 10.4 Building pull requests
      • 10.4.1 Multiple workflows
    • 10.5 Storing artifacts
    • 10.6 Code coverage in CI
    • 10.7 Code coverage with Coveralls
      • 10.7.1 Using Coveralls from our computer
      • 10.7.2 Using Coveralls from GitHub Actions
      • 10.7.3 Coverage threshold
    • 10.8 Badges
    • 10.9 Reproducibility in CI
    • 10.10 Let’s revise our build process
    • 10.11 Further steps
  • 11. Docker
    • 11.1 Let’s get started with Docker
    • 11.2 Run a server in a container
    • 11.3 Dockerize a Java application
      • 11.3.1 The Java application to dockerize
      • 11.3.2 The Dockerfile
    • 11.4 Windows containers
    • 11.5 Build the Docker image from Maven
    • 11.6 Using Docker in GitHub Actions
    • 11.7 Docker networks
    • 11.8 Docker compose
      • 11.8.1 Control startup order of container
    • 11.9 Docker in Eclipse
    • 11.10 Push to DockerHub
    • 11.11 Reproducibility in Docker
  • 12. Integration tests
    • 12.1 Our running example
    • 12.2 Unit tests with databases
      • 12.2.1 Mock the MongoClient?
      • 12.2.2 Use an in-memory database
    • 12.3 Integration tests
      • 12.3.1 Source folder for integration tests
      • 12.3.2 Integration tests with Docker and Testcontainers
      • 12.3.3 Running integration tests with Maven
      • 12.3.4 Integration tests with Docker and Maven
      • 12.3.5 Running integration tests in GitHub Actions
    • 12.4 Unit or integration tests?
  • 13. UI tests
    • 13.1 The running example
    • 13.2 UI unit tests
      • 13.2.1 Testing the GUI controls
      • 13.2.2 Implementing the StudentView interface
      • 13.2.3 Unit tests for the UI frame’s logic
    • 13.3 Running UI tests in GitHub Actions
    • 13.4 UI integration tests
    • 13.5 Multithreading
      • 13.5.1 Race conditions in the application
      • 13.5.2 Race conditions in the database
    • 13.6 Improvements
  • 14. End-to-end tests
    • 14.1 The running example
    • 14.2 E2e tests for our application
    • 14.3 BDD with Cucumber
      • 14.3.1 Data tables
      • 14.3.2 Step decoupling
      • 14.3.3 High-level specifications
    • 14.4 Starting from the high-level specifications
    • 14.5 Change some low-level details
  • 15. Code Quality
    • 15.1 Using SonarQube locally
    • 15.2 Analyze a project
      • 15.2.1 False positives and rule exclusion
      • 15.2.2 Analysis of test code
      • 15.2.3 Security hotspots
      • 15.2.4 Code coverage in SonarQube
      • 15.2.5 JUnit reports
    • 15.3 SonarCloud
    • 15.4 SonarLint (IDE integration)
  • 16. Learning tests
    • 16.1 Dependency Injection with Google Guice
      • 16.1.1 Guice main concepts
      • 16.1.2 Singleton
      • 16.1.3 Field and method injection
      • 16.1.4 Providers
      • 16.1.5 Binding annotations
      • 16.1.6 Overriding bindings
      • 16.1.7 Factories and AssistedInject
      • 16.1.8 Cyclic dependencies
      • 16.1.9 Provides
    • 16.2 Apply our learnings
  • Bibliography
  • Notes

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.

You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!

So, there's no reason not to click the Add to Cart button, is there?

See full terms...

80% Royalties. Earn $16 on a $20 book.

We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub