Docstrings

[Klankers]

• Initialized pytest (toolbox/tests/, new github workflow) to start addressing Tests #101
• Continued adding docstrings for the API, continuing to address Automated documentation formatting does not match docstrings #59 (previously Logfile support and bugfix #99 )
• Added writeout of qc_history to data product and fixed a bug therein
• Added temporary step, range_test_gross.py, which flags outside of a selected area. Can be registered in range_test.py in the future.
• Ran ruff on contents of the custom/qc/ folder.
• Removed blank QC test from registry, therefore no longer being read in (having no functionality). Comments added to blank_test.py for clarity on future use.

Please let me know if you'd like anything changed or adjusted!

[Obsidian500]

It's a good point on the range test. There are a couple of flaws with it at the moment, the one you've pointed out, but also the fact that you cant assign multiple "bad" regions to the same flag. eg. on a number scale, if I wanted to flag 1-3 and 4-5 as bad, but not 2 I wouldn't be able to do it, because range test only accepts one range per flag. Not ideal...

Thanks for all of the logging updates. I've overlooked that in the V1.0 post (#102) but it should be in the mandatory section.

Could you explain what the new tests are checking for? Ideally I'd like to avoid failing them 😅

[Klankers]

I guess the term "test" carries multiple meanings for this repository.

The pytest workflow is for unit testing. If you aren't familiar, it's helpful for seeing how the code runs when small changes are made. For example, we decide to update from Python 3.14 to 3.15 and discover that a function has been depreciated - it shows up in the unit test as a failure and alerts us that it isn't working as intended.

A good general practice is to have good unit test coverage, easily mapped with something like CodeCov or Coveralls. When the Python pytest or unittest modules are called, they have an output which can be passed along to CodeCov or Coveralls in the github workflow (commented out at the end until we have a definite package name). From there, CodeCov and Coveralls do some magic and are able to map out which lines are being tested for (for example, if we are testing each if-else) which can map out code vulnerabilities. It's a good goal to aim for 100% coverage!

The workflow is currently set up to run with every commit on every branch, so that way we're made aware of issues that happen as soon as possible, but eventually we'll change the branch to main and only push code coverage based on what everyday users can see. Files in the toolbox/tests folder are excluded from those within /src, making it easier to build tests as we go (especially since QC has "test" in the filenames).