Reputation: 8296
Is there any Bazel convention for defining all of a project's test targets in some subfolder tests
with its own BUILD
file? Is that layout preferred to one main BUILD
file that combines everything in one place: bins, libs, and tests?
An all-in-one build file could get lengthy, but it has the benefit of using in-package sibling target references, ie the ":siblingTarget"
references.
Upvotes: 2
Views: 477
Reputation: 8170
Short answer: Yes.
Why would you like to couple your test with the implementation? You should always try to reduce dependencies between different parts of your code. That makes it easier to understand. See also here.
Imaging you find some BUILD
file that contains implementation and test rules (e.g. cc_library
, cc_binary
, cc_test
). Imagine some developer needed for some test some library - and only for testing proposes (e. g. cc_library(name="some_lib"
). How would you know if this library is only needed for testing? If it is in a BUILD
file contained in test
folder then it would be clear from the folder structure that there is a high probability that this lib is only needed for testing proposes.
Update:
Short answer: It depends ;)
Was just stumbling over this post again. To be honest, in C++ projects I always mix test targets with "normal" targets (see for instance here) - at least for unit/low level tests - I do it similar as abseil-cpp - see here for instance: https://github.com/abseil/abseil-cpp/tree/master/absl/base - there is a log_severity.h
, log_severity.cpp
and a log_severity_test.cc
. In the BUILD file we have:
cc_library(
name = "log_severity",
...
cc_test(
name = "log_severity_test",
It makes perfect sense to have these files/targets close together, since the stuff that is tested is directly in the corresponding files. I have some acceptance and high-level tests. For those I create usually a test folder because in those situations many different things are tested at the same time and it would not make sense to put it aside to a low level implementation source file - see for instance here).
When it comes to Java I do it differently. In Java projects, I have a separate test folders and separate BUILD files for tests and other code, since it's a common pattern in Java projects.
Is difficult to give a general advice here, since Bazel as a polyglot build system support many languages, which already have a community that expects a certain pattern.
In my opinion, you should be consistent in your placement - otherwise, developers will have a hard time finding the corresponding implementation/test fast - it does not matter if you have a separate test folder or place low-level tests always close to the implementation - it only has to be consistent so code navigation works fast.
Upvotes: 2