Also related is TDD
because writing a test first forces you to focus on module interface early and from the point of view of the module user.
In your example discussion, module tests that employed a mock DNS server running on a different port would have
caught this specific module interface issue before the module was released.
Not only that, having your own mock DNS server controlled by your tests makes it easier to test module robustness
and recovery (for example, how your module handles timeouts, broken connections, data corruption, ...).
| [reply] |
| [reply] [d/l] |
Yes indeed! An example of having to resort to mind-boggling trickery and deviousness
simply to modify the default value of a module parameter! :) While entertaining, and a challenging problem,
definitely not an example of good module design.
From On Interfaces and APIs, the most relevant point is probably this simple tip for Perl module designers from TheDamian:
- Make common usage the default; allow uncommon usage via optional attributes.
| [reply] |