Pragmatic Unit testing

Question

I'm writing an application using an MVC framework which takes care of a lot of the boilerplate wiring of our system. Specifically - application is written in Flex, using the Parsley MVC framework. However, the question is not language specific.

In my Presentation Model / Code-Behind / View-Controller (whatever you want to call it), I might have something like this:

[Event(name="attemptLogin",type="com.foo.AttemptLoginEvent")]
[ManagedEvents["attemptLogin"]
public class LoginViewPM {
   public function attemptLogin(username:String,password:String):void
   {
       dispatchEvent(new AttemptLoginEvent(username,password));
   }
 }

Then, elsewhere in my system, code which responds to this, would look like this

public class LoginCommand {
   [MessageHandler]
   public function execute(attemptLoginEvent:AttemptLoginEvent):void {
      // Do login related stuff
   }
}

It's important to note that within Flex / Actionscript, Metatags are not checked by the compiler. For example:

[Event(name="attemptLogin",type="com.foo.AttemptLoginEvent")]
[ManagedEvent["attemptLogin"] // Spelling mistake - metatag is ManagedEvents
public class LoginViewPM {

and

[Event(name="attemptLogin",type="com.foo.AttemptLoginEvent")]
[ManagedEvent["attemtLogin"] // Spelling mistake - event name is wrong
public class LoginViewPM {

In the above two examples, the framework will fail. In the first example it fails silently (because the metatag is incorrect - hence the framework is never engaged). In the second example, we get some runtime logging that partially alerts us that things are wrong.

Given this, what is a pragmatic level of unit testing for the attemptLogin() method on the PM, with regard to the MVC framework's duties? Ie:

Should I:

• Test that the AttemptLoginEvent is managed by the MVC framework
• Test that the LoginCommand gets invoked by the framework when the event is dispatched.

In other container / framework environments, I tend not to write tests that exercise the responsibilities of the frameworks, as (IMHO) this leads to brittle tests. However, given the lack of compiler checking, in this case it may seem warrented.

Thoughts?

Answer 1

If you think about it, you're not really testing the responsibilities of the framework as much as you are testing how well your coders can type.

However, if the same coder who wrote the event also writes the test, and if the event name is something that will not be updated frequently, then you could probably skip it, since any typos would most likely be caught while the test is being written.

Answer 2

What you want to test sounds like integration testing. If you want a unit test, you have to define what your unit is.

If you want to test your eventing, mock the event receiver and find out whether the mock has been called afterwards.

public class MockLoginCommand : ICommandReceiver {

   public bool BeenCalled { get; set; }

   [MessageHandler]
   public function execute(attemptLoginEvent:AttemptLoginEvent):void {
      BeenCalled=true;
   }
}

etc.