What do y all think about this Rather than subclassing `Test Pants #development

What do y’all think about this? Rather than subcla...

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.

source_files_test.py

🔥 1

🚀 1

👖 1

hundreds-father-404

08/24/2020, 2:47 AM

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

hundreds-father-404

08/24/2020, 2:49 AM

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

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

Open in Slack

Previous Next