Closed nickw444 closed 4 years ago
Hey @nickw444
Thanks for the issue, and sorry for the late response.
It is possible to simulate arguments that would be passed via the apps.yaml
config, but using @automation_fixture
is not the way to go. Passing arguments to @automation_fixture
allows for parametrised tests.
To pass arguments to apps just like apps.yaml
would do, use given_that.passed_arg(ARG_KEY).is_set_to(ARG_VAL)
See:
apps.yaml
configMaybe the documentation could benefit from some readability upgrade. Once you understand how everything work, and once it's working for you, maybe you could submit a PR with your suggestions on how to make the documentation more readable? 🙂 But don't feel like you have to, I'm already happy when anyone is using our tool 😊
Best, Florian
Explanation of what passing args to
@automation_fixture
doesIn that example
@automation_fixture((MyAutomation, { 'foo': 'bar' })) def my_automation(): pass
my_automation
would not actually represent your automation, a better name for this fixture would bemy_automation_with_arguments
. Indeed when adding arguments to@automation_fixture
the fixture returned is not just the automation, but the automation with the arguments. This is useful for parameterized testing, but has nothing to do with the arguments passed viaapps.yaml
To see an example of how it work, you can check this test where it showcases the feature: https://github.com/FlorianKempenich/Appdaemon-Test-Framework/blob/master/test/test_automation_fixture.py#L264-L322
The documentation seems to imply when configuring a fixture I can provide arguments that will be accessible during
initialize
:However, my test failed when trying to access
this.args
withininitialize
:Example Code:
My workaround is currently to do the following, but wondering if there was a more "blessed" way to achieve this: