https://pantsbuild.org/ logo
Join SlackCommunities
Powered by
<@U04S45AHA>: what did you mean about intrinsics?
# development
w
@enough-analyst-54434: what did you mean about intrinsics?
(thread)
e
Well, when your creating an engine in a test, you add in rules. In this case there are 3, two in Greg's test (both new) and 1 in the base test. But really, the engine adds in intrinsics too. It would be nice - in tests - for it not to.
Then you could say - the universe of rules is exactly these 5, use these only.
As it stands you get many more and have to satisfy unseen things. Not grerat for a unit-test that tests whats at hand.
w
you can skip calling 
super
but it's a lot to build up from scratch
e
It shouldn't be though. His universe is 5 types
He should be anble to hand inject those 5 types in the test
w
hm. yea.
so, to be clear: this had nothing to do with the other rules
e
Basically, a rule unit test should need only inject an instance of the right type for all rule params and possible Gets
w
and everything to do with the actual rule he installed
@enough-analyst-54434: this is "sortof" a unit test
if you want a unit test, use 
run_rule
...
when you're testing multiple rules together, you need to seal up the "boundaries" around your rule
e
OK... this is all clear as mud to me at the moment. Hopefully more time in SLC to look.
Yes, exactly. But you should never need multiple rules, just yours + 1 per unique get
In a unit test
w
should only actually create a scheduler when you want to test multiple rules together
run_rule
requires no scheduler, and no other rules
everything is mocked
e
In fact you shouldn't need a 
run_rule
, just call the function. Unless 
run_rule
mocks Gets which is probably what it does,
w
yea, it does
the lambdas produce the results for your Gets
e
I'd still love Gets to be able to be functions passed into rules to get rid of that. I wish it were structurally possible.
w
cc @hundreds-breakfast-49010: ^
h
IIRC 
run_rule
requires providing mocks for every 
yield Get
anywhere in the rule or any subrules it uses?
and yeah if you just called a rule as a function it would return a generator object if it had any yields in it
e
Yeah. That's where I'd hoped way back we could not introduce yield Get and instead inject 1st class functions as params into rules.
And hide the yielding / coroutines inside those function (wrappers).
h
it does seem like a lot of unit tests are subclasses of 
TestBase
that define a 
rules()
clss function and basically run a minimal rule graph
but either way, I'd have to mock a 
HydratedTarget
since that's what (as I understand it) stu thinks the signature of this new 
@rule
ought to be
w
anywhere in the rule
yes
or any subrules it uses
no
^ because it can't use other rules
e
But
or any subrules it uses
Is right in spirit correct, but maybe spelling is wrong? A Get maps to a rule in the end
w
not with 
run_rule
... you provide the computation of the result value of the yield
e
The lambdas are Gets / rules
w
there is exactly one rule in 
run_rule
in
Copy code
address_mapper = AddressMapper(JsonParser(TEST_TABLE))
    af = run_rule(parse_address_family, address_mapper, Dir('/dev/null'), {
        (Snapshot, PathGlobs): lambda _: Snapshot(Digest('abc', 10), ('/dev/null/BUILD',), ()),
        (FilesContent, Digest): lambda _: FilesContent([FileContent('/dev/null/BUILD', b'', False)]),
      })
    self.assertEqual(len(af.objects_by_name), 0)
... the two lambdas compute the values of the two 
yield
statements in the 
parse_address_family
rule
e
Yeah - the lambda is a mocked Get impl which is - in spirit - a rule
This is why I mentioned spelling
w
should have included more of it
e
Gotcha
w
but: you only provide mocks for the yields in the rule, because there are no subrules
Open in Slack
PreviousNext
Powered by