Argh!  I just spent the last hour trying to figure out why I can't configure a Mule UMO (mule-descriptor) using Spring.  I ran into a couple of issues, firstly if you specify a container-context for your bean the life cycle interfaces (like Startable) are ignored.  Next I tried using a mixed Mule-Spring config file, putting the property injection declarations directly in the mule XML file, but I kept getting the following SAX error:

The content of element type "mule-descriptor" must match "(inbound-router?,outbound-router?,response-router?,interceptor*,threading-profile?, pooling-profile?,queue-profile?,exception-strategy?,properties?,bean*)".

Not being that familair with DTDs, what I didn't realize is that the comma between element declarations (as in the error message) means that the sub elements must be declared in the XML file in that order.

Big, fat, DOH!

A conversation in a not so distant universe...

Golly, why would anyone follow the Law of Demeter and produce an orthogonal system design?  There's a reason I can call select * from table directly from my aspx page.  It's far less code and my wizard completely supports it.  TDD just slows you down, and is only for developers who write a lot of buggy code; so much code they need a computer to test their app.

What do you mean the 3rd party database has changed to a new schema that now uses a web service?  We'll luckily I can crank out an entirely new application using my wizards in a month or two, we'll just have to line of some resources to test it after I deploy it to production.

WatiN

Inspired by Watir development of WatiN started in December 2005 to make a similar kind of Web Application Testing possible for the .Net languages. Since then WatiN has grown into an easy to use, feature rich and stable framework. WatiN is developed in C# and aims to bring you an easy way to automate tests with Internet Explorer. Following is the Hello world example of web testing automation; searching Google with WatiN.

I'm currently in the middle of refactoring all of my test code.  I've decided to split my test folder into two subfolders, unit and integration.

\src\test\java\integration
\src\test\java\unit

I have a lot of long running integration tests that need to be separated from my unit tests.  My were getting slow and difficult to manage, so hopefully JUnit will be able to fly through my newly organized unit tests.