NASA-AMMOS / NASA-AMMOS/plandev

Provide mechanism for identifying spawned child activities in testing

Open
#801 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

clipper
Dominant language
Java
Stars
128
Forks
33
Avg merge
1d 17h
Merged PRs (30d)
12

Description

gavinm
https://jira.jpl.nasa.gov/browse/AERIEQS-223
Medium
As we get further into activity implementation, we've increasingly made use of the Merlin JUnit5 extension which allows us to write tests in which we execute activities and make assertions about the resulting state values. This gets us part of the way through activity V&V, but the biggest missing piece is the ability to make assertions that an activity decomposed into child activities.

E.g., an instance of activity type Parent may decompose into two instances of ChildA, an instance of ChildB, and conditionally (based upon some state value or parameter) decompose into ChildC. It is essential that we have the ability to verify that decompositions did occur during testing in order to support our V&V efforts.

This information is already being tracked within the Aerie system (since you're able to associate child activities with parents via API calls); we'd like a way to do it from activity unit tests.

Originally brought up via Slack here: [https://jpl.slack.com/archives/C0163E42UBF/p1626216769131900]

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Merlin JUnit5 extension and existing activity unit tests, then trace how child activities are associated with parents through the Aerie APIs. Define how tests should observe decompositions, including conditional children, and consider the work complete when activity tests can assert the spawned child activities.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
testing
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.