Menu
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?
785
A test can exercise methods from three objects and still be a unit test. Some may claim that's integration but three lines of code are just as "integrated" so that's not really a thing. Method and object boundaries don't present any significant barrier to testing.
Every behavior should be covered by a unit test, but every method doesn't need its own unit test. Many developers don't test get and set methods, because a method that does nothing but get or set an attribute value is so simple that it is considered immune to failure.
Unit tests should not affect each other. Unit tests should be deterministic. Unit tests should not depend on any external state.
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.
114
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
