The component-based approach of T3 makes it easy to write better tests for your application. Since each component is registered separately and uses dependency injection to access other objects, you can easily stub or mock out dependencies.
The T3 testing bundle is a small utility you include before your own T3 code. It stubs out
Box.Application and provides methods to access modules, service, and behavior objects directly. This way, you can directly interact with object for testing purposes.
t3-testing.js file is located in the
/dist directory. Depending on how you’ve installed T3, you may access this file in a few different ways:
Note: Make sure you do not include the regular
t3.js file in your tests.
Since services get used quite frequently in T3, the testing bundle has a special
Box.TestServiceProvider type that is used to easily wire up an object with a
getService() method that responds with appropriate objects. When you create a new instance of
Box.TestServiceProvider, you pass in an object with key-value pairs corresponding to the service name and an object to return when that service name is requested. Here’s an example:
This code sets up a fake
context object for a test by using a
Box.TestServiceProvider that is wired up to return two services:
service2. Each of these names are tied to fake service objects that should be returned when
getService() is called. In this way, you can quickly write up service dependencies for your tests.
Occasionally, you will need to use an actual service instead of a stub. A DOM manipulation service is a great example of a utility that is hard to stub/fake short of just re-implementing the functionality in the test.
Box.TestServiceProvider will include any services that are registered to the application stub before the
Box.TestServiceProvider is instantiated, provided that you specify the services in the 2nd param,
allowedServicesList of a TestServiceProvider. For example:
Note: The component being tested will use the real service. That does not prevent you from stubbing or mocking methods as normal.
The T3 testing bundle stubs out
Box.Application so you can focus on testing just your components in an isolated environment. This stub contains the
addBehavior() methods that are used to register components, so your components are never aware they aren’t running with the real
Additionally, there are three methods on the
Box.Application stub that allow you to get access to T3 components:
getModuleForTest(moduleName, contextFake)- returns the module object for the given module name and passes
contextobject to the module’s creator function.
getServiceForTest(serviceName, applicationFake)- returns the service object for the given module name and passes
applicationobject to the service’s creator function.
getBehaviorForTest(behaviorName, contextFake)- returns the behavior object for the given behavior name and passes
contextobject to the behavior’s creator function.
Each of these methods allow you to inject an object in place of the
application object that is typically passed to the component’s creator function. This allows you to substitute in a
Box.TestServiceProvider, or any other object, to aid in testing. For example:
getBehaviorForTest() should only be called once for each unit test and should be used only to retrieve the component you are testing.