Ticket #33 (accepted enhancement)

Opened 07/28/05 17:56:34 (3 years ago)

Last modified 07/22/08 01:18:52 (3 months ago)

Implement regression tests

Reported by: anti Owned by: anti
Priority: normal Milestone:
Component: General Version:
Severity: normal Keywords:
Cc:

Description

Will make it easier to check whether changes in the code break anything. In fact, I already have written a bunch of code and a few unit tests (19 as of now) based on PHPUnit and HTTP_Client from Pear.

There are still some minor kinks to iron out and then I'll make the code public.

Of course, that code should never be redistributed with Plogger, it's ment for developers to make their life easier.

Change History

Changed 07/28/05 17:56:46 (3 years ago) by anti

  • status changed from new to assigned

Changed 05/15/06 05:41:14 (2 years ago) by stefan

FYI.

I've added a "unittests" directory to the root directory in the plogger-with-tags branch. There I'm using PHPUnit from PEAR.

The way I did this was to add the following structure:

+-plogger-root/

+-unittests/

+-lib/ | +-(here's the PHPUnit lib) +-tag-tests.php +-(more test related php files)

I figured that this would probably be the easiest way to exclude the unittests completely from being distributed (which can be dangerous because proper unittests will mess with your database).

I was also wondering whether it might be a good idea to make some sort of a build script to create a distribution package? This script could be a Makefile or it could use Ant (a Java build system) or some derivative of that (I think there's a Python version of that somewhere). What this script could then do would be something like the following:

  • Check out a specified revision of plogger from SVN.
  • Create a zip file excluding all the unittests and buildscripts. The zip file could be named something like plogger-1.0.zip where the 1.0 would be a string supplied to the buildscript similar to the SVN revision that needs to be checked out. The build script could even put this string in a file which it would include in the zip file and Plogger could use that file to display version information.
  • Copy the zip file to whereever it needs to be copied to make it available.
  • Create a tag in SVN with the specified version number, something like tags/plogger-1.0.
  • Create a branch in SVN to make development of bugfixes to that version easier. Something like branches/plogger-1.0.x.

This might of course be overkill for such a simple project but at least we might want to think about doing these things manually when we issue a new release of plogger.

Changed 05/15/06 05:42:56 (2 years ago) by stefan

Forgot to put my directory structure in a code block so the formatting got screwed up.

It's easier to just take a look at the plogger-with-tags branch: http://dev.plogger.org/browser/branches/plogger-with-tags/unittests/

Changed 07/22/08 01:18:52 (3 months ago) by sidtheduck

I have no idea where this code is or if it's fully functional. Could be a useful tool for development though.

Note: See TracTickets for help on using tickets.