unit testing with wire js?

[Brendan Miller]

Are there any examples of how to do unit testing with require js?

The cujo main page had a really simple example, but it didn't show how to inject mock dependencies in the test.

What I want to see is, an application where the dependencies are wired up one way, but in my unit test I have mock dependencies that are different from the normal application flow. Skimming through the wire.js docs it's not obvious to me how to have mock dependencies in the unit tests...

Thanks,

Brendan

[Brian Cavalier]

Hey Brendan,

Since javascript objects are easy to set properties on, components written in a dependency inversion style are typically pretty easy to unit test without any extra tools, and even without using wire at all.  I just pushed an update to the contacts sample app that includes a unit test for its controller.  Here's the controller, and here's the test.  Granted both are simple, but I think it illustrates the idea.  All the test has to do is inject a spy, call a public method on the controller, and then verify that the public method delegated correctly to the spy.

There are other unit tests in the contacts sample, and you'll see similar things there.  Since they all have few or no dependencies, they are very easy to test, which is quite typical of a cujoJS app: small components, with few or no dependencies, which are easy to unit test, composed together declaratively in one or more wire specs.

Does that help?

Looking beyond unit testing, say to functional or composition testing, where you want to test groups of components or sections of an application, there are a few options.  If you've used a tool like Selenium or some other functional web test driver, you can certainly continue to do that level of testing with a cujoJS app, and we encourage it.

We've done some work on testing coarse grained components (those made up of, say, a group of smaller, unit-testable components), and there is an example of how you might do this in the Monty Hall demo app.  See the ui testing harness here.  That approach works well for testing visual components, as well, without having to run the entire application--great for getting your design team integrated into the process.

Right now, wire itself doesn't provide any sort of auto-mocking or other type of testing help, as some other IOC envs, like Spring provide.  We're definitely interested in exploring that space, though.  There are a few options right now:

Wire 0.10 allows you to override components when you call the wire function, or use the AMD plugin by supplying "mixin" specs.  For example:

wire([mainSpec, overridesSpec]).then(function(context) { ... });

In that case, components in overridesSpec with the same names as those in mainSpec will take precedence.  Or similarly when using wire as an AMD plugin:

curl(['wire!mainSpec,overridesSpec'], function(context) { ... });

Where mainSpec and overridesSpec are (obviously!) module ids in this case.  That'll have the same effect.  This kind of overriding approach works pretty well, and will likely be the basis of a more automated composition testing approach in the future.

Of course, you can manually wire in different implementations of a component.  In the Monty Hall app, we built 2 game APIs, a real one and a fake one.  You uncomment which server API implementation you want to run with.  Not a great solution, obviously, but shows that it is possible.

Hope that gives you some ideas!