You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This attribute, which is `True` by default, controls whether `XCTest`-style tests are automatically discovered (either using the Objective-C runtime or manual discovery via symbol graphs). If set to `False`, the test is assumed to provide its own `main`.
This will subsume the behavior of the `swift.bundled_xctests` feature, which will be removed in the future.
PiperOrigin-RevId: 471589475
(cherry picked from commit 477b48a)
Signed-off-by: Brentley Jones <[email protected]>
Copy file name to clipboardExpand all lines: doc/providers.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -111,7 +111,7 @@ that use the toolchain.
111
111
| <aid="SwiftToolchainInfo-requested_features"></a>requested_features |`List` of `string`s. Features that should be implicitly enabled by default for targets built using this toolchain, unless overridden by the user by listing their negation in the `features` attribute of a target/package or in the `--features` command line flag.<br><br>These features determine various compilation and debugging behaviors of the Swift build rules, and they are also passed to the C++ APIs used when linking (so features defined in CROSSTOOL may be used here). |
112
112
| <aid="SwiftToolchainInfo-root_dir"></a>root_dir |`String`. The workspace-relative root directory of the toolchain. |
113
113
| <aid="SwiftToolchainInfo-swift_worker"></a>swift_worker |`File`. The executable representing the worker executable used to invoke the compiler and other Swift tools (for both incremental and non-incremental compiles). |
114
-
| <aid="SwiftToolchainInfo-test_configuration"></a>test_configuration |`Struct` containing two fields:<br><br>*`env`: A `dict` of environment variables to be set when running tests that were built with this toolchain.<br><br>*`execution_requirements`: A `dict` of execution requirements for tests that were built with this toolchain.<br><br>This is used, for example, with Xcode-based toolchains to ensure that the `xctest` helper and coverage tools are found in the correct developer directory when running tests. |
114
+
| <aid="SwiftToolchainInfo-test_configuration"></a>test_configuration |`Struct` containing the following fields:<br><br>*`env`: A `dict` of environment variables to be set when running tests that were built with this toolchain.<br><br>*`execution_requirements`: A `dict` of execution requirements for tests that were built with this toolchain.<br><br>*`uses_xctest_bundles`: A Boolean value indicating whether test targets should emit `.xctest` bundles that are launched with the `xctest` tool.<br><br>This is used, for example, with Xcode-based toolchains to ensure that the `xctest` helper and coverage tools are found in the correct developer directory when running tests. |
115
115
| <aid="SwiftToolchainInfo-tool_configs"></a>tool_configs | This field is an internal implementation detail of the build rules. |
116
116
| <aid="SwiftToolchainInfo-unsupported_features"></a>unsupported_features |`List` of `string`s. Features that should be implicitly disabled by default for targets built using this toolchain, unless overridden by the user by listing them in the `features` attribute of a target/package or in the `--features` command line flag.<br><br>These features determine various compilation and debugging behaviors of the Swift build rules, and they are also passed to the C++ APIs used when linking (so features defined in CROSSTOOL may be used here). |
Compiles and links Swift code into an executable test target.
686
686
687
-
The behavior of `swift_test` differs slightly for macOS targets, in order to
688
-
provide seamless integration with Apple's XCTest framework. The output of the
689
-
rule is still a binary, but one whose Mach-O type is `MH_BUNDLE` (a loadable
690
-
bundle). Thus, the binary cannot be launched directly. Instead, running
691
-
`bazel test` on the target will launch a test runner script that copies it into
692
-
an `.xctest` bundle directory and then launches the `xctest` helper tool from
693
-
Xcode, which uses Objective-C runtime reflection to locate the tests.
694
-
695
-
On Linux, the output of a `swift_test` is a standard executable binary, because
696
-
the implementation of XCTest on that platform currently requires authors to
697
-
explicitly list the tests that are present and run them from their main program.
698
-
699
-
Test bundling on macOS can be disabled on a per-target basis, if desired. You
700
-
may wish to do this if you are not using XCTest, but rather a different test
701
-
framework (or no framework at all) where the pass/fail outcome is represented as
702
-
a zero/non-zero exit code (as is the case with other Bazel test rules like
703
-
`cc_test`). To do so, disable the `"swift.bundled_xctests"` feature on the
704
-
target:
705
-
706
-
```python
707
-
swift_test(
708
-
name="MyTests",
709
-
srcs= [...],
710
-
features= ["-swift.bundled_xctests"],
711
-
)
712
-
```
713
-
714
-
You can also disable this feature for all the tests in a package by applying it
715
-
to your BUILD file's `package()` declaration instead of the individual targets.
687
+
By default, this rule performs _test discovery_ that finds tests written with
688
+
the `XCTest` framework and executes them automatically, without the user
689
+
providing their own `main` entry point. See the documentation of the
690
+
`discover_tests` attribute for more information about how this affects the rule
691
+
output and how to control this behavior.
716
692
717
693
If integrating with Xcode, the relative paths in test binaries can prevent the
718
694
Issue navigator from working for test failures. To work around this, you can
@@ -738,6 +714,7 @@ bazel test //:Tests --test_filter=TestModuleName.TestClassName/testMethodName
738
714
| <aid="swift_test-data"></a>data | The list of files needed by this target at runtime.<br><br>Files and targets named in the `data` attribute will appear in the `*.runfiles` area of this target, if it has one. This may include data files needed by a binary or library, or other programs needed by it. | <ahref="https://bazel.build/concepts/labels">List of labels</a> | optional |`[]`|
739
715
| <aid="swift_test-copts"></a>copts | Additional compiler options that should be passed to `swiftc`. These strings are subject to `$(location ...)` and ["Make" variable](https://docs.bazel.build/versions/master/be/make-variables.html) expansion. | List of strings | optional |`[]`|
740
716
| <aid="swift_test-defines"></a>defines | A list of defines to add to the compilation command line.<br><br>Note that unlike C-family languages, Swift defines do not have values; they are simply identifiers that are either defined or undefined. So strings in this list should be simple identifiers, **not**`name=value` pairs.<br><br>Each string is prepended with `-D` and added to the command line. Unlike `copts`, these flags are added for the target and every target that depends on it, so use this attribute with caution. It is preferred that you add defines directly to `copts`, only using this feature in the rare case that a library needs to propagate a symbol up to those that depend on it. | List of strings | optional |`[]`|
717
+
| <a id="swift_test-discover_tests"></a>discover_tests | Determines whether or not tests are automatically discovered in the binary. The default value is `True`.<br><br>If tests are discovered, then you should not provide your own `main` entry point in the `swift_test` binary; the test runtime provides the entry point for you. If you set this attribute to `False`, then you are responsible for providing your own `main`. This allows you to write tests that use a framework other than Apple's `XCTest`. The only requirement of such a test is that it terminate with a zero exit code for success or a non-zero exit code for failure.<br><br>Additionally, on Apple platforms, test discovery is handled by the Objective-C runtime and the output of a `swift_test` rule is an `.xctest` bundle that is invoked using the `xctest` tool in Xcode. If this attribute is used to disable test discovery, then the output of the `swift_test` rule will instead be a standard executable binary that is invoked directly. | Boolean | optional | `True` |
741
718
| <aid="swift_test-env"></a>env | Dictionary of environment variables that should be set during the test execution. | <ahref="https://bazel.build/rules/lib/dict">Dictionary: String -> String</a> | optional |`{}`|
742
719
| <aid="swift_test-linkopts"></a>linkopts | Additional linker options that should be passed to `clang`. These strings are subject to `$(location ...)` expansion. | List of strings | optional |`[]`|
743
720
| <aid="swift_test-malloc"></a>malloc | Override the default dependency on `malloc`.<br><br>By default, Swift binaries are linked against `@bazel_tools//tools/cpp:malloc"`, which is an empty library and the resulting binary will use libc's `malloc`. This label must refer to a `cc_library` rule. | <ahref="https://bazel.build/concepts/labels">Label</a> | optional |`"@bazel_tools//tools/cpp:malloc"`|
0 commit comments