Initial end-to-end tests via GitHub Actions

[jmtsuji]

@LeeBergstrand I'm starting to work on automated tests for spokewrench via GitHub Actions (my first time using GitHub Actions). It seems like GitHub Actions might only become enabled for the repo after I set up the relevant workflow files in main. I've set up a skeleton test workflow... would you mind if I push this into main for testing purposes? I might need to make multiple commits to main in the coming days to troubleshoot. Let me know your thoughts -- thanks.

[jmtsuji]

@LeeBergstrand Never mind -- it seems that creating this PR made the new GitHub Actions workflows visible to GitHub. I no longer need to merge this anytime soon, because I can keep developing things just on the current testing branch. I will keep updating this PR for testing purposes, but I don't need a review right away... please feel free to ignore activity on this branch for the time being. Thanks!

[jmtsuji]

@LeeBergstrand I've finalized some initial end-to-end tests via GitHub Actions. For now, I only include tests for the rotate module. Would you mind giving some quick feedback via code review? I'll flag a few key areas in the new code where I'd like additional feedback. Based on your feedback, I can then add end-to-end tests for the repair module in a future PR. Excited to have these initial actions in place. Thanks!

[LeeBergstrand]

@jmtsuji I think many of your tests done in the shell should be replaced by Python unit testing of underlying functions (e.g., rotation). This way, you could embed the sequence (e.g. FASTA sequences) and state information (pass or fail) in the unit testing code rather than having many small files that are very similar. I typically do unit tests using the unittest package (https://docs.python.org/3/library/unittest.html).

Here is an example of some of my code. https://github.com/Micromeda/pygenprop/tree/develop/pygenprop/testing (I would review the structure of these files and note that there is a mix of shell (for end-to-end) and Python unit tests)

Usually, when you do end-to-end testing, it's just a few test cases to ensure that all steps of the pipeline work together. Unit testing ensures the underlying functions work as expected.

[LeeBergstrand]

For example, all of your FASTAs sequences are very similar or identical and could be stored as reused variables if you were using unittest.

[LeeBergstrand]

@jmtsuji A key thing for you to use is setup and tear-down methods before and after testing.

They allow you to set up specific data (e.g., sequences 1, 2, 3) for use during the test. setUp() is run once per unit test, and setUpClass() is run once before the entire test suite. setUpClass should be used for variables that aren't changed by the tests over time, whereas setUp() is used to set up variables for each test, which resets their state.

See this tutorial for details: https://www.freecodecamp.org/news/how-to-write-unit-tests-for-instance-methods-in-python/

[LeeBergstrand]

I would do this work on a separate branch that splits off before you add all the files to the tests/rotate/expected folder. If you add the files and then delete them later, git will still retain a copy of the files.

[LeeBergstrand]

@jmtsuji Here is an example of some of my code that deals with FASTA files and setup methods: https://github.com/Micromeda/pygenprop/blob/develop/pygenprop/testing/test_results_with_matches.py

Note: In your case, some of your FASTA sequences are short enough to be embedded as strings in the test code rather than opened and passed to the tests.

[jmtsuji]

@LeeBergstrand Thanks for the tips. Good to know that end-to-end tests usually just test a couple cases. Also, thanks for sending the micromeda repo as a reference. Now that I have a basic framework for GitHub Actions working, I'll start to build unit tests for individual functions in place of most of the end to end tests. (Will be my first time trying unit tests.) Agreed, I'll start a new branch that avoids the introduction of the input and expected output files to prevent clogging up the git tree. For now, I'll close this PR and open a new one once the modified code is ready.