The current nodemanager tests will spawn a --test-mode instance of the nodemanager to run the test cases against. Tests and test-mode NM run on the same machine. However, this is difficult to do correctly on platforms like Android, where we often don't have proper shell access, and/or extra caution may be needed (with respect to Popen (SeattleTestbed/utf#53), standard streams (SeattleTestbed/utf#68), C libraries (SeattleTestbed/repy_v2#98) etc.)
To run the tests against a remote NM instance, the tests would use the owner key pair for the vessels-to-test, rather than creating fresh temporary keys and setting up a local NM. Afterwards, the tests should proceed as they do now, testing NM API interactions and so on.
This raises a couple of design questions.
How do signal to the test that you want to test a remote NM? (Just leave a specially-named key pair in the test dir?)
What exact configuration does the remote vessel need? (Number of vessels, keys used; resources?)
Which tests can be run against a remote NM? (E.g., we can't access the nodemanager log in the general case.)
What additional tests do we need?
I would prefer to not duplicate all of the existing tests in a separate test module namespace. NM tests should probably default to the usual all-local method unless an educated user flips the required switch to run against a remote NM instance.
The current nodemanager tests will spawn a
--test-modeinstance of the nodemanager to run the test cases against. Tests and test-mode NM run on the same machine. However, this is difficult to do correctly on platforms like Android, where we often don't have proper shell access, and/or extra caution may be needed (with respect toPopen(SeattleTestbed/utf#53), standard streams (SeattleTestbed/utf#68), C libraries (SeattleTestbed/repy_v2#98) etc.)To run the tests against a remote NM instance, the tests would use the owner key pair for the vessels-to-test, rather than creating fresh temporary keys and setting up a local NM. Afterwards, the tests should proceed as they do now, testing NM API interactions and so on.
This raises a couple of design questions.
I would prefer to not duplicate all of the existing tests in a separate test module namespace. NM tests should probably default to the usual all-local method unless an educated user flips the required switch to run against a remote NM instance.