Because your build infra also needs build (and tests)

Bazel CI

Bazel-integration-testing aims to give confidence when developing code that is strongly dependent on Bazel.
It does so by allowing you to have isolated reproducible tests which run Bazel inside of them.
Happy path testing are often possible inside of bazel by adding examples of your usage but failing cases are much harder.
Few examples for such code can be Starlark plugins (both open and closed source), tools that augment Bazel/Bazel query and actually also Bazel itself.
This project was inspired by Bazel's own integration tests which were in bash at the time and were coupled inside.
Internally at Wix we use this to develop and test several internal rules, macros and also tools that need to run bazel query and bazel while bazel-watcher runs Bazel in its E2Es to verify its assumptions on bazel run amongst other things. All of these set up scratch workspaces isolated to the specific tests.

• Bazel Starlark rule developers (both open source and closed source)
• Bazel ecosystem tool developers (both open source and closed source)
• Bazel developers

For integration testing as of Jan'19 there is no alternative which is usable outside of Bazel.
For some use-cases and tests one can use bazel-skylib's unittest framework.
This is faster and might be easier to setup in the test (smaller scope) but has the built-in limitations of unit testing where you make assumptions about the environment.
To be clear it's usually a good idea to have a mix of unit tests and integration tests for your feedback loop and confidence.

The project is built from repository rules, build rules and test drivers.
The build rules are per stack (currently JVM, go, python) and are essentially a wrapper over the $stack_test rule. For every bazel version configured such a wrapper is generated along with a test_suite aggregate.
The JVM build rules are a bit more advanced in that they integrate with bazel_external_dependency_archive repository rule to support external dependencies in the test workspace.
Lastly each stack has a specific test driver which eases creation of scratch WORKSAPCE files, BUILD files, source files, running of Bazel and more.

In order to use bazel_java_integration_test, bazel_go_integration_test, or bazel_py_integration_test, you must add the following to your WORKSPACE file:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "build_bazel_integration_testing",
    url = "https://github.com/bazelbuild/bazel-integration-testing/archive/3a6136e8f6287b04043217d94d97ba17edcb7feb.zip",
    type = "zip",
    strip_prefix= "bazel-integration-testing-3a6136e8f6287b04043217d94d97ba17edcb7feb",
    sha256 = "bfc43a94d42e08c89a26a4711ea396a0a594bd5d55394d76aae861b299628dca",
)


load("@build_bazel_integration_testing//tools:repositories.bzl", "bazel_binaries")
#depend on the Bazel binaries, also accepts an array of versions
bazel_binaries()

http_archive(
    name = "io_bazel_rules_go",
    sha256 = "f04d2373bcaf8aa09bccb08a98a57e721306c8f6043a2a0ee610fd6853dcde3d",
    urls = [
        "https://github.com/bazelbuild/rules_go/releases/download/0.18.6/rules_go-0.18.6.tar.gz",
    ],
)

http_archive(
    name = "bazel_gazelle",
    sha256 = "7fc87f4170011201b1690326e8c16c5d802836e3a0d617d8f75c3af2b23180c4",
    urls = [
        "https://github.com/bazelbuild/bazel-gazelle/releases/download/0.18.2/bazel-gazelle-0.18.2.tar.gz",
    ],
)

load("@io_bazel_rules_go//go:deps.bzl", "go_rules_dependencies")

go_rules_dependencies()

For JVM tests one would like to call the below instead of the above call to bazel_binaries since it does that plus more dependencies needed for java_test:

load("@build_bazel_integration_testing//tools:bazel_java_integration_test.bzl", "bazel_java_integration_test_deps")
bazel_java_integration_test_deps()

TODO

TODO

TODO

TODO

We need to add more info (and also port a small configuration utility) but I'll just add that Wix uses this library on RBE successfully for a few good months.

The project is under active development.
Because the project solves many use cases right now and unfortunately because of capacity issues we're more in a reactive mode but we strongly encourage feedback in the form of issues and PRs.
Note that it is easier for us to review and assist when PRs are Small and especially when they are prefaced with an issue describing the need and possibly iterating there on the design.
We hope to have more capacity in the next few months to also ramp up the missing pieces below.

• More documentation (for go and python as well as much better documentation for the workspace drivers).
• Adding external dependencies is possible in some cases (http_archive) but is not easy. We'd like to see if we can expand this support and make it easier.
• More adoption by rule-sets (rules_docker, rules_scala, etc)
• Up-to-date linting

Here's a (non-exhaustive) list of companies and projects that use bazel-integration-testing. Don't see yours? You can add it in a PR!

• bazel-watcher
• Wix