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
To maintain backward compatibility, we wouldn't do this directly. Instead, we can add a new internal method to TestClass which will be called by the sequencer, and that new method will then call the original TestClass.test. And instead of directly passing a reference to the sequencer, I think we could create a SequencerProxy object. The methods on this object would represent the public interface that is O.K. for test scripts rely on.
e.g.
classSequencerProxy:
def__init__(self, sequencer: Sequencer):
self._sequencer=sequencer@propertydefcontext(self):
returnlist(self.sequencer.context)
@propertydefscript_params(self):
returnself.sequencer.context_dataclassTestClass:
# the sequencer would call this method instead of calling test directly.deftest_internal(self, sequencer_proxy):
# Returns a dict of test data that this class needs from containing TestListskwargs=get_test_data(sequencer_proxy.context)
self.test(**kwargs)
deftest(self):
# overridden by the test implementation.raiseNotImplementedError
... etc
This idea was motivated by thinking about #126
At the moment, we can't easily share data from the sequencer to tests. We added the context_data dict to the sequencer and some scripts use that as a way to pass some data from the sequencer into the script. But this requires the TestClass.test method to reach into RESOURCES["SEQUENCER"], accessing the global sequencer instance.
With this change, we could implement Ryan's idea "5" from here without having to add much extra complexity to the sequencer and provide a more general method to make the use of context_data more explicit where it's used.
If the need arises, we could also do the same treatment to setup/teardown/enter/exit.
The text was updated successfully, but these errors were encountered:
To maintain backward compatibility, we wouldn't do this directly. Instead, we can add a new internal method to TestClass which will be called by the sequencer, and that new method will then call the original TestClass.test. And instead of directly passing a reference to the sequencer, I think we could create a SequencerProxy object. The methods on this object would represent the public interface that is O.K. for test scripts rely on.
e.g.
This idea was motivated by thinking about #126
At the moment, we can't easily share data from the sequencer to tests. We added the context_data dict to the sequencer and some scripts use that as a way to pass some data from the sequencer into the script. But this requires the TestClass.test method to reach into RESOURCES["SEQUENCER"], accessing the global sequencer instance.
With this change, we could implement Ryan's idea "5" from here without having to add much extra complexity to the sequencer and provide a more general method to make the use of context_data more explicit where it's used.
If the need arises, we could also do the same treatment to setup/teardown/enter/exit.
The text was updated successfully, but these errors were encountered: