- [Instructor] Code coverage can be reported automatically
with a technique called continuous integration.
What's that ?
Continuous integration is a technique
for continually executing tasks on your code.
When code is merged into a central repository
like pushing a change to a code, versioning repository
automated builds can run and tests executed.
For example, unit tests and coverage reports
linting tasks to check for suspicious code,
and functional testing can be run automatically.
The results can be used to report problems immediately
to a developer warning about potential issues
with their changes.
The end result is an improvement in software quality
assuming the feedback is addressed.
There are a number of options
for open source continuous integration tools
that you can host yourself.
Each of the following are extensible using plugins
and configuration.
And as a result are flexible for many different use cases.
They all support both single and multiple servers
working in conjunction with each other
in a coordinator worker relationship.
I'll discuss each example in more detail.
They include jenkins, buildbot and spinnaker.
Let's start with jenkins.
Jenkins from "jenkins.io" is written in Java.
It's highly extensible with configurations and plugins
for virtually every task you can think of.
It's also the most popular continuous integration
tool available.
Buildbot from "builtbolt.net" is a tool
that is written in Python.
Buildbot is used by large open source projects
such as Mozilla WebKit and the Chromium browser.
Although at the time of this writing
Chromium is being transitioned to a different tool.
Spinnaker from "spinnaker.io"
was written in Java by Netflix.
And since then, extended by Google.
Spinnaker is explicitly designed for cloud platforms
including support for Kubernetes, Google cloud platform,
Amazon web services, Microsoft Azure, and Oracle cloud.
If you're not comfortable running your own solution
or feel it's better delegated considering
continuous integration as a service.
There's a couple of different ways of getting it.
Multiple services now offer both code hosting,
continuous integration and continuous delivery
and deployment options.
GitHub has actions which are available on "github.com."
GitLab's offering is called CI slash CD
available on "gitlab.com."
Bitbucket pipelines can be found on "bitbucket.org."
For more specifically focused CI and CD solution
both CircleCI and Travis CI provide robust
continuous integration, hosted solutions.
Each of these commercial options has both free
and commercial tiers available.
And there are other providers as well.
When selecting a continuous integration service,
there are a few desirable features to keep in mind.
You should try to match the configuration
of your production environment as closely as possible
including versions of the stack, such as .JS,
the package manager and so forth.
It should be easy to configure and use,
not just by yourself, but by others in the organization.
It should scale to your needs of you and your team.
So nobody should be waiting an undue amount of time
for a task to complete.
Finally, it should integrate with your existing workflow
without too many radical changes.
For example, reporting problems and pull requests
immediately surfaces issues to developers.
In this chapter, we've covered a lot of topics relating
to reporting on your entire code base.
We started with a definition of what code coverage is
and why it matters.
Then we measured code coverage using built into Jest.
We expanded on our code coverage
by functionally testing the application
with Jest along with a survey of functional testing tools.
We used test doubles in an express application
to remove dependencies on services like the database.
We tested form submissions with SuperTest
including setting and coding and checking the response.
Armed with an idealistic goal,
we then explored the fallacies and misconceptions
of 100% test coverage.
Finally, we took a brief look at some options
for code coverage, using continuous integration
and discussed the desirable features of a service.
We may be nearing the conclusion of this course,
but one big question remain,
where can we go from here?