Introduction

Testing an Ext JS application normally requires a deep dependency chain, which will include both application classes and the framework itself. Other than being difficult to set up, the resulting context is closer to
integration testing, where the interconnected glue of an application and the framework are tested rather than its individual parts.

Ext Spec frees you to focus on your own functions by providing a mock implementation of Ext.define. This captures Ext JS class definitions and allows them to be reconstituted in a test suite, either in their original form or as basic instances. From there,
everything else can be faked. All application and framework dependencies are removed other than Ext Spec and the class under test.

Getting Started

If you want to skip the reading and just see how Ext Spec can help you unit test your Ext JS application,
download the latest example release. It contains an Ext JS MVC application straight from Sencha's samples with full unit test coverage using Ext Spec.

Ext Spec 2.0.0 Released

This version switches Jasmine support from 1.x to 2.0, and as such is a breaking change. Obsolete matchers have been removed.

Ext Spec 1.3.0

Version 1.3.0 introduces an optional argument to ExtSpec.create. If supplied, this function will be run against the instance before the constructor is fired, allowing spies and other dependencies to be injected. The
this context of the function will be the new instance. For example:

Minor updates in this version include better support for
statics and inheritableStatics and the automatic addition of a
self property.

The example distribution now ships with Ext JS 4.2.0, and the codebase has been upgraded to TypeScript 0.9.0.

Ext Spec 1.2.0

Version 1.2.0 focuses primarily on improving and expanding Ext Spec's suite of Jasmine matchers and helpers.

Firstly, all of the existing MVCS methods now support Ext JS "short" aliases using the @ character. For example, if a controller contains a model "ShortName@sub.namespace", toHaveModel("ShortName") will pass, and createModelSpy("ShortName")
will successfully create a spy.

New event listening spy matchers have been created to take the place of the existing ones, which have always been a bit awkward and overly fragile. These new matchers do a better job of conforming to standard Jasmine behavior and have clear descriptive
names. The old methods have been marked as obsolete (via a console warning) and will be removed in a future major version. See the complete list on the updated
Event Listening Matchers page.

Rounding out the update, there are also few new general purpose matchers and helpers:

toHaveConfig - Used to confirm that an Ext JS class has a particular "config" property.

toHaveBeenCalledWithConfig matcher - Useful for spying on methods that use Ext-like config arguments.

createFluentSpyObject - Helps create spies for objects that support method chaining, such as Ext.dom.Element. Each spy is pre-configured to return the base object. The "fluent" action can also be used with the existing helpers using configuration.

Ext Spec 1.1.0

Now that Visual Studio has JSDoc enriched intellisense for both TypeScript and JavaScript (thanks to
Web Essentials), the VSDoc distribution has been retired. There is now just one version of Ext Spec and it contains JSDoc style annotation.

From a source code perspective, the entire toolset has been translated to TypeScript. Don't worry, the public interface for Ext Spec is completely unchanged. TypeScript just simplifies the build process and makes the code base more maintainable.

Finally, from this version forward, Ext Spec will observe
Semantic Versioning. Short story: Breaking changes will require a major version change; new features will require a minor version; fixes and revisions will increment the patch version.