https://pantsbuild.org/ logo
#development
Title
# development
h

hundreds-father-404

08/24/2020, 2:45 AM
What do y’all think about this? Rather than subclassing
TestBase
, tests can use Pytest style of top-level functions. The expectation would be for each test file to create a Pytest fixture that returns a
RuleRunner
type, which wraps a SchedulerSession and exposes entry points like
create_file
and
request_product
. Because it’s a fixture, you define it once, and then each individual test gets a new copy of the
RuleRunner
, which preserves the test isolation we need. If you want multiple distinct setups in your test file, you can create multiple fixtures. The test then says which fixture it wants to use.
🔥 1
🚀 1
👖 1
An explicit goal of this project is to move towards Pytest style tests, rather than unittest, in line with the direction of the project the past year. Pytest style tests are more composable and provide nice things like test parametrization and pre-built fixtures
pants_integration_test.py
is now changed to use Pytest style with the top-level function
run_pants()
.
run_rule()
has always been that way.
TestBase.request_product()
is the only hold out
RuleRunner
will take as optional args the normal classmethod boilerplate we have, e.g.
Copy code
RuleRunner(target_types=[PythonLibrary], rules=[*python_sources.rules(), foo])
Because it’s a dataclass with a constructor, we can do things like add a boolean parameter
register_util_rules: bool = True
, which will pre-register those to ameloriate the issue with rule registration being icky
💥 1
a

aloof-angle-91616

08/24/2020, 2:52 AM
i like that a lot!! best practices for unstable kwargs are in general to move it to a wrapper struct (like this) when it gets too complex i think
💯 1