javascript_test
A single Javascript test file.
Backend: pants.backend.experimental.javascript
source
strA single file that belongs to this target.
Path is relative to the BUILD file's directory, e.g. source='example.ext'.
batch_compatibility_tag
str | NoneNoneAn arbitrary value used to mark the test files belonging to this target as valid for batched execution.
It's sometimes safe to run multiple javascript_tests within a single test runner process, and doing so can give significant wins by allowing reuse of expensive test setup / teardown logic. To opt into this behavior, set this field to an arbitrary non-empty string on all the javascript_test targets that are safe/compatible to run in the same process.
If this field is left unset on a target, the target is assumed to be incompatible with all others and will run in a dedicated nodejs test runner process.
If this field is set on a target, and its value is different from the value on some other test javascript_test, then the two targets are explicitly incompatible and are guaranteed to not run in the same nodejs test runner process.
If this field is set on a target, and its value is the same as the value on some other javascript_test, then the two targets are explicitly compatible and may run in the same test runner process. Compatible tests may not end up in the same test runner batch if:
- There are "too many" compatible tests in a partition, as determined by the
[test].batch_sizeconfig parameter, or - Compatible tests have some incompatibility in Pants metadata (i.e. different
resolves orextra_env_vars).
When tests with the same batch_compatibility_tag have incompatibilities in some other Pants metadata, they will be automatically split into separate batches. This way you can set a high-level batch_compatibility_tag using __defaults__ and then have tests continue to work as you tweak BUILD metadata on specific targets.
dependencies
Iterable[str] | NoneNoneAddresses to other targets that this target depends on, e.g. ['helloworld/subdir:lib', 'helloworld/main.py:lib', '3rdparty:reqs#django'].
This augments any dependencies inferred by Pants, such as by analyzing your imports. Use pants dependencies or pants peek on this target to get the final result.
See https://www.pantsbuild.org/v2.18/docs/targets for more about how addresses are formed, including for generated targets. You can also run pants list :: to find all addresses in your project, or pants list dir to find all addresses defined in that directory.
If the target is in the same BUILD file, you can leave off the BUILD file path, e.g. :tgt instead of helloworld/subdir:tgt. For generated first-party addresses, use ./ for the file path, e.g. ./main.py:tgt; for all other generated targets, use :tgt#generated_name.
You may exclude dependencies by prefixing with !, e.g. ['!helloworld/subdir:lib', '!./sibling.txt']. Ignores are intended for false positives with dependency inference; otherwise, simply leave off the dependency from the BUILD file.
description
str | NoneNoneA human-readable description of the target.
Use pants list --documented :: to see all targets with descriptions.
extra_env_vars
Iterable[str] | NoneNoneAdditional environment variables to include in test processes.
Entries are strings in the form ENV_VAR=value to use explicitly; or just ENV_VAR to copy the value of a variable in Pants's own environment.
This will be merged with and override values from [test].extra_env_vars.
tags
Iterable[str] | NoneNoneArbitrary strings to describe a target.
For example, you may tag some test targets with 'integration_test' so that you could run pants --tag='integration_test' test :: to only run on targets with that tag.
timeout
int | NoneNoneA timeout (in seconds) used by each test file belonging to this target.
If unset, will default to [test].timeout_default; if that option is also unset, then the test will never time out. Will never exceed [test].timeout_maximum. Only applies if the option --test-timeouts is set to true (the default).