You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's common for modern software packages have built-in testing. Whether this is formal unit tests, or just a naive run-through of some commands with expected outputs isn't so important for now.
But, ideally it should:
Match up with standards that GitHub (for instance) can do to automatically verify. For instance, when one does a Pull request on Github, there's a box that alludes to this.
Be understandable
Be expandable or follow some template, so that more tests could be later.
Use an existing infrastructure (probably matches up with point 1. here). Meaning, use some package. Options here: unittest (looks like it's in "core" Python?) and pytest (which isn't). Should compare these (or get the internet's opinion) before picking one and sticking with it.
To satisfy this issue, just go through 1-5 and make a test that is "satisfied" if one can "import" our package successfully (whatever that means). It should work independent of any specific data set - so the test might be very naive.
The text was updated successfully, but these errors were encountered:
Originally raised by @maminian on 18 Feb. 2022
It's common for modern software packages have built-in testing. Whether this is formal unit tests, or just a naive run-through of some commands with expected outputs isn't so important for now.
But, ideally it should:
unittest
(looks like it's in "core" Python?) andpytest
(which isn't). Should compare these (or get the internet's opinion) before picking one and sticking with it.To satisfy this issue, just go through 1-5 and make a test that is "satisfied" if one can "import" our package successfully (whatever that means). It should work independent of any specific data set - so the test might be very naive.
The text was updated successfully, but these errors were encountered: