sh_test is my most commonly used test rule by far. It is the easiest way to
write quick-and-dirty tests and works nearly everywhere. For anything beyond
the most trivial tests, I use Bazel’s Bash unit test framework. This explains
what the framework is and how to use it.
When creating a new ruleset, particularly on GitHub, start with the
official Bazel rules template. It includes a number of features
out of the box that are rather tiresome to implement yourself.
At work, we have a number of custom-written Bazel rulesets stored in organization
repositories on GitHub1. This post explains how we use these non-public
rulesets in our Bazel projects.
For most Bazel projects, I strongly recommend using a single Bazel
workspace per source code repository. However, it can be occasionally
useful to nest multiple workspaces within a single repository. For
example, when I’m writing Bazel rulesets, I will often create test
cases that contain own workspace with a slightly different configuration
in order to test various workspace-level configuration settings
for the ruleset, while maintaining a root workspace which is the
primary workspace for the ruleset.
As developers know, virtually all compilers support the notion
of compilation mode, e.g.. whether to compile the code in debug
or release mode. In Bazel, this concept is built natively into
the build system itself. When compiling software using bazel build,
one can select a compilation mode using the --compilation_mode
(often shorted to -c) flag.
When writing a custom Bazel ruleset, it is important to carefully
separate its public interface from its private implementation
and be deliberate and careful about changes to the public
interface. Here’s the pattern I use when I’m writing rulesets to
handle this.