Introduction

Simone comes with tests. If you're unfamiliar with the concept of software testing, this Wikipedia article is a good introduction.

Over 1400 tests are currently written, around 240 of them being tests inherited from jQuery UI Dialog widget, a widget that this plugin's window widget extends.

Test types

Two main types of tests are maintained: unit tests and functional tests. In addition, a few manual tests and stress tests are part of this project.

Unit tests are more towards testing the widget's public API.

Functional tests are more towards testing the simulated user interactions and widgets visuals, although the distinction isn't strict.

Manual tests are those tests that cannot be automated, for example, when a required action, like click, must come from natural user action and cannot be simulated, or a required action needs to be performed outside of browser window, manually by the user.

Stress tests tests various functionalities using random data, or multiple times, or in many iterations.

Test list

Failing tests

It could happen that a particular test or set of tests fails in a certain environment. If you found a failling test, make sure you're doing everything right:

• The browser you are using is supported.
• The window the test or test suite was run was active and on top all the time. This is particularly important for Chrome, but can be a case in other browsers too.
• The device tests are run onto is not extremely busy or very ancient, in which case test relying on timeouts might be failing, because the device isn't performing fast enough.

If none of the above seems to be the case, please fill a bug report.

Writing tests

QUnit is used for maintaining test base.

Although test coverage is decent, new tests are always welcomed.

In most cases, you will add new tests to the existing test suites when writing unit and functional tests, but in some situations you can create a new test suite. Before you add new test suite, stronly consider extending the existing ones, and make sure that what you want to test is not already tested.

Writing new tests requires general knowledge about contributing code. Before doing major changes to the tests files, you might like to discuss them to get sure they won't get rejected.

Try to put stress tests into a separate files, within reason.

There are templates ready for particular types of tests:

Upon creating new test suite, copy template file into relevant directory, rename it to match it's planned content, and then follow the instructions in template to get you started. After you're done with setting up the file, add it to the file manifest. It's structure is pretty self-explanatory—it's used on this page to build test lists.

When you're done with new tests, make a pull request on GitHub.