The purpose of this page is to describe the new software engineering workflow I propose that we adopt in order to transition towards test-driven development (TDD). Our current method lacks structured testing strategies, which will cause many problems during the integration phase. Our development process should be effectively testing software components both individually and integrated with the rest of the system. The following document will talk about unit testing, system integration testing, and design steps in detail, and how we can ensure our software is reliable and easy to integrate.
Figure 1: The Firmware Workflow diagram is designed to ensure that all software designs adhere to mission requirements and can effectively be integrated into the flight architecture.
Now that most of our projects are moving into the implementation phase, it’s necessary to establish a workflow to ensure high-quality software development. It’s easy to assume that our code needs to pass any generic unit test before it can be integrated into our flight architecture, however we need to keep in mind that our software must adhere to the mission requirements. Hence the Firmware Workflow is designed to ensure that our implementations, unit testing, and system testing are adhering to requirements found in .
Let’s break down the process you should be following in each of the workflow stages:
Yes, we unfortunately cannot just started coding from the start. Even if we know what to do. Each task page will have links to requirements that the assignment is derived from. Take some time to read through the requirement and understand the purpose that the task serves to the overall mission and our flight software architecture. Understanding this information will help guide your designs much better. Even if that means a trip back to APS111 (or whatever the Praxis course code is).
I find that whenever I write unit tests AFTER creating the source code, I am a bit biased to come up with test cases that I know will pass on the first try. Or I’ll be lazier when looking for edge cases, because I’ll be tempted to just write tests for edge cases I consider during implementation. We obviously don’t want to work this way. In the HLD phase, it is required to create the header file FIRST (writing function declarations, structs, enums, etc.), as a way to force you to think about the design of your code. Using that header file, you will then create a test plan, which is a word document (see below for the template) that qualitatively describes the testing strategies you will be using. This way, your test cases are created based on the requirements, rather than your code implementation. Once you are completed, ping @Eesa Aamer, @Kevin Caldwell , or @Mirai SHINJO and get them to approve your designs and test plans prior to the next stage.
Detailed Design is the fun part. This is where you implement that functions that you have declared in header files during the HLD phase. During this stage, please ensure that you are following the style guide and best practices outlined by Firmware Design Guidelines. Failure to do so will result in a lot of repetitive comments on your pull request (Which I will not hesitate to do 😈).
[UPCOMING]
[UPCOMING]
The final step of the process is to submit a pull request on the branch that you have been working on so far. Your fellow Firmware members will review and leave comments on your code regarding improvements to style, identifying any bugs, or overlooked edge cases. Once all comments have been addressed, a pull request on the dev repos requires at least one approval before being merged. Alongside a code review, you may be asked to demo your code to the leads as well as any relevant stakeholder, where you can be given further feedback.