Every Perl module needs a test file
Test driven development is a must, that's why I think it is necessary to check that there is at least a test for every module specially if you can't know a priori how much will be populated a namespace, for example if you decide to have plugins .
So here it comes a very nice core module called Module::Pluggable ! For sure ti can help a lot !
Read a short explanation ( more code than words :) in
this article .
I' am an italian mathematician and I like Perl 'cause it helps pay my rent :)
Fibo, Test-Driven Development, or TDD, is the practise of writing tests first and then writing code to fulfill the tests, never writing any code before the related test isn't done already.
While this may be a nice thing in some situations, in most situations it is an unaffordable luxury and in some situations, where the coding happens in an explorative manner, is flat-out impossible because you don't really know how you want your code to behave until you figure out how it can work.
As such TDD can never be an absolute must. Though you may have just meant to say "test-supported development". :)
This comment added nothing constructive. Shame on you.
Clever use of M::P, fibo. I'll have to remember it.
This comment added nothing constructive. Shame on you.
Clever use of M::P, fibo. I'll have to remember it.
Tests are highly compatible with exploratory coding. It may help to think of them as sketches, drafts or samples rather than as the incarnation of a fixed spec. And becoming the first consumer of your own API will help you figure out in a hurry whether, and how, it can work.
Tsk, tsk, Chromatic...
I suppose your book explains which TLAs I should chant while coding.
I'll add one to the second edition. How about:
"If you have nothing constructive or kind to contribute to a discussion, please feel free not to comment."
> becoming the first consumer of your own API will help you figure out in a hurry whether
That is true. I often do this whenever i am in a situation where i can apply working like this.
> Tests are highly compatible with exploratory coding.
Not in all cases though. Example from my work: I have an XML web API (blegh), that is supposed to provide me with data about one-way flights. I have zero documentation or explanation of it however, as the thing is still being built on the other side. That means that i have no idea what individual data points can be extracted from it until i've written the code to request and parse apart the data.
I can apply some testing very early, in the form of regression testing, but TDD is extremely difficult in this situation, as it's basically a case of figuring out which comes first, chicken or egg?