text: Ext.data.JsonP.siesta_getting_started({"guide":"<h2 id='siesta_getting_started-section-description'>Description</h2>\n<div class='toc'>\n<p><strong>Contents</strong></p>\n<ol>\n<li><a href='#!/guide/siesta_getting_started-section-description'>Description</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-about-this-document'>About this document</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-requirements'>Requirements</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-getting-started'>Getting started</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-writing-tests-in-bdd-style'>Writing tests in BDD style</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-configuring-the-harness'>Configuring the harness</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-harness-page-vs-test-page'>Harness page vs Test page</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-assertions'>Assertions</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-user-interface'>User interface</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-testing-asynchronous-code'>Testing asynchronous code</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-simulating-user-interaction'>Simulating user interaction</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-detecting-global-variable-leaks'>Detecting global variable leaks</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-organizing-tests-in-folders'>Organizing tests in folders</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-configuring-individual-tests'>Configuring individual tests</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-%22todo%22-assertions'>\"TODO\" assertions</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-extending-the-test-class'>Extending the test class</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-automation'>Automation</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-best-practices'>Best practices</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-running-tests-in-nodejs'>Running tests in NodeJS</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-buy-this-product'>Buy this product</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-support'>Support</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-see-also'>See also</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-attribution'>Attribution</a></li>\n<li><a href='#!/guide/siesta_getting_started-section-copyright-and-license'>COPYRIGHT AND LICENSE</a></li>\n</ol>\n</div>\n\n<p>Siesta is a stress-free JavaScript unit testing tool. It is known that change of activity is a form of rest,\nso stop writing code, write some tests and have some rest! Your application will win from both.</p>\n\n<p>Siesta is very easy to learn and as your test suite grows and your requirements becomes more complex it still scales very well.</p>\n\n<p>Siesta is also cross-platform - the same tests can run in browsers and NodeJS (assuming of course they are written in a platform-independent manner).</p>\n\n<p><p><img src=\"guides/siesta_getting_started/images/demo.png\" alt=\"\" width=\"976\" height=\"642\"></p></p>\n\n<h2 id='siesta_getting_started-section-about-this-document'>About this document</h2>\n\n<p>This document is a complete manual, covering most use cases and details about using Siesta. There is no need to read it in full when you're starting out -\nread as much as you need to get started and return here when you feel you need information about some additional use case/feature.</p>\n\n<p>Although most of the examples use the Ext JS library, Siesta is a general-purpose testing library - it can test any code.</p>\n\n<h2 id='siesta_getting_started-section-requirements'>Requirements</h2>\n\n<p>To run tests that use XHR requests reliably across all browsers, you will need to use a local web server on your machine.</p>\n\n<h2 id='siesta_getting_started-section-getting-started'>Getting started</h2>\n\n<p>Start by creating a directory for your tests, let's say it will be \"/yourproject/tests\". Make it available via HTTP as for example\n\"http://localhost/yourproject/tests\".</p>\n\n<p>Now you will need a harness file. Harness is a kind of dashboard, which sets up the environment for each test and collects the results.\nLets name it \"index.js\" and put this code in it:</p>\n\n<pre><code>var Harness = <a href=\"#!/api/Siesta.Harness.Browser.ExtJS\" rel=\"Siesta.Harness.Browser.ExtJS\" class=\"docClass\">Siesta.Harness.Browser.ExtJS</a>;\n\nHarness.configure({\n    title       : 'Awesome Test Suite',\n\n    preload     : [\n        // version of ExtJS used by your application\n        '../ext-4.1.1/resources/css/ext-all.css',\n        '../resources/yourproject-css-all.css',\n\n        // version of ExtJS used by your application\n        '../ext-4.1.1/ext-all-debug.js',\n        '../yourproject-all.js'\n    ]\n});\n\nHarness.start(\n    '010_sanity.t.js',\n    '020_basic.t.js'\n);\n</code></pre>\n\n<p>Here we are configuring the harness to run 2 tests: <code>010_sanity.t.js</code> and <code>020_basic.t.js</code>. By default, each test will be run\nin <strong>its own</strong>, completely <strong>isolated</strong> and <strong>clean</strong> global scope. <strong>There is no need to cleanup anything</strong>.\nThe <a href=\"#!/api/Siesta.Harness.Browser-cfg-preload\" rel=\"Siesta.Harness.Browser-cfg-preload\" class=\"docClass\">preload</a> option specifies what files should be loaded prior each test. This behavior\nis configurable with the <a href=\"#!/api/Siesta.Harness.Browser-cfg-sandbox\" rel=\"Siesta.Harness.Browser-cfg-sandbox\" class=\"docClass\">sandbox</a> option, but we recommend you to keep it enabled\nuntil you start feeling yourself comfortable with Siesta.</p>\n\n<p><strong>All paths are relative to the harness file - <code>index.html</code></strong></p>\n\n<p>Now lets create an \"index.html\" file and include a link to \"index.js\" in it\" ` (this step is optional for the NodeJS platform):</p>\n\n<pre><code>&lt;!DOCTYPE html&gt;\n&lt;html&gt;\n    &lt;head&gt;\n        &lt;!-- Siesta UI must use ExtJS 5.1.0 (you can specify any other ExtJS version in your \"preload\" config) --&gt;\n        &lt;link rel=\"stylesheet\" type=\"text/css\" href=\"//cdn.sencha.com/ext/gpl/5.1.0/packages/ext-theme-crisp/build/resources/ext-theme-crisp-all.css\" /&gt;\n        &lt;link rel=\"stylesheet\" type=\"text/css\" href=\"__path_to_siesta__/resources/css/siesta-all.css\"&gt;\n\n        &lt;!-- Siesta UI must use ExtJS 5.1.0 (you can specify any other ExtJS version in your \"preload\" config) --&gt;\n        &lt;script type=\"text/javascript\" src=\"//cdn.sencha.com/ext/gpl/5.1.0/build/ext-all.js\"&gt;&lt;/script&gt;\n        &lt;script type=\"text/javascript\" src=\"__path_to_siesta__/siesta-all.js\"&gt;&lt;/script&gt;\n\n        &lt;script type=\"text/javascript\" src=\"index.js\"&gt;&lt;/script&gt;\n    &lt;/head&gt;\n\n    &lt;body&gt;\n    &lt;/body&gt;\n&lt;/html&gt;\n</code></pre>\n\n<p>Please note, that the harness page is subject for the same-origin policy as any other web pages. You can include the scripts/css from another domains, but XHR requests on older browsers\nare restricted to the same domain. The best approach is to run the test suite on the same domain as your application. You can also configure a proxy.</p>\n\n<p>Ok, we are ready to write a simple sanity test. It's always a good idea to start your test suite with some sanity checks that ensure the environment is really\nin the state that you expect. For example since we are preloading the ExtJS library, let's make sure it is really there. Also, let's check your main class <code>Your.Project</code> has been\nloaded as well.</p>\n\n<p>Here is how the content of such sanity test will look like (put this into <code>010_sanity.t.js</code> file):</p>\n\n<pre><code>// also supports: startTest(function(t) {\nStartTest(function(t) {\n    t.diag(\"Sanity\");\n\n    t.ok(Ext, 'ExtJS is here');\n    t.ok(Ext.Window, '.. indeed');\n\n\n    t.ok(Your.Project, 'My project is here');\n    t.ok(Your.Project.Util, '.. indeed');\n\n    t.done();   // Optional, marks the correct exit point from the test\n})    \n</code></pre>\n\n<p>The test code should be wrapped with <code>StartTest(function (t) { ... })</code> construct. The function passed to it will receive an instance of the <a href=\"#!/api/Siesta.Test\" rel=\"Siesta.Test\" class=\"docClass\">Siesta.Test</a> as the 1st argument.\nCamel cased variant <code>startTest(function (t) { ... })</code> is also supported and can be used if you are using JSLint code validation or similar tool.</p>\n\n<p>The instance of test class has various methods for <em>assertion checking</em>. An \"assertion\" is any statement about your code. It may have arbitrary semantics,\nranging from very simple, like \"this variable is equal to that variable\" to complex and domain specific: \"this instance of Observable will fire this event exactly N\ntimes during the following X milliseconds\". Siesta has various general-purpose assertions built-in and it also allows you to create your own assertions.\nThe statement of the assertion can be either truthy (we'll say - assertion pass) or false (assertion fail).</p>\n\n<p>In the example above we use the simplest possible assertion: <code>t.ok(value, description)</code>. It passes when the provided <code>value</code> is \"truthy\", like : <code>true / 1 / \"TRUE\" / {}</code> etc\nand fails otherwise. Each assertion also has an optional description which should contain an explanation of what's being asserted.</p>\n\n<p>At the end of each test, one can optionally call <code>t.done()</code> method. It will tell to Siesta that the test has reached the correct exit point and no other assertions should be added.\nTo make this call required, use the <a href=\"#!/api/Siesta.Harness-cfg-needDone\" rel=\"Siesta.Harness-cfg-needDone\" class=\"docClass\">needDone</a> configuration option. See also \"Testing asynchronous code\" section below.</p>\n\n<p>Ok, we have a harness and test, lets open the <code>index.html</code> file in a browser and click the \"Run all\" button in the toolbar. You should see something like this:</p>\n\n<p><p><img src=\"guides/siesta_getting_started/images/synopsys.png\" alt=\"\" width=\"976\" height=\"642\"></p></p>\n\n<p>The \"020_basic.t.js\" has a red cross indicating the file is missing - why not create it after reading a couple of the following sections? ;)</p>\n\n<h2 id='siesta_getting_started-section-writing-tests-in-bdd-style'>Writing tests in BDD style</h2>\n\n<p>Siesta supports BDD syntax for writing your tests. Please refer to this guide for more information: <a href=\"#!/guide/bdd_conventions\">Writing tests in BDD style.</a></p>\n\n<h2 id='siesta_getting_started-section-configuring-the-harness'>Configuring the harness</h2>\n\n<p>A harness can be configured with the <a href=\"#!/api/Siesta.Harness.Browser.ExtJS-method-configure\" rel=\"Siesta.Harness.Browser.ExtJS-method-configure\" class=\"docClass\">configure</a> method. See the <a href=\"#!/api/Siesta.Harness.Browser.ExtJS\" rel=\"Siesta.Harness.Browser.ExtJS\" class=\"docClass\">Siesta.Harness.Browser.ExtJS</a> for a detailed description of all available options.\nThe most important option is <a href=\"#!/api/Siesta.Harness.Browser.ExtJS-cfg-preload\" rel=\"Siesta.Harness.Browser.ExtJS-cfg-preload\" class=\"docClass\">preload</a>, which defines the files that should be pre-loaded for each test.\nAll urls in <a href=\"#!/api/Siesta.Harness.Browser.ExtJS-cfg-preload\" rel=\"Siesta.Harness.Browser.ExtJS-cfg-preload\" class=\"docClass\">preload</a> are relative to the harness file <code>index.html</code>.</p>\n\n<p>Once the harness is configured, you can launch your suite with the <a href=\"#!/api/Siesta.Harness.Browser.ExtJS-method-start\" rel=\"Siesta.Harness.Browser.ExtJS-method-start\" class=\"docClass\">start</a> method.</p>\n\n<p>Note that the harness file contains regular javascript code, so you can for example configure it differently depending on some condition:</p>\n\n<pre><code>var isDev   = window.location.href.match(/localhost/);\nvar Harness = <a href=\"#!/api/Siesta.Harness.Browser.ExtJS\" rel=\"Siesta.Harness.Browser.ExtJS\" class=\"docClass\">Siesta.Harness.Browser.ExtJS</a>;\n\nHarness.configure({\n    title       : 'Awesome Test Suite',\n\n    preload     : [\n        isDev ? '../ext-4.0.6/ext-all-debug.js' : '../ext-4.0.6/ext-all.js',\n        isDev ? '../yourproject-all-debug.js' : '../yourproject-all.js'\n    ]\n});\n\nHarness.start(\n    ...\n);\n</code></pre>\n\n<h2 id='siesta_getting_started-section-harness-page-vs-test-page'>Harness page vs Test page</h2>\n\n<p>As it was mentioned above, Siesta runs each test isolated - on its <em>own</em> \"test\" page. In the same time, there's a page with Harness\nUI page, showing all the tests, results from them etc. Don't confuse these two pages - they are not related.</p>\n\n<p>Typical mistake is to include Siesta files in the \"preload\" option:</p>\n\n<pre><code>Harness.configure({\n    title       : 'Awesome Test Suite',\n\n    preload     : [\n        '../../siesta-all.js', // WRONG, no need to include siesta files on the test page\n        '../my-app-all.js'\n    ]\n});\n</code></pre>\n\n<p>In the same manner don't include the files from your application to the harness page (index.html we've created above)</p>\n\n<h2 id='siesta_getting_started-section-assertions'>Assertions</h2>\n\n<p>Some assertions are generic and cross platform - they belong to the <a href=\"#!/api/Siesta.Test\" rel=\"Siesta.Test\" class=\"docClass\">Siesta.Test</a> class. Others are browser/ExtJS specific - and those are\nlisted in the <a href=\"#!/api/Siesta.Test.Browser\" rel=\"Siesta.Test.Browser\" class=\"docClass\">Siesta.Test.Browser</a> / <a href=\"#!/api/Siesta.Test.ExtJS\" rel=\"Siesta.Test.ExtJS\" class=\"docClass\">Siesta.Test.ExtJS</a> classes.</p>\n\n<p>When an assertion passes - it shows a green checkmark with the assertion description (if description is not provided, Siesta will try to generate\na sensible default text). When it fails, it also tries to provide you with as much information about the failure as possible, including the\narguments passed to the assertion method. This is why you are encouraged to use various special assertions for each specific case. For example,\nlets say we would like to check if one value is greater than other. We could do that with a simple:</p>\n\n<pre><code>t.ok(value1 &gt; value2, 'Value1 is greater than value2')\n</code></pre>\n\n<p>But in case of a failure, the only additional information you will see will be something like:</p>\n\n<pre><code>Failed assertion [ok] at line xxx, \nGot  : false, \nNeed : \"truthy\" value\"\n</code></pre>\n\n<p>Compare with the output from the more specific \"isGreater\" assertion:</p>\n\n<pre><code>t.isGreater(value1, value2, 'Value1 is greater than value2')\n</code></pre>\n\n<p>It will output the message along with the provided arguments, instantly making it clear what happened:</p>\n\n<pre><code>Failed assertion [isGreater] at line xxx, \nGot                : value1, \nNeed, greater than : value2\n</code></pre>\n\n<p>So make sure you've scanned the documentation <a href=\"#!/api/Siesta.Test\" rel=\"Siesta.Test\" class=\"docClass\">Siesta.Test</a> or <a href=\"#!/api/Siesta.Test.ExtJS\" rel=\"Siesta.Test.ExtJS\" class=\"docClass\">Siesta.Test.ExtJS</a> - doing so will save you a lot of time.</p>\n\n<p>At this point you should have enough information to start - feel free to leave this document and start hacking your test suite together :)</p>\n\n<h2 id='siesta_getting_started-section-user-interface'>User interface</h2>\n\n<p>The harness UI is stateful - it keeps the selected row, checked rows and options in cookies. You can refresh the harness page anytime and your settings will remain.</p>\n\n<p>The rows in the test files grid has a context menu:\n<p><img src=\"guides/siesta_getting_started/images/ui-context-menu.png\" alt=\"\" width=\"401\" height=\"236\"></p></p>\n\n<p>The \"Options\" button in toolbar, contains several checkboxes corresponding to harness <a href=\"#!/api/Siesta.Harness.Browser.ExtJS\" rel=\"Siesta.Harness.Browser.ExtJS\" class=\"docClass\">configuration options</a>:\n<p><img src=\"guides/siesta_getting_started/images/ui-configure-buttons.png\" alt=\"\" width=\"165\" height=\"245\"></p></p>\n\n<h2 id='siesta_getting_started-section-testing-asynchronous-code'>Testing asynchronous code</h2>\n\n<p>When testing asynchronous code, the test function (passed to <code>StartTest</code>) may complete its execution, but the test itself\nwill still be running and incoming assertions will be valid. So, you need to explain to the test, that it needs to wait some time before finalizing.</p>\n\n<p>For that, before some asynchronous part of the code is started, indicate its beginning with <a href=\"#!/api/Siesta.Test-method-beginAsync\" rel=\"Siesta.Test-method-beginAsync\" class=\"docClass\">Siesta.Test.beginAsync</a> or <a href=\"#!/api/Siesta.Test-method-wait\" rel=\"Siesta.Test-method-wait\" class=\"docClass\">Siesta.Test.wait</a> methods.\nThen, once the async code complete, use <a href=\"#!/api/Siesta.Test-method-endAsync\" rel=\"Siesta.Test-method-endAsync\" class=\"docClass\">Siesta.Test.endAsync</a> or <a href=\"#!/api/Siesta.Test-method-endWait\" rel=\"Siesta.Test-method-endWait\" class=\"docClass\">Siesta.Test.endWait</a> accordingly.</p>\n\n<p>Both beginAsync and wait methods will start an \"asynchronous code frame\", the only difference is that <code>beginAsync</code> will return you an auto-generated id for it\n(which you need to save to some variable), and <code>wait</code> need to receive an unique id as parameter.</p>\n\n<p>For example:</p>\n\n<pre><code>var async = t.beginAsync();\n\nExt.Ajax.request({\n    url     : 'ajax_demo/sample.json',\n\n    success : function (response, opts) {\n        t.is(response, 'foobar', 'Response is correct');\n\n        t.endAsync(async);\n    },\n\n    failure : function (response, opts) {\n        t.fail(\"request failed\");\n\n        t.endAsync(async);\n    }\n});\n</code></pre>\n\n<p>Or the same with <code>wait</code>:</p>\n\n<pre><code>t.wait('xhrSample');\n\nExt.Ajax.request({\n    url     : 'ajax_demo/sample.json',\n\n    success : function (response, opts) {\n        t.is(response, 'foobar', 'Response is correct');\n\n        t.endWait('xhrSample');\n    },\n\n    failure : function (response, opts) {\n        t.fail(\"request failed\");\n\n        t.endWait('xhrSample');\n    }\n});\n</code></pre>\n\n<p>You can start as many asynchronous code \"frames\" as you need. By default, all frames will be forced to finalize after 15 seconds, so the whole test\nwill not get stuck in case of unexpected failures. You can configure this interval in the <a href=\"#!/api/Siesta.Test-method-beginAsync\" rel=\"Siesta.Test-method-beginAsync\" class=\"docClass\">beginAsync</a> and <a href=\"#!/api/Siesta.Test-method-wait\" rel=\"Siesta.Test-method-wait\" class=\"docClass\">wait</a> calls.</p>\n\n<p>Note, that you don't need to use these methods for built-in Siesta methods that accepts callbacks - Siesta already does that for you:</p>\n\n<pre><code>// the \"click\" method is asynchronous and accepts a callback\n// there's no need for `beginAsync` though, since its a built-in method\nt.click('.some-button', function () {\n}) \n</code></pre>\n\n<h3 id='siesta_getting_started-section-chaining'>Chaining</h3>\n\n<p>Many methods of the test class are asynchronous and accept a callback. When you need to execute one such method after another,\nthe nesting level can grow quite quickly and affect the readability of the test code:</p>\n\n<pre><code>t.type(userNameField, 'username', function () {\n    t.type(passwordField, 'secret', function () {\n        t.click(loginButton, function () {\n            // done\n        })\n    })\n})\n</code></pre>\n\n<p>If you see such code in your tests, make sure you've checked the <a href=\"#!/api/Siesta.Test-method-chain\" rel=\"Siesta.Test-method-chain\" class=\"docClass\">chain</a> method. It allows you keep the nesting to a minimum:</p>\n\n<pre><code>t.chain(\n    function (next) {\n        t.type(userNameField, 'username', next)\n    },\n    function (next) {\n        t.type(passwordField, 'secret', next)\n    },\n    function (next) {\n        t.click(loginButton, next)\n    },\n    function () {\n        // done\n    }\n})\n</code></pre>\n\n<p>Or even more compact notation, providing action configuration objects instead of functions:</p>\n\n<pre><code>t.chain({\n    action  : 'type',\n    target  : userNameField, \n    text    : 'username'\n},{\n    action  : 'type',\n    target  : passwordField, \n    text    : 'secret'\n},{\n    action  : 'click',\n    target  : loginButton \n})\n</code></pre>\n\n<h3 id='siesta_getting_started-section-waiting'>Waiting</h3>\n\n<p>Since the nature of web applications is very asynchronous (Ajax calls, animations, etc.), be prepared to wait a lot in your tests.\nTo wait for a condition, do:</p>\n\n<pre><code>this.waitFor(\n    // The condition to check for, this line will mean waiting until the presence of #foo element\n    function() { return document.getElementById('foo'); },  \n\n    // The callback, after the condition has been fulfilled\n    function(el) { /* DO COOL STUFF */ }          \n);\n</code></pre>\n\n<p>You will find lots and lots of waitForXXX methods in the API to assist you in various situations, example:</p>\n\n<pre><code>t.waitForSelector('.some_class', function() {\n    // Found it\n});\n\ndocument.body.className = 'some_class'; // this fulfills the condition, \n                                        // and the callback function is called\n</code></pre>\n\n<p>You can also wait easily in a chain, by adding a \"waitFor\" step with a value equal to XXX of any waitForXXX command as the value:</p>\n\n<pre><code>t.chain({\n    { waitFor : 'selector', args : ['.some_class'] },   // calls waitForSelector which waits until \n                                                        // the some_class CSS class exists in the DOM\n\n    { waitFor : 500 },                                  // waits for 500 ms\n\n    { waitFor : 'elementVisible', args : [someEl] },    // calls waitForElementVisible and waits \n                                                        // for an element to become visible\n });\n</code></pre>\n\n<h2 id='siesta_getting_started-section-simulating-user-interaction'>Simulating user interaction</h2>\n\n<p>Siesta can simulate user interactions such as click, double click, type, drag-drop etc. You can find these various methods documented in the API under Test/Simulate. Keep\nin mind, for tests involving mouse interaction - you should not move the mouse during the execution of such test, when it runs visibly.</p>\n\n<h2 id='siesta_getting_started-section-detecting-global-variable-leaks'>Detecting global variable leaks</h2>\n\n<p>Siesta has a special built-in assertion, called <a href=\"#!/api/Siesta.Test-method-verifyGlobals\" rel=\"Siesta.Test-method-verifyGlobals\" class=\"docClass\">t.verifyGlobals()</a>. It will scan the global properties of the test 'window' object,\nand compare them with the properties of a clean and fresh scope (properties from an empty <code>&lt;iframe&gt;</code>). In case it finds any \"unexpected\" globals\nit will report them as a test failure. You can specify your list of additional \"expected\" globals, using the <a href=\"#!/api/Siesta.Harness-cfg-expectedGlobals\" rel=\"Siesta.Harness-cfg-expectedGlobals\" class=\"docClass\">expectedGlobals</a> configuration\noption of the harness, or by using the <a href=\"#!/api/Siesta.Test-method-expectGlobals\" rel=\"Siesta.Test-method-expectGlobals\" class=\"docClass\">t.expectGlobals</a> method of your test.</p>\n\n<p>You can enable this assertion to be executed automatically at the end of each test, by setting <a href=\"#!/api/Siesta.Harness-cfg-autoCheckGlobals\" rel=\"Siesta.Harness-cfg-autoCheckGlobals\" class=\"docClass\">autoCheckGlobals</a> to true on the harness configuration.</p>\n\n<p>For example, in harness:</p>\n\n<pre><code>Harness.configure({\n    autoCheckGlobals    : true,\n    expectedGlobals     : [ 'Ext', 'MyProject' ],\n    ...\n});\n</code></pre>\n\n<p>And then in tests:</p>\n\n<pre><code>// will suppress the complaints about these globals\nt.expectGlobals('Additional', 'Globals');\n</code></pre>\n\n<p>Please note however, that this feature is not supported in IE &lt;= 8, due to a bug in its JavaScript implementation: <a href=\"http://social.msdn.microsoft.com/Forums/en/iewebdevelopment/thread/065a5b93-6474-4756-aaea-1fd55d4a013a\">http://social.msdn.microsoft.com/Forums/en/iewebdevelopment/thread/065a5b93-6474-4756-aaea-1fd55d4a013a</a>\nAlso see: <a href=\"http://blogs.msdn.com/b/ericlippert/archive/2005/05/04/414684.aspx\">http://blogs.msdn.com/b/ericlippert/archive/2005/05/04/414684.aspx</a></p>\n\n<h2 id='siesta_getting_started-section-organizing-tests-in-folders'>Organizing tests in folders</h2>\n\n<p>As your test suite grows, you may need to start grouping your tests in a logical hierarchy. You can do this easily by passing special \"test file descriptors\" instead of strings to the <a href=\"#!/api/Siesta.Harness-method-start\" rel=\"Siesta.Harness-method-start\" class=\"docClass\">Siesta.Harness.start</a> method.\nThe descriptor should contain a group name and an array of child descriptors:</p>\n\n<pre><code>Harness.configure({\n    ...\n});\n\nHarness.start(\n    '011_simple.t.js',\n    '012_complex.t.js',\n    {\n        group       : 'Rendering tests',\n\n        items       : [\n            'rendering/grid.t.js',\n            'rendering/tree.t.js'\n        ]\n    }\n);\n</code></pre>\n\n<p>In turn, child descriptors can be groups as well. This feature is especially useful, when you need to override the <a href=\"#!/api/Siesta.Harness.Browser.ExtJS\" rel=\"Siesta.Harness.Browser.ExtJS\" class=\"docClass\">harness</a>\noptions for some group of tests (see the following section).</p>\n\n<p>See also <a href=\"#!/api/Siesta.Harness-method-start\" rel=\"Siesta.Harness-method-start\" class=\"docClass\">Siesta.Harness.start</a> method for additional information.</p>\n\n<h2 id='siesta_getting_started-section-configuring-individual-tests'>Configuring individual tests</h2>\n\n<p>When configuring a \"test file descriptor\", one can also provide some of the harness configuration options and they will override the corresponding options that were provided to the harness.\nThese options are explicitly marked in the <a href=\"#!/api/Siesta.Harness.Browser.ExtJS\" rel=\"Siesta.Harness.Browser.ExtJS\" class=\"docClass\">harness</a> documentation.\nFor example, one can have a test with its own <code>preload</code> and <code>autoCheckGlobals</code> configs:</p>\n\n<pre><code>Harness.configure({\n    autoCheckGlobals    : false\n    ...\n})\n\nHarness.start(\n    {\n        url     : '011_simple.t.js',\n\n        autoCheckGlobals : true,\n        preload : [\n            ...\n        ]\n    },\n    '012_complex.t.js'\n)\n</code></pre>\n\n<p>When specifying config options for a group descriptor, these options will override the configuration for all child descriptors of that group:</p>\n\n<pre><code>Harness.start(\n    {\n        group       : 'On demand loading',\n\n        // will override the `preload` option for all tests in this group\n        preload     : [\n            ...\n        ],\n\n        items       : [\n            ...\n        ]\n    }\n)\n</code></pre>\n\n<p>You can also provide test file descriptor in the test file itself, by addding it to the StartTest call:</p>\n\n<pre><code>StartTest({\n    autoCheckGlobals : false\n}, function (t) {\n    ...\n}) \n</code></pre>\n\n<p>Values from this object takes the highest priority and will override any other configuration.</p>\n\n<p>See also <a href=\"#!/api/Siesta.Harness-method-start\" rel=\"Siesta.Harness-method-start\" class=\"docClass\">Siesta.Harness.start</a> method for additional information.</p>\n\n<h2 id='siesta_getting_started-section-%22todo%22-assertions'>\"TODO\" assertions</h2>\n\n<p>Sometimes you might want to mark some assertions in a test as \"TODO\". For example, you might start to write a test covering an edge case,\nbut only fully implement it later. It's still desirable to run such assertions (sometimes they can accidentally start passing actually),\nbut if they fail - that doesn't mean a failure of the whole test.</p>\n\n<p>In such cases you can wrap your assertions using the <a href=\"#!/api/Siesta.Test-method-todo\" rel=\"Siesta.Test-method-todo\" class=\"docClass\">t.todo()</a> method:</p>\n\n<pre><code>t.todo('Scheduled for 4.1.x release', function (todo) {\n\n    var treePanel    = new Ext.tree.Panel()\n\n    todo.is(treePanel.getView().store, treePanel.store, \"NodeStore and TreeStore have been merged and there's only 1 store now\");\n})\n</code></pre>\n\n<p>As you can see, the <code>todo</code> method accepts a description and a new test function. That function will receive a new \"TODO\" test instance, as the 1st argument\n(you can name it arbitrarily). Any failures coming from the methods of this new test instance will be reported as \"green\", as they are expected.</p>\n\n<p>See also <a href=\"#!/api/Siesta.Test-method-snooze\" rel=\"Siesta.Test-method-snooze\" class=\"docClass\">snooze</a> method.</p>\n\n<h2 id='siesta_getting_started-section-extending-the-test-class'>Extending the test class</h2>\n\n<p>Quite often you may find yourself repeating various initialization code in your tests. Or you may have your own assertions, specific to your data.\nTo avoid repeation, you can extend the default Siesta test class by adding own methods to it. Please refer to <a href=\"#!/guide/extending_test_class\">this guide</a> to know more.</p>\n\n<h2 id='siesta_getting_started-section-automation'>Automation</h2>\n\n<p>You can run your tests from the command line using a headless Webkit (provided by PhantomJS). This option is suitable for Linux servers w/o graphic cards.\nOr, you can launch your tests in several browsers simultaneously, using Selenium. Please refer to <a href=\"#!/guide/siesta_automation\">Automation Guide.</a> for more information.</p>\n\n<h2 id='siesta_getting_started-section-best-practices'>Best practices</h2>\n\n<p>In general, you can organize your tests suite as you prefer - there are no strict rules where to place the files, how to name them, etc. Choose the way\nthat is more appropriate and efficient in your case.</p>\n\n<p>There are, however, some simple guidelines. First of all, treat your test suite as you treat your main codebase. After all <em>it is</em> a part of your codebase, just not visible to the end user.\nYou will need to maintain it, update tests after refactoring (refactoring having a test suite is very pleasant experience btw) and so on.</p>\n\n<p>So, use the same coding style and practices as in your main codebase, provide meaningful assertion descriptions, write comments in non-trivial places, avoid repeating code\nand keep your test suite up-to-date.</p>\n\n<h2 id='siesta_getting_started-section-running-tests-in-nodejs'>Running tests in NodeJS</h2>\n\n<p>If your code is written in a cross-platform manner, you can also run your tests in NodeJS. For that, first of all, install Siesta in the \"node_modules\"\nfolder of your project. Then, in the harness, detect the platform and choose a correct harness class, like this:</p>\n\n<pre><code>var Harness\n\nif (typeof process != 'undefined' &amp;&amp; process.pid) {\n    Harness = require('siesta');\n} else {\n    Harness = <a href=\"#!/api/Siesta.Harness.Browser.ExtJS\" rel=\"Siesta.Harness.Browser.ExtJS\" class=\"docClass\">Siesta.Harness.Browser.ExtJS</a>\n}\n</code></pre>\n\n<p>And finally, launch the harness file in NodeJS:</p>\n\n<pre><code>&gt; node tests/index.js\n</code></pre>\n\n<p>You will see the same output as when running the test suite in PhantomJS. See also the \"nodejs-browsers\" example in the \"/examples\" folder.</p>\n\n<p>In case of any failures in the test suite, the command will exit with non-zero exit code.</p>\n\n<h2 id='siesta_getting_started-section-buy-this-product'>Buy this product</h2>\n\n<p>Visit our store: <a href=\"http://bryntum.com/store/siesta\">http://bryntum.com/store/siesta</a></p>\n\n<h2 id='siesta_getting_started-section-support'>Support</h2>\n\n<p>Ask question in our community forum: <a href=\"http://www.bryntum.com/forum/viewforum.php?f=20\">http://www.bryntum.com/forum/viewforum.php?f=20</a></p>\n\n<p>Share your experience in our IRC channel: <a href=\"http://webchat.freenode.net/?randomnick=1&amp;channels=bryntum&amp;prompt=1\">#bryntum</a></p>\n\n<p>Please report any bugs through the web interface at <a href=\"https://www.assembla.com/spaces/bryntum/support/tickets\">https://www.assembla.com/spaces/bryntum/support/tickets</a></p>\n\n<h2 id='siesta_getting_started-section-see-also'>See also</h2>\n\n<p>Web page of this product: <a href=\"http://bryntum.com/products/siesta\">http://bryntum.com/products/siesta</a></p>\n\n<p>Other Bryntum products: <a href=\"http://bryntum.com/products\">http://bryntum.com/products</a></p>\n\n<h2 id='siesta_getting_started-section-attribution'>Attribution</h2>\n\n<p>This software contains icons from the following icon packs (licensed under Creative Common 2.5/3.0 Attribution licenses)</p>\n\n<ul>\n<li><a href=\"http://www.famfamfam.com/lab/icons/silk/\">http://www.famfamfam.com/lab/icons/silk/</a></li>\n<li><a href=\"http://led24.de/iconset/\">http://led24.de/iconset/</a></li>\n<li><a href=\"http://p.yusukekamiyamane.com/\">http://p.yusukekamiyamane.com/</a></li>\n<li><a href=\"http://rrze-icon-set.berlios.de/index.html\">http://rrze-icon-set.berlios.de/index.html</a></li>\n<li><a href=\"http://www.smashingmagazine.com/2009/05/20/flavour-extended-the-ultimate-icon-set-for-web-designers/\">http://www.smashingmagazine.com/2009/05/20/flavour-extended-the-ultimate-icon-set-for-web-designers/</a></li>\n<li><a href=\"http://www.doublejdesign.co.uk/products-page/icons/super-mono-icons/\">http://www.doublejdesign.co.uk/products-page/icons/super-mono-icons/</a></li>\n<li><a href=\"http://pixel-mixer.com/\">http://pixel-mixer.com/</a></li>\n</ul>\n\n\n<p>Thanks a lot to the authors of the respective icons packs.</p>\n\n<h2 id='siesta_getting_started-section-copyright-and-license'>COPYRIGHT AND LICENSE</h2>\n\n<p>Copyright (c) 2009-2014, Bryntum &amp; Nickolay Platonov</p>\n\n<p>All rights reserved.</p>\n","title":"Getting Started with Siesta - stress free JavaScript unit testing"});