Testing Waffle Applications

Custom Registrars

Waffle provides a built-in test case for verifying that your Custom Registrar (the class extending AbstractRegistrar) can satisfy all dependencies. To utilize this test case extend the abstract class "RegistrarTest". Here is an example of testing the HelloWorldRegistrar:

Yep, that is all the code necessary to test your Custom Registrar.

Controllers

Controllers are extremely easy to test with JMock. Let's write a test to verify the following:

The "save" ActionMethod on a the AutomobileController will save the Car being configured to a Database (via the AutomobileDAO interface).

Preconditions:

- A "Car" exists in the users session

So here is an example of how this could be done. We'll first write a test to ensure that the "save" ActionMethod on AutomobileController does what we expect it to.

So the test is first creating an instance of the Car object for use within the test. A mock is created to stand in for the AutombileDAO. We are expecting that the AutomobileDAO will have it's "save(Car):void" method called one time. A mock is also created for HttpSession. We are expecting the "getAttribute(String):Object" method to be called on the HttpSession mock one time, and when it is called it will return the instance of Car we have previously created. Then we build the AutomobileController satisfying its dependencies with the mocks we have created and execute it's "save():void" method.

Look how great this is, we can test this controller in complete isolation. No dependency on a database in order to test this and no need to actually have a running servlet container. Now it is time to implement the "save():void" method in the AutomobileController to satisfy our test.

Wow, the controller is pretty small and simple. But I feel we can still improve the design. So let's keep going with the Agile approach and refactor this to an even simpler solution. Utilizing the ActionMethod firing support built into Waffle we can change the "save" method to expect a Car instance passed to it, therefor eliminating the dependency on an HttpSession. So we will refactor the test.

The test now only mock the AutomobileDAO exactly as it did before. An HttpSession is no longer needed in the Action. So what changed? We'll have a look at the "save" method on the Controller. It now expects an instance of a "Car" to be passed to it. Running the test will cause the controller to fail, so let's refactor the Controller to satisfy the test.

Now that is a pretty simple controller, and no internal dependency on an HttpSession makes the test simpler too. Another thing to note, prior to the refactoring the AutomobileController needed to be registered to the Session Level context (in the Registrar). However after the refactoring the Action can be registered higher, to the Application Context Level, which will allow it to be shared across the application.

How to test the view?

For in browser testing, take a look at Selenium.

For unit-level testing, you can use the ViewHarness found in the waffle-testing module.