Open MCT is a next-generation mission control framework for data visualization on desktop and mobile devices. It was created at NASA’s Ames Research Center, and NASA uses it to analyze spacecraft mission data.

In this intriguing session, John Hill, a Web UI Test Engineer at the NASA Ames Research Center, outlines how the Open MCT project is leveraging the testing community to write mission-critical e2e tests.

ohn kicks off the session by introducing Open MCT.

The Open Mission Control Technologies, or the Open MCT, will be seen as a part of the VIPER Mission, which is set to launch in the upcoming years. NASA’s VIPER mission will be to head to the South Pole of the Moon in search of evidence of water.

John talks about the rapid changes in the industry, moving from the thick clients installed on an app for Python or a Java app installed with a specific binary and packaged differently based on a Mac or Windows. One of the powerful things seen in the industry is the move towards the web, which allows Mission Control software to run anywhere.

So part of a larger initiative at NASA, they decided to provide the Mission Control software through Open Source. It allows you to get an insight into any visualization that a mission control operator would need.

Open E2E Test Initiative Goals

• Increase our test coverage: Keeping track of your code coverage and aiming to increase those numbers with the community’s help.

• Get Open Source contributions: Provide an opportunity for the testing community to contribute to this NASA Open Source project directly.

• Knowledge: Helping people learn from the community represents new approaches to old testing practices with Playwright.

• Ensure the Open MCT is accessible.

John went on to give a brief overview of the history of this open source project which made him realize how to leverage the community to help him and the development team.

Getting started with Open MCT’s implementation of Playwright

Starting by reading through the development guide, John pulled up a terminal window and ran it locally after installing the NPM and the git clone to get the NPM start and have Open MCT running on 8080.

He then went on to create a plot object overlay demo. One of how you can visualize data is through a plot. And after successfully editing and saving the project, the last thing to do is create an example Telemetry object.

Moving on to the next step, John performed the same in Playwright using the Playwright CodeGen tool. Through this process, John captures everything a mission control operator would do to create a similar layout and records it as a series of recorded playback steps.

The next requirements in the test would be:

• Close any terminals serving up a local instance.

• Run the example test in debug mode.

John shares that after working on Playwright for over a year, he has learned more and more about its application. It led to constantly testing and reinforcing changes over time to help give new people from the development team a place to start.

But John calls out a few specific features from the test:

• They had to extend the base functionality of Playwright in all of the tests.

• They also added helper functions in the app actions.

• test.fixme is a decorator for a skip that allows addressing and isolating tests that do not yet exist.

To end the demo, John summarized the following:

• He utilized playwright to mimic operator behavior to interact with Open MCT exactly as a mission control operator.

• He demonstrated how easy it is to start writing with the CodeGen tool and debug tests with the debug flag to step through each test and watch it run live.

• How Open MCT reinforces internal evolving best practices into the onboarding process.

• How test stubs and test.fixme coexists.

While listing some of the challenges with any E2E project, John also suggests a few solutions to tackle these issues. Here are some of them:

• Onboarding issues.

Solution: To reinforce an example template, provide linting, enforcement, and heavy self-documenting code to get people started quickly.

• Web-dev-ism.

Solution: Despite the improvements made to the fixtures, generalizing functions, etc., failure must be evident in Trace files and error logs.

John highlighted that one of the challenges he comes across is a few community members trying to make a change for their benefit. These situations end up reordering the import statements.

Lastly, he wants you to Open Source!

QnA Round!

How can one go about contributing plugins to open MCT?

John: The project has been around for a while, so the process for contributing plugins is pretty well established, and it’s available on the website as to how to do it specifically.

Are there any plans to use typescript vs JavaScript?

John: As not allowed to speak on any commitments, but what you just saw are typings built into the tests and the usage of typescript hints, and some typing sporadically throughout the application. So, when working with specific APIs, you will find typing hints, though it can’t be confirmed if there are any plans to merge.

Can we automate end-to-end tests using APIs?

John: API tests are automated as coming to and from the persistent data store and provide examples of how you could do that. The two things that can be highlighted are:

• There are two APIs that share the real-time data in the browser context, which includes token authentication and more.

• There is also a direct line of API requests to and from the node process that runs without authentication.