Building with Bazel

Jul 8 2022 · Starlark, Bazel 5.1, Visual Studo Code 1.66

Part 1: Learning Bazel

15. Run Unit Tests

Episode complete

Play next episode

About this episode

Leave a rating/review

See forum comments
Cinema mode Mark complete Download course materials
Previous episode: 14. Incorporate a BazelRC File Next episode: 16. Use the Android Studio Plugin
Transcript: 15. Run Unit Tests

Episode 15 - Run Unit Tests

Building in one part of the process. We also need to run our unit tests. Running your tests is just as important. Bazel supports running tests out of the box. For this to work, we need to define our testing targets.

As mentioned in an earlier episode, our iOS version of the app has a few tests in it. Lets put these tests to work. When we run our tests, the command line will inform you if the tests had passed or not. If you want additional information about the tests, you can look in the test-logs that provides more information about the tests itself.

One of the great things about Bazel unit testing is that Bazel will cache the build results. Whereas another build system will re-rerun all your tests every single time, Bazel will be able determine which tests need to be re-run based on the affected target. So you may have a project with a thousand tests but the affected target has only a hundred tests. This means, Bazel will just run those hundred tests whereas another system would run the entire lot. Over time, that saved time will compound to hundreds of hours of saved development time.

To get started, open up your project in progress. Open up your iOS BUILD file. We’re going to define two additional targets. A swift library will hold our compiled tests after which, we’ll create a unit test target.

We’ll start with the swift library. Add the following



We’ll give it a name and pass some tests.

    name = "tests",
    srcs = glob(["BullseyeTests/*.swift"]),

We’ll set the visibility to private since this is a support target.

visibility = ["//visibility:private"],

Now our tests are testing our application code. This means, we need to create a dependency to our sources target. Add the following:

deps = [":sources"],

Finally, we need to define a module name. In this case, this our BullseyeTests.

module_name = "BullseyeTests",

Now if we switch over to Xcode, and open our tests, we’ll see that we import a Bullseye module. We need to define this. Back in our build file, update the sources target to the following:

module_name = "Bullseye",

Now we’ll be able to import the test code. Okay, we setup a target to compile our tests, we need to create an ios_unit_test target. We don’t have access to the ios_unit_test so we me must import it.

load("@build_bazel_rules_apple//apple:ios.bzl", "ios_application", "ios_unit_test")

Let’s add the following:



We’ll give it the name ios_tests and set up a dependency.

name = "iostests",
deps = [":tests"],

We’ll add our minimum os version.

minimum_os_version = "14.0",

Since we are testing an application, we’ll set the target to an iOS target.

test_host = ":youfirstapp",

We’ll also set the platform type to be iOS and set the visibility to be public.

platform_type = "ios",
visibility = ["//visibility:public"]

And that’s it. Now it’s time to run our tests. First, let’s build our targets. In the terminal, we could build the tests like so:

bazel build //Bullseye-iOS:iostests

But let’s just run them. Type the following:

bazel test //Bullseye-iOS:iostests 

Notice we use the test command. It takes awhile but the tests will run. In our case, our tests failed. Now lets drill down in the test logs folder. Keep going until you run into Unzip the file and you’ll see produces an xcresult file. Double click it and you’ll be able to see the results in Xcode.

Here we are informed why the test failed. It turns out, that the test itself was bugged since there was no way for the asset to be 195. Change it to 95. Return back to Visual Studio code. Rerun your tests. And now it passes.

Well done.