Unit Test APRS.py

[abagali1]

Methods To Test

Send (Flight -> GS)

Inputs

• Normal-sized string that fits within bounds
• Long string
• Short string
• Empty string
• String of spaces
• String of newline/escape characters

Outputs

• Message should be displayed on the ground terminal
• RAW String should be base64 encoded

Recieve(GS -> Flight)

Inputs

Non-Commands

• Normal-sized string that fits within bounds
• Long string
• Short string
• Empty string
• String of spaces
• String of newline/escape characters

Commands

• "$" + Actual Command
• "$" + Invalid Command Name
• "$" + Non-Command Strings

Outputs

Non-Commands

• Echos back to GS

Commands

• Should see evidence of executed function
• Echo "execution successful" to GS

IMPORTANT Unit testing should not include an intermediary. These tests should directly interface with the submodule file and only output can be viewed on an intermediary. (e.x. Test recieve() by sending from another file, not from the GS Terminal)

[abagali1]

Assigned @sparthaje as original developer, @ayusher as testing coordinator, and @amtron521 as hardware supervisor. Your job is to create a new file called aprs_test.py in the submodules/radio directory or add a main method to aprs.py(if __name__ == '__main__':) so that when either is run(python submodules/radios/aprs_test.py or python submodules/radios/aprs.py) a series of unit testing cases will run. Afterwards, you shall examine the output see if it is consistent with flight requirements and report back. If you do see any mistakes or bugs in the output, it is your job to report the input and the corresponding output. It is not your job to trace the bug to its origin, although if you suspect a block of code is working incorrectly, it would be helpful to know that as well. Submit any incorrect outputs and/or bugs as an issue with the label bug on this repo. Make sure that any changes you might make while creating testing code is done on the testing branch and not on any other branch.

[abagali1]

In addition to the above tasks, if any change to flight behaviour or infrastructure is needed, make those changes as well. If you do need to make any changes to flight behaviour, either document it ASAP or let me know in person

[sparthaje]

I don't think APRS module should be responsible for echoing back non-commands. Shouldn't it be taken care of higher up (ie Telemetry when APRS enqueues the non-command)

[sparthaje]

We should also test what happens if the serial port closes in the middle of listening/writing to see if the APRS module handles it.