How do I design unit tests for multiple Perl modules in the same distribution?

Question

I have been developing an internal framework which is designed with bunch of Perl modules. All these modules are dependent on a single module that exposes some Win32 functionality. For e.g. A, B, C, D, etc modules all depend on a single module Z. So all these modules will import by "use MyFramework::Z". All these modules A,B,C etc can be used individually & arenot dependent on any other framework modules.

Now, with that simple design in mind - how do I design my unit tests. I am planning to use Test::More to do all the unit tests. Should I write individual unit tests for each module? There are 25 different modules that belong to this framework. Any suggestions?

Answer 1

Unit tests for Z should cover the Win32 functionality.

Unit tests for A should cover the functionality of A that isn't covered in Z. Repeat for B, C, D, and so on.

If you find that C, E, and G are doing similar things and you are writing nearly identical unit tests, that is the signal to refactor -- extract common components up to a higher level (e.g., module CEG) and just leave and test the special parts of C, E, and G in their original modules.

Answer 2

There are several things you can do:

1. Start writing them! ;)
2. One test per module (as you suggested) and try to test 'only' the code your are testing. (sounds obvious but it's easy to start thinking about interactions with other modules)
3. Check out the modules tests on CPAN for examples
4. Read about BDD and TDD

Answer 3

In general, I'd start with implementing tests for low-level functionality and keep the tests for modules that are designed to be independent of each other in separate files.

If you think that it is important to be able to test your code independent of the Win32 environment, create some module code (specifically for the tests) that emulate the interface of the Win32-specific module. A package statement along with some stripped-down functions may do the trick just fine, depending on what the real module actually does.