I kind of wish someone will join in, and say why they like and don't like '.t' files and coverage tools, to make it more "spicy" and understand why so many people use these.

I wish that too.

You may read any of many reasons for the lack of such responses here. Here are a couple of possibilities:

• I could be such a kook, that I'm not worth arguing with.
• I could be so good at arguing my case, no one is prepared to subject their prejudices, dogmas and half-baked reasoning to the cold, hard logic of my scrutiny.

You'll have to arrive at your own judgement on that.

What do you think ?

I think that you could pose a new question here, something like: "Do you use separate .t files for your tests? If so, why?". If you don't mention this thread or my handle, you might get more responses. I'd stay out of the thread at least until you invited my reaction there.

In the end, you'd have to try it both ways and live with the packages through a few maintenance cycles -- preferably carefully logging your experiences -- to reach some kind of definitive conclusions.

Even then they would be your conclusions and other would interpret the results differently. I've often see practices adopted by people because they are the done thing; or the latest greatest fad; that then become entrenched habits they will defend without needing rationality.

Indeed, I've done it myself in the past. It took a particular project where my way of working was closely monitored and questioned in fine detail by a third party -- it was used to form the basis of a set of working practices and guidelines for a whole huge project -- to make me question some of them in detail.

I'll speak up and say thank you for offering an alternative to the generally accepted push toward heavy use of git and testing. That 14-step process (and that's brief?) sounds like it would work great for collaborative projects, but for a one-man operation like mine, I look at it and wonder when I'd get any coding done.

On the other hand, I would like to use more testing and version control. My programming background is of the "hack it together until it works" variety, so my steps tend to look like this:

• 10 Edit script
• 20 Run script
• 30 If errors, goto 10
• 40 Publish script, send invoice

(If I used git on most of my projects, I have a feeling they would get checked in once, like this: `git commit -a -m 'done'`) Most of the time, that works fine. If there's an error, it's probably near the lines I was editing, so I don't need an IDE to take me to the location of the error. If I'm using Emacs and running the script in an xterm (or web browser), my editor is still where I was; if I'm using vi, it takes me back to my previous location when I open the file again. Perl's error messages are clear enough to get me to the exact spot from there.

Some version control would be nice. In 15 years of programming, there have only been a handful of times that I wanted to go back farther than the current editing session (which my editor could 'undo'). But on those occasions, it would have been very handy, so if I could automate that, it'd be nice. I probably could with Emacs, and I know I could with a simple script that would watch my 'work' directory and check anything that changed into git/svn/cvs/rcs, but I guess I haven't wanted that enough to bother yet.

Another appealing aspect of the 14-step process is that it provides a certain amount of a paper trail and documentation. Quick hack scripts and troubleshooting sessions generally aren't heavy on documentation, if they have any at all, so it'd be nice to have some kind of running commentary to check back on later. It would also supply a timeline of time spent on the task. But again, if I were inclined to write better documentation and keep tighter timelines, I could already do so by adding it right in the script or a separate doc file.

So I like your idea of testing and version control as an automated background process; that would make me a better programmer without annoying me into avoiding it. I think much of that can be done with Emacs, but I haven't studied it enough to know if it can be made unobtrusive enough.

Aaron B.
My Woefully Neglected Blog, where I occasionally mention Perl.

I would like to use more testing

I do test. Just not with the Test::* tools.

It is my contention that when writing a module, you should write the application (or at least an application) that uses that module, concurrently with the development of the module itself. This improves the module design by ensuring that its interface works with the needs of the application. That it has the entry points the application needs, and no more. The application becomes the prototypical test-bed for the module.

Far too many modules are developed in isolation of their use case, designed on the basis of what-if and maybe and it-could-do, hence you end up with clumsy, fragile, bloated, and over-specified interface definitions

Once the module is written and working with the application, then is the time to go back and see if it can be generalised to some degree, without breaking the original use case. At that point I write a generic application -- a cut-down and simplified version of the original use case -- that self-checks its own results and serves as test case and regression test, and lives in the module file itself. It can then be annotated and also serves as user documentation for the module.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?