Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^3: [RFC] Review of module code and POD (TDD)

by eyepopslikeamosquito (Archbishop)
on Apr 01, 2021 at 01:09 UTC ( [id://11130654]=note: print w/replies, xml ) Need Help??


in reply to Re^2: [RFC] Review of module code and POD
in thread [RFC] Review of module code and POD

Is it worth also trying to write tests for this - again for practice and learning - if so, where would I start?
Before you write the module. :)

The main point of TDD is that writing the tests first (or at least early) affects and improves the design of the module! Writing a test first forces you to focus on interface - from the point of view of the user. Hard to test code is often hard to use. Simpler interfaces are easier to test. Functions that are encapsulated and easy to test are easy to reuse. Components that are easy to mock are usually more flexible/extensible. Testing components in isolation ensures they can be understood in isolation and promotes low coupling/high cohesion. Implementing only what is required to pass your tests helps prevent over-engineering.

To give a clearer picture of where I'm coming from, a quote from Ten Essential Development Practices:

The most important aspect of any module is not how it implements the facilities it provides, but the way in which it provides those facilities in the first place. If the module’s API is too awkward, or too complex, or too extensive, or too fragmented, or even just poorly named, developers will avoid using it. They’ll write their own code instead. In that way, a poorly designed module can actually reduce the overall maintainability of a system.

Designing module interfaces requires both experience and creativity. Perhaps the easiest way to work out how an interface should work is to “play test” it: to write examples of code that will use the module before implementing the module itself. These examples will not be wasted when the design is complete. You can usually recycle them into demos, documentation examples, or the core of a test suite.

The key, however, is to write that code as if the module were already available, and write it the way you’d most like the module to work.

Once you have some idea of the interface you want to create, convert your “play tests” into actual tests. Then it’s just a Simple Matter Of Programming to make the module work the way that the code examples and the tests want it to.

See also: Re: Winning people over to better development practises (TDD) and On Interfaces and APIs

  • Comment on Re^3: [RFC] Review of module code and POD (TDD)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11130654]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2024-04-23 22:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found