Positron version 0.1.3 released


The next version of Positron, version 0.1.3, has been released on CPAN.

Yes, I did not announce version 0.1.2, but I'm not going to announce all releases. At this point, a +0.0.1 release is basically a way to let others take part in the progress, and to show that the project is still moving forward.

The changes this release include a wrapping sigil ":", sigils "," and ";" to include / wrap actual DOM fragments from the environment, and sigil "^" to process a part of the DOM tree with a user-defined function. The "," sigil contained quite a difficult choice: should I process the DOM fragment as a template again, or not? The case is clear for the wrapping variant, but the simple inclusion not so much. Solution: not processed. For now.

Test Driven Development

On another note, I'd like to sing the praises of test-driven development again. For this use case, at least. Meaning libraries.

To add a new feature to Positron, say a new templating sigil, I'll first read up on my notes, to recall what it was supposed to do, what options it has, etc. Then I might check the current code and think about how to implement it. But just think. And just out of curiosity.

Because the first thing I do is to write a test. A real unit test file, with several tests inside it. I'll write tests for each variant and option, and for each edge case. In fact, this is usually the first time I really think about those edge cases.

Once the tests are finished, then I run them, and they fail, but at least the file compiles (Ok, sometimes it doesn't. Then I fix that first). Then I start working on the library, until the tests pass (and all others, eventually). And if they don't pass, and I don't know why, I can always run the tests through the Perl debugger – I have an isolated library call right there.

However, this approach does not always work. It works fine for libraries, with a well-defined interface, fixed in- and outputs. It does not work so well, for me at least, for web applications. For web applications, I'll write the code and run it, until it works. And at that point, it already does what it should, so I leave it alone. And if it breaks down the line, that's quickly noticed, and I hack on it until it's better. And if it's not noticed quickly, it can't have been that bad.

So whenever people argue about the test-driven development, I for one keep this in the back of my mind: for some things like libraries, it works very well, and for one-shot code, it's more trouble than it's worth. At least in my experience. But maybe I just haven't practiced enough on one-shot code.