SQA: Define high priority files with low-level requirements and higher coverage requirement
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- c
- Domain
- testing-qa
Research direction
Read the current coverage configuration and the existing tests for flight.c and state_transition.c, which the issue names as the firmware's most detailed tests. Check referenced issue #324 for the earlier requirement-tagging proposal, since this issue may obsolete it. Done means the two files are flagged as high priority with documented system and low-level requirement tags plus a coverage threshold above the current every-line baseline, and the automated test run consumes those tags.
Written by the indexing model from the issue text.
Description
Version: v2.8.0
Describe the feature you'd like
Currently, every file in the firmware requires the same level of coverage: every line is covered. However, there are high priority files that should be tested more closely to ensure high level logic works properly.
Luckily, the two immediate candidates flight.c and state_transition.c both have some of the best written and most detailed tests in the firmware. These will be pretty easy to get to the right coverage burden, and we only have to develop the requirements. We should also create tags for the system requirements and low-level requirements for use in automated testing (ref: #324 -- may obsolete).
Describe alternatives you've considered
N/A
Additional context
N/A
Points of Contact
Firmware lead: @NArmistead
SQA SME: @ETSells
- Dominant language
- C
- Stars
- 8
- Forks
- 6
- Avg merge
- 5d 6h
- Merged PRs (30d)
- 5
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SunDevilRocketry/Flight-Computer-Firmware
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
SunDevilRocketry/Flight-Computer-Firmware#347 ·
Maintainers usually reply within 3 days
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
SunDevilRocketry/Flight-Computer-Firmware#339 ·
Maintainers usually reply within 3 days
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 20/100
SunDevilRocketry/Flight-Computer-Firmware#346 ·
Maintainers usually reply within 3 days
-
EPIC: v2.8.0 major refactors and breaking changesPossibly taken @NArmistead claimed this 5 days ago. Openadvanced Epic refactor
SunDevilRocketry/Flight-Computer-Firmware#341 · 2 assignees ·
Maintainers usually reply within 3 days
-
System Tests [v2.7.0]: Re-execute Telemetry integration testPossibly taken @NArmistead claimed this 13 days ago. Openverification
SunDevilRocketry/Flight-Computer-Firmware#337 · 1 comment · 1 assignee ·
Maintainers usually reply within 3 days
All issues in SunDevilRocketry/Flight-Computer-Firmware
Similar issues
-
IO.get_env on Node truncates names at embedded NULPossibly taken @Yi-111-a claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
HigherOrderCO/Bend#1449 · 1 comment ·
-
bug C/C++ code
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
webarkit/WebARKitLib#84 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
OpenPrinting/cups#1751 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
es-ude/OnDeviceTraining#488 ·
Maintainers usually reply within 1 day
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 1 day