Docs Help

Terms, Icons, and Labels

Many classes have shortcut names used when creating (instantiating) a class with a configuration object. The shortcut name is referred to as an alias (or xtype if the class extends Ext.Component). The alias/xtype is listed next to the class name of applicable classes for quick reference.

Access Levels

Framework classes or their members may be specified as private or protected. Else, the class / member is public. Public, protected, and private are access descriptors used to convey how and when the class or class member should be used.

Member Types

Member Syntax

Below is an example class member that we can disect to show the syntax of a class member (the lookupComponent method as viewed from the Ext.button.Button class in this case).

lookupComponent ( item ) : Ext.Component
protected

Called when a raw config object is added to this container either during initialization of the items config, or when new items are added), or {@link #insert inserted.

This method converts the passed object into an instanced child component.

This may be overridden in subclasses when special processing needs to be applied to child creation.

Parameters

item :  Object

The config object being added.

Returns
Ext.Component

The component to be added.

Let's look at each part of the member row:

Member Flags

The API documentation uses a number of flags to further commnicate the class member's function and intent. The label may be represented by a text label, an abbreviation, or an icon.

Class Icons

- Indicates a framework class

- A singleton framework class. *See the singleton flag for more information

- A component-type framework class (any class within the Ext JS framework that extends Ext.Component)

- Indicates that the class, member, or guide is new in the currently viewed version

Member Icons

- Indicates a class member of type config

- Indicates a class member of type property

- Indicates a class member of type method

- Indicates a class member of type event

- Indicates a class member of type theme variable

- Indicates a class member of type theme mixin

- Indicates that the class, member, or guide is new in the currently viewed version

Class Member Quick-Nav Menu

Just below the class name on an API doc page is a row of buttons corresponding to the types of members owned by the current class. Each button shows a count of members by type (this count is updated as filters are applied). Clicking the button will navigate you to that member section. Hovering over the member-type button will reveal a popup menu of all members of that type for quick navigation.

Getter and Setter Methods

Getting and setter methods that correlate to a class config option will show up in the methods section as well as in the configs section of both the API doc and the member-type menus just beneath the config they work with. The getter and setter method documentation will be found in the config row for easy reference.

History Bar

Your page history is kept in localstorage and displayed (using the available real estate) just below the top title bar. By default, the only search results shown are the pages matching the product / version you're currently viewing. You can expand what is displayed by clicking on the button on the right-hand side of the history bar and choosing the "All" radio option. This will show all recent pages in the history bar for all products / versions.

Within the history config menu you will also see a listing of your recent page visits. The results are filtered by the "Current Product / Version" and "All" radio options. Clicking on the button will clear the history bar as well as the history kept in local storage.

If "All" is selected in the history config menu the checkbox option for "Show product details in the history bar" will be enabled. When checked, the product/version for each historic page will show alongside the page name in the history bar. Hovering the cursor over the page names in the history bar will also show the product/version as a tooltip.

Search and Filters

Both API docs and guides can be searched for using the search field at the top of the page.

On API doc pages there is also a filter input field that filters the member rows using the filter string. In addition to filtering by string you can filter the class members by access level, inheritance, and read only. This is done using the checkboxes at the top of the page.

The checkbox at the bottom of the API class navigation tree filters the class list to include or exclude private classes.

Clicking on an empty search field will show your last 10 searches for quick navigation.

API Doc Class Metadata

Each API doc page (with the exception of Javascript primitives pages) has a menu view of metadata relating to that class. This metadata view will have one or more of the following:

Expanding and Collapsing Examples and Class Members

Runnable examples (Fiddles) are expanded on a page by default. You can collapse and expand example code blocks individually using the arrow on the top-left of the code block. You can also toggle the collapse state of all examples using the toggle button on the top-right of the page. The toggle-all state will be remembered between page loads.

Class members are collapsed on a page by default. You can expand and collapse members using the arrow icon on the left of the member row or globally using the expand / collapse all toggle button top-right.

Desktop -vs- Mobile View

Viewing the docs on narrower screens or browsers will result in a view optimized for a smaller form factor. The primary differences between the desktop and "mobile" view are:

Viewing the Class Source

The class source can be viewed by clicking on the class name at the top of an API doc page. The source for class members can be viewed by clicking on the "view source" link on the right-hand side of the member row.

Sencha Test 2.2.1


top

Projects, Scenarios, and Suites

Sencha Studio enables you to author test scripts to repeatedly test your applications in a structured and predictable way. This level of testing helps to ensure stability as your application grows and matures. Before you create the individual tests, you will first need to setup your workspace and initialize a Test Project.

Within each workspace/project, you will have a Tests node under the following groupings:

  • The workspace root itself
  • Each application in the workspace
  • Each package in the workspace

Sencha Studio Workspace View

Test Projects are part of the test suite hierarchy in Sencha Studio. They allow you to manage the scope of tests by way of a workspace. Tests within the root workspace’s Test Project may be applied to code that is shared across any application or package within the workspace. Tests in the Test Project of an application or package will be run against the code in their respective parents.

Test Projects

Initialize a Test Project

Once you are within a workspace, application, or package, you will see a “Tests” node under the parent folder. When the Tests node is selected for the first time, Sencha Studio will display the Test Project creation screen. Click “Initialize Test Project” to create the test project file (test/project.json by default, though you can specify another directory within the workspace if necessary). Sencha Studio will create the Test Project and present the Test Project details view.

Sencha Studio Init Test Project

Location (URL)

Test Projects located in the workspace root level or within a package will require you to enter the "index.html" target file in the Project Settings "Location (URL)" field. This target file is the one spun up at the time tests are run. Projects located within an application will use the application’s generated “index.html” file (unless explicitly overridden). The URL provided should start with a valid protocol (http or https).

Sencha Studio Project URL

Test Frameworks

Sencha Studio contains the latest version of Jasmine by default. Check out the excellent Jasmine documentation for more information on authoring and editing Jasmine tests.

Sencha Studio Project Test Framework

Documentation for writing adapters using other test frameworks will be detailed in a future guide as well.

Additional Libraries

Additional JavaScript files may be included in the test runs in a Test Project by specifying the path for each file in the Additional Libraries section of the Test Project. These files will often be external libraries such as mapping clients, data mocking utilities, and other supporting scripts that could be used when running tests. The path of each file will append to the workspace directory; i.e. setting a file path of “shared/UserData.js” will result in the test runner loading “[workspaceDirectory]/shared/UserData.js” at test time. All additional library files will be loaded prior to the running of the tests specs.

Sencha Studio Project Additional Libraries

Test Projects and Scenarios

A Test Project must contain at least one “Scenario” to be of any use. Test Projects contain one or more Scenarios that serve to organize groupings of unit tests within a Test Project. The Test Project contains common configuration items that will be inherited by all of its Scenarios. Scenarios contain the information needed to define a complete collection of tests, including the location of test scripts, the URL of the test subject, etc.

Adding a Scenario

You can add Scenarios by clicking the “New Scenario” button on the project toolbar. Give the Scenario a name that describes what the tests will manage, and choose the scenario type. If you have the Test Engineer persona selected, by default all added scenarios will be WebDriver scenarios. Developers have the option to choose between In-Browser and WebDriver.

Sencha Studio Project Add Scenario

The Scenario directory should be left as its default value unless you are avoiding a directory conflict in which case you may point to another directory within the Test Project's configured directory.

After saving, the Scenario will appear in the workspace navigation tree under its parent Test Project.

Scenario Location (URL)

The Location (URL) field in the Scenario details allows you to:

  1. Override the URL set in the parent Test Project’s details by supplying a URL (starting with “http” or “https”
  2. Append a hash or query to the Test Project’s URL (by including a string starting with a “#”, “?”, or a some combination)

Scenario Additional Libraries

Scenarios may have supporting JavaScript files specified in addition to those set in the Test Project. Scenarios inherit the additional JavaScript libraries specified in the Test Project which are loaded before any additional libraries defined by the Scenario.

Creating Jasmine Test Suites

You can create and edit tests directly in Sencha Studio or via your favorite IDE/text editor. The tests will be located within the sub-folder indicated in the "Directory" field on the Scenario details view. You can navigate to said view by clicking on a Scenario in the Tests tab.

To create a new test in Sencha Studio, use the context menu on the target Scenario in the Workspace navigation tree, or click the "New Test Suite" button on the top toolbar.

Sencha Studio Add Test Suite

The test suites can then be opened for edit by expanding the parent Scenario node and selecting the test suite node.

Sencha Studio Select Test Suite

Suites can be directly modified within Sencha Studio’s editor. User-authored tests can be run against internal logic within an application or by simulating events on an application UI. You can also use the Event Recorder functionality to author user interactions directly, which allows you to record live interactions within a browser. These recorded events can then be repeated at test run time.

A suite follows the following convention:

describe("A suite", function() {

});

The first param in describe should be a plain English explanation of what the Suite aims to test. Our actual tests will go inside of the describe function.

Creating Jasmine Test Specs

Once a suite has been added, the actual tests themselves can be created and added to the suite's describe function. In Jasmine terms, an individual test is known as a spec. A spec is a JavaScript function that explains what a portion of your program should accomplish. Specs should explain in plain language what the test is aiming to prove. It should then provide JavaScript that performs the tests for said expectation.

it("contains spec with an expectation", function() {
    expect(true).toBe(true);
});

So the suite and spec together appear as follows:

describe("A suite", function() {

    it("contains spec with an expectation", function() {
        expect(true).toBe(true);
    });

});

You can then add as many specs to your suite as you'd like. It's ideal to keep your suites organized by what they aim to test. Often, this organization will follow your application's organization.

For more information about the Jasmine test framework, be sure to check out their suite documentation.

Conclusion

Now that you have your test environment established you'll want to start authoring tests against your code. For a complete example refer to the Testing your Application with Sencha Studio walkthrough guide.

If you have further questions, concerns, or bug reports, please visit the Sencha Test forums

Sencha Test 2.2.1