With my open source work, I've historically taken an approach which relies more on integration testing than unit testing, but with some of my newer projects, I've tried adopting principles from $paidwork and applying them to my free software.
This is a quick run-down of how I'm structuring my test suite in newer projects. It's likely that many of my existing projects will never adopt this structure, but some may.
Let's look at the XSPF playlist format. It's a pretty simple XML-based file format.
<?xml version="1.0" encoding="UTF-8"?> <playlist version="1" xmlns="http://xspf.org/ns/0/"> <title>80's Music</title> <trackList> <track> <title>Take On Me</title> <creator>A-ha</creator> <location>https://example.com/music/01.mp3</location> </track> <track> <title>Tainted Love</title> <creator>Soft Cell</creator> <location>https://example.com/music/02.mp3</location> </track> <track> <title>Livin' on a Prayer</title> <creator>Bon Jovi</creator> <location>https://example.com/music/03.mp3</location> </track> </track> </trackList> </playlist>
The full specification has a lot more details, but for now, we'll just use those elements.
If we are building a Perl application that needs to allow less experienced users to write playlists in Perl, it might be useful to define a domain-specific dialect of Perl for writing playlists.
Consider the following fairly simple class, which creates a lookup object for month names:
package Local::MonthList { use experimental ="color:#333;backgr…This is a variant of SemVer which mostly meets all its rules, except for releases prior to 0.2.0, where we bend them slightly.
It is my intention to use this versioning system for all open source software I develop from 1 January 2023 onwards. Existing open source projects I manage will adopt this scheme from their next release onwards. (Type::Tiny already somewhat does.)
Eagle-eyed watchers of CPAN may have noticed that I've recently been releasing Type::Tiny development releases with version numbers 1.999_XYZ.
Type::Tiny v2 is intended to be compatible with Type::Tiny v1. If you've used Type::Tiny v1, you shouldn't need to change any code, but Type::Tiny v2 has a few new features which may make your code simpler, more maintainable, and more readable if you adopt them.
I'm tobyink on CPAN, IRC and PerlMonks.