One of programming mantras I try to follow is "Bugs are only found once." When a bug is discovered, an automated test is written to demonstrate it. When the test passes, the bug is fixed, and with the test around, subsequent versions of the software will be checked to see if it reappers. I have been more lax than I like with testing my plugins, but I have started to make things right.
A bug in MultiBlog was recently brought to my attention: the file containing a tag that is not used very often did not even compile. It was just a little typo, but it was in software that I had shipped. I really should not have let it out of my subversion repository in that condition.
So, I wrote up a quickie test file and I run it pretty often now. It has already proved itself useful in development.
use Test::More tests => 8;
require_ok ( 'multiblog.pl' );
require_ok ( 'MultiBlog::Tags::Categories' );
require_ok ( 'MultiBlog::Tags::Comments' );
require_ok ( 'MultiBlog::Tags::Entries' );
require_ok ( 'MultiBlog::Tags::Include' );
require_ok ( 'MultiBlog::Tags::LocalBlog' );
require_ok ( 'MultiBlog::Tags::MultiBlog' );
require_ok ( 'MultiBlog::Tags::Pings' );
Using Test::Harness's prove utility (prove -l -I/home/rayners/mt/MT-3.31/lib t/00-require.t), I can make sure that all of the files involved in my plugin compile correctly.
The next step is to start building up some MT testing infrastructure using SQLite and begin testing the actual plugin functionality.
; "Feed Stats Widget")
; "Google Referrer")
; "MediaConsumer Template Output")
; "MediaConsumer List Items")
; "MediaConsumer Edit Item")
; "mt-qotd.png")
; "Vox-qotd.png")
Leave a comment