(1) could we consider explicitly just sort of using your four-word descriptions as the snake-cased method names directly? (2) it sounds like your #3 and #4 are reasonable to keep separate for now! (3)

integration tests for Pants

this isn't 100% clear imho. perhaps "integration test for pants plugin code"?

could we consider explicitly just sort of using your four-word descriptions as the snake-cased method names directly

Possibly. Related is that we need to answer where the utils live, also, e.g. *

testutil/rule_unit_tests.py

*

testutil/rule_integration_test.py

But then I didn’t like this at all:

from pants.testutil.rule_integration_test import RuleRunner

It’s not predictable. I’m pretty sure that we want to call this type

RuleRunner

. Which led to me thinking we have

from pants.testutil.rule_runner import RuleRunner

def test() -> None:
  RuleRunner.run_rule_with_mocks(foo, gets=MockGet(...))

// or

def test(rule_runner: RuleRunner) -> None:
   rule_runner.request_product(P, [S])

ok i think that setup makes sense as more describing what it is rather than what it does, thanks

i personally prefer the explicit injection of RuleRunner

This is the part I don’t love about my proposal. With

run_rule

/ aka

RuleRunner.run_rule_with_mocks()

, you do not want to have to actually create an instance of

RuleRunner

. That’s more setup than you’d like, and

run_rule()

will ignore all that setup. It’s a classmethod for that reason, so you would not have it injected via a fixture But that’s really subtle, and I could see plugin authors unintentionally doing more work than they really need to

ok yes re: classmethod making it not directly useful to "inject" anything

Great point about the connotation of run. I like

simulate_rule()

, I think! The tricky thing is it does actually execute your rule, just not any of the things outside your rule like `Get`s and the inputs to your rule

ok yes! i like that

I suspect that

engine_util.execute_rule_with_mocks()

would be the least used of the 4 approaches, as that’s not super discoverable. But also honestly maybe not a huge deal. I suspect after writing these plugin docs that the vast majority of plugin authors will want approaches #3 and #4 In our own repo,

run_rule()

is really only useful for our highly generic rules like

test.py

and

lint.py

In our own repo, run_rule() is really only useful for our highly generic rules like test.py and lint.py

that's a great point and should maybe be included in docs if not already??

Agreed 🙂 not yet in the docs as I’ve been waiting to figure out what approaches #2 and #3 will look like.

pants_run()

is the first that’s seen lots of love, and today’s changes were for

TestBase