You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just had to implement this function in Starlark:
# starlark has no 'rjust', and 'format' does not support padding with# zeros, so we have to do this manually.defrjust(s: str, pad: str, width: int) ->str:
iflen(s) >=width:
returnsreturnpad* (width-len(s)) +s
What I'd like to do is write a test for this in terms of buck2 test, but I don't really think I can. I don't see why it shouldn't be possible, though?
For example you could imagine a BUILD file that does something like this:
test_starlark_assert could then just be a rule that returns some provider containing a pass/fail status, and the logic itself can actually be in the rule (this would allow you to have things like expected failures and write them on your own). Because these tests are actually pure you could have a family of providers you return:
def_test_starlark_assert_impl(...):
# ...ifexpected==actual:
pass_fail_info=PureTestPassResult('passed')
else:
pass_fail_info=PureTestFailureResult(f'expected value {expected} but got value {actual}')
return [ DefaultInfo(), pass_fail_info ]
I understand the TestInfo v2 thing won't be done for a while now, but this seems like a rather independent addition to the API.
The text was updated successfully, but these errors were encountered:
At the bottom of the file. Means these tests run in every single run, but they are typically millisecond duration, and if they fail, the consequences are often serious. As an example,
I just had to implement this function in Starlark:
What I'd like to do is write a test for this in terms of buck2 test, but I don't really think I can. I don't see why it shouldn't be possible, though?
For example you could imagine a BUILD file that does something like this:
test_starlark_assert
could then just be a rule that returns some provider containing a pass/fail status, and the logic itself can actually be in the rule (this would allow you to have things like expected failures and write them on your own). Because these tests are actually pure you could have a family of providers you return:I understand the TestInfo v2 thing won't be done for a while now, but this seems like a rather independent addition to the API.
The text was updated successfully, but these errors were encountered: