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

This book is 100% complete

Completed on 2019-10-11

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 Travis CI. 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 Quick Access
    • 2.7 Eclipse Shortcuts
    • 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.3 External collaborators (dependencies)
      • 3.3.1 Alternative implementations
    • 3.4 Testing private methods?
    • 3.5 Keep your tests clean and readable
    • 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
  • 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 The Transformation Priority Premise
      • 4.1.4 Small or big steps?
    • 4.2 A first example of TDD
    • 4.3 The factorial example with TDD
    • 4.4 Tests and induction (part 1)
  • 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 A 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 Mutation testing on the MyStringUtils example
      • 6.3.3 Mutation testing on the Bank example
  • 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.3.4 Other archetypes
    • 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.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 Maven deploy
    • 7.19 Maven wrapper
    • 7.20 Beyond Java 8
    • 7.21 Reproducibility in the build
  • 8. Mocking
    • 8.1 Mockito: an overview
      • 8.1.1 Creating a mock
      • 8.1.2 Method stubbing
      • 8.1.3 Interaction verification
    • 8.2 Mockito: a tutorial
      • 8.2.1 Spy
      • 8.2.2 Spying and stubbing
      • 8.2.3 Stubbing and exceptions
      • 8.2.4 Subsequent stubbing
      • 8.2.5 Argument matchers
    • 8.3 Alternative ways of initializing mocks and other elements
    • 8.4 Mockito BDD style
    • 8.5 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 Travis CI
      • 10.2.1 Configure the Travis build
      • 10.2.2 Caching on Travis
      • 10.2.3 Testing against multiple JDKs
      • 10.2.4 Testing against multiple operating systems
      • 10.2.5 Building pull requests
      • 10.2.6 Conditional builds
    • 10.3 Code coverage with Coveralls
      • 10.3.1 Coverage threshold
    • 10.4 Badges
    • 10.5 Reproducibility in CI
    • 10.6 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.3.3 Build the Docker image from Maven
      • 11.3.4 Using Docker in Travis CI
    • 11.4 Docker networks
    • 11.5 Docker compose
    • 11.6 Docker in Eclipse
    • 11.7 Push to DockerHub
    • 11.8 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 Travis CI
    • 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 Travis CI
    • 13.4 UI integration tests
    • 13.5 Multithreading
      • 13.5.1 Beware of race conditions
    • 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 Step decoupling
      • 14.3.2 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 Code coverage in SonarQube
      • 15.2.2 JUnit reports
      • 15.2.3 Analysis of test code
    • 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

Authors have earned$8,071,546writing, publishing and selling on Leanpub,
earning 80% royalties while saving up to 25 million pounds of CO2 and up to 46,000 trees.

Learn more about writing on Leanpub

The Leanpub 45-day 100% Happiness Guarantee

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

See full terms

Free Updates. Free App. 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), EPUB (for phones and tablets), MOBI (for Kindle) and in the free Leanpub App (for Mac, Windows, iOS and Android). 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. It really is that easy.

Learn more about writing on Leanpub