Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass a reference to the sequencer when calling TestClass.test #127

Open
clint-lawrence opened this issue Sep 18, 2020 · 0 comments
Open

Comments

@clint-lawrence
Copy link
Collaborator

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.

class SequencerProxy:
    def __init__(self, sequencer: Sequencer):
      self._sequencer = sequencer
  
    @property
    def context(self):
        return list(self.sequencer.context)
  
    @property
    def script_params(self):
        return self.sequencer.context_data

class TestClass:
    # the sequencer would call this method instead of calling test directly.
    def test_internal(self, sequencer_proxy):
        # Returns a dict of test data that this class needs from containing TestLists
        kwargs = get_test_data(sequencer_proxy.context)  
        self.test(**kwargs)

    def test(self):
        # overridden by the test implementation.
        raise NotImplementedError

   ... 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant