James Mead in Hellish XML:
So now you can write test cases for ANT in XML using AntUnit.
You can even write assertions in XML ...
<!-- the actual test case -->
<target name="testTouchCreatesFile">
<au:assertFileDoesntExist file="${foo}"/>
<touch file="${foo}"/>
<au:assertFileExists file="${foo}"/>
</target>
... but why?
The short answer is: Because it is the best way to test Ant tasks.
To answer this in more detail I need to put AntUnit into context a little bit.
Despite its name AntUnit is more about functional and integration testing than unit testing. Nobody suggests you should write unit tests for your Java (or Ruby) project in Ant instead of the testing framework that fits your language or problem domain. In fact Ant will certainly stick with JUnit 3.x for "real" unit tests of its internals.
AntUnit's main purpose was and is testing Ant tasks. As such it is quite natural to express the tests using a language familiar to Ant developers and users - as Ant build files.
Ant's own tests started out as a collection of ad-hoc JUnit tests
in the early days of JUnit 3.x and Ant 1.1 sometime during the summer
of 2000. Pretty soon an Ant domain specific JUnit extension was born,
BuildFileTest
which contains some logic for setting up Ant Project
instances from test build files and a few Ant specific assertion
methods.
Over time many tests degraded to stuff like
public void testSomeSpecificProperty() {
executeTarget("someSpecificProperty");
}
and the actual assertions were performed using <fail> tasks inside of the build file. JUnit wasn't used as a Java testing framework but as a driver for Ant.
We could do better than that, AntUnit was born. Ad-hoc <macrodef>s using <fail> are now replaced by a standard set of assertion tasks and a new task acts as a driver for tests - no reason to abuse JUnit any longer.
There also is an important side effect of using AntUnit as Ant's testing framework: it has become absolutely straight forward to turn a bug report into a test. If a user reports a bug all we need now is a sample build file snippet that exhibits the bug. Glue an assertion at the end and you are done.
path: /en/Apache/Ant/AntUnit | #
If you read this the DNS changes for samaflost.de have reached you. The websites and mail are more or less running smoothly by now. Finally.
I decided to not use Plesk at all but rely on myself and a couple of FAQs to do all the configuration stuff. This is all under the assumption that Plesk will leave config files alone as long as it doesn't think it should change one, and I don't intend to make it change them.
After I figured out how to get my procmail recipes into qmail - thank God for Dave Sill's Life with qmail - the biggest missing piece now is integrating Spamassassin and qmail.
The whole migration has eaten up about a week of spare time devoted to hacking by now, time to get back to "normal" life.
path: /en/personal/hosting | #
My current hosting provider is going out of business so I'm moving on. The new server is already up and running but as long as the domain transfer is underway I'm unable to properly configure web and mail for it.
When I installed the old server it was running a web-based admin-software named Confixx that was standing in my way more often than not. It took me a few months to get rid of it completely. The new machine is running what seems to be its predecessor in spirit, an AJAXy web-app named Plesk and I've already started to hate it. I'm seriously contemplating to remove it from the system, but this will probably not work without jumping through some hoops.
Anyway, Plesk is interfering with my manual configuration and I can't configure virtual web hosts or mail servers before the domain is transfered. This probably means the website will be down (not that anybody would notice) and the samaflost.de mail domain dysfunctional (not that anybody used it much) for a few hours if not days in the near future.
path: /en/personal/hosting | #