Would you be writing tests for a single purpose module?

Dear Bod, we've discussed this topic before, on April 1 2021 - where my answer was not intended as an April Fools' joke. In summary:

You should write your tests before you write your module - or while you are developing it

my answer was not intended as an April Fools' joke

I didn't think it was :P

As this module is not much more than a wrapper around Template and really cannot be used anywhere other than within the website that it is written for - really...it cannot - I didn't think tests would be needed because there is no end user as such.

Time to revisit that thought...

"... really cannot be used anywhere other than within the website that it is written for - really...it cannot ..."

Unfortunately, what happens all too often, is a sequence like this:

1. You write something specifically for "A" (whatever that might be). The code is peppered with hard-coded "A"s throughout.
2. At some later point you have a similar requirement for "B". You take a copy of the first code and replace all of the "A"s with "B"s. You add some enhancements to this version of the code.
3. Further down the track, you have another similar requirement, this time for "C". You take a copy of the first code and replace all of the "A"s with "C"s. However, you notice that the enhancements which you added for the "B" code are not in the "C" code. You attempt to retrofit those enhancements but encounter problems. You scrap your new "C" code, take a copy of the "B" code and replace all of the "B"s with "C"s.
4. And then something generic changes; it could be something minor like certain URLs with an http scheme now need an https scheme. You now sit down with your editor and modify the "A" code, then the "B" code, then the "C" code.
5. Later you realise that the "A" code needs the enhancements that were originally added to the "B" code. You sit down again with your editor and ...

I hope you can see where this is going. There is no such thing as "will only be used by" or "final version" or anything else absolute like that. Every time you copy and substitute, or attempt to make identical changes in multiple files, you run the risk of introducing typos, subtle errors, and the like; the more you do this, these risks go from minimal chance to almost guaranteed. Furthermore, look at the huge rod you're making for your back with all of this extra work (that could've been avoided).

The A/B/C scenario I provided is, of course, a purely hypothetical example; however, it does mirror the type of thing that I've encountered on numerous occasions in over four decades of software development. Here's some examples.

• One company had hundreds of scripts, whose core functionality was roughly equivalent, but each had hard-coded values, and were all subtly different from each other (including unprofessional-looking typos and bugs in rarely called routines that had never been tested).
• Another employed the practice of copying entire modular frameworks and changing hard-coded values. My protestations fell on deaf ears. Then it blew up in their faces when an update, to a client in the Philippines, displayed text in a variety of languages including Vietnamese and Urdu.
• A third, and classic, example is from over 20 years ago. The company had a number corporate clients for whom they managed hundreds of static HTML pages. Whenever a new page was required, they just copied some random existing page, then changed the title and replaced the old main content with new. All of these pages were littered with <font> tags. I urged them to strip out the <font> tags and start using CSS: this was greeted with howls of "if it ain't broke, don't fix it" and such like. Then one of their clients changed one of their corporate colours to a slightly different shade: more than 3,000 edits to <font> tags later, CSS was back on the table.

Never assume your code will only ever be used by one entity. Always abstract your code such that it can be reused. Avoid hard-coded values like the plague.

Some of this might seem like additional work; however, once you get into the habit of doing it, you should find that it takes little or no extra effort. Moreover, as your software matures, the benfits accrue and you'll avoid the types of problems that I've indicated above.

You've been here for less than a year with a clear appetite for learning and improvement — this is great. You've taken onboard templates, placeholders, and so on; I hope you pick up on the ideas I've presented here too.

— Ken

I never wrote a test case for anyone else than me, though others might benefit from it.

Greetings,
-jo

$gryYup$d0ylprbpriprrYpkJl2xyl~rzg??P~5lp2hyl0p$

Would you be writing tests for a single purpose module? In other words, a module that only ever gets used with the same 3 related scripts.

Yes, with 100% certainty I would.

Besides, "only ever gets used with" are famous last words.

I write tests for every single module I create. That includes personal and $work modules. And the first one is always 00-load.t.

Writing tests is extremely important — I can't stress this strongly enough.

Run 'make test' every time you change Module.pm; that provides a regression test. Now write one or more new tests that address whatever changes you made. If you're only changing a test, or want more specific feedback from a test, use 'prove -vb t/whatever.t'.

It might seem like extra work but, in the long run, it will save you much time and frustration. If you use something like Module::Starter, some tests will be automatically written for you; you can write generic test templates which you copy to 't/' and then just do a global substitution, e.g. s/___MODULE_NAME___/Module::Name/g; you can write boilerplate tests which you can just copy and leave as is (see 't/99-02_manifest.t' in "Re: Perl tools for making code better" for an example — that's the first block of code; the filename is mentioned further down).

I absolutely concur with ++stevieb's "famous last words" comment.