|We don't bite newbies here... much|
Re: What to test in a new moduleby kcott (Archbishop)
|on Jan 29, 2023 at 00:50 UTC||Need Help??|
Obviously, without seeing the module, I can only give generalised information. The following describes how I do testing. It's fairly standard but different authors have their own way of doing things. I also have my own naming conventions: not dissimilar from what many others use (but certainly not universal). I'd suggest looking around CPAN and seeing what others have done.
Firstly, my (skeleton) module directory layout tends to follow this pattern:
Test files are typically split into two groups: those generally run for any installation; and, Author Only tests which are normally skipped for a general make test.
The first is always "00-load.t". It's short, simple, and just tests that "use Some::Module;" works. It uses Test::More::use_ok() and typically looks something like this:
If an object-oriented module, the next test is "01-instantiate.t". The complexity of this script will depend on whether there are any instantiation arguments and, if so, whether they are required or optional. Here's a simple example, paraphrased from a real test script:
Individual methods and functions are tested next. Wherever possible, I put tests for each method or function in their own separate scripts. These follow the same naming conventions; for example, "02-some_method.t", "03-some_function.t", and so on. Here you need to test all possible argument combinations and return values. Consider as many problematic use cases as possible and test that they are all handled correctly; add more tests as other problems are encountered (either from your own work or bug reports from others).
I tend to put all tests in their own anonymous block:
There's a plethora of modules in the "Mock:: namespace". Although I haven't used it myself, Test::Mock::LWP looks like it might be useful for you. I didn't spend any time searching for you; this one just happened to stand out; do have a look around for others.
Author Only Tests
These are really only for you. They generally represent sanity checks of the module code, and ancillary files, in your distribution. They are typically triggered by an environment variable having a TRUE value; and are skipped otherwise.
In the spoiler below, I show three scripts that I've pulled verbatim from a random, personal distribution; these are standard for me (with, potentially, some variation in version numbers). I actually use these with all of my $work modules as well (although, they do have a few more as standard).