Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>There isn't one right answer to your question, but rather a lot of good principles to learn from. Consider the following code. I've refactored your example. I'll explain everything I did below.</p> <pre><code>// Define your module in a self-executing function. // This module is now completely unit testable. var myModule = (function () { var num; function getNum() { $.getJSON('./getNumber.php', function (n) { num = n; }); } function alertNum() { alert(num); } // this returned object will by set to myModule and will publicly // expose the necessary functions return { getNum: getNum, alertNum: alertNum }; })(); // wire up your events $(function() { $("#id").on('click', myModule.alertNum); }); </code></pre> <p>This example is obviously overkill for this simple code, but it should give you some good ideas.</p> <ol> <li><p>Your core functionality is now encapsulated in a module. You keep additional private functions and variables inside the module (like <code>num</code>), but everything publicly exposed through the returned object can now be tested. (See Note below)</p></li> <li><p>I've wired up the events outside the module. If your module is large, you may even want to put this code in another script. Either way, it separates your concerns in a more MVC-like approach. You <em>can</em> test this chunk of code, but you shouldn't really have to; it should be very straightforward jQuery, and wrapping tests around it would be little more than testing the jQuery library, which has already been thoroughly tested by the jQuery team.</p></li> <li><p>This may seem weird, but don't use any jQuery selectors inside your module! If your module needs an element, pass it in as a function parameter. There are ways to stub that stuff out, but it's really a hassle, and shouldn't be necessary if you've properly separated your concerns. Most of my modules (or the objects in them) wind up with an <code>init()</code> method where I can pass in stuff. -- You might still choose to use jQuery's <code>.find()</code> method on your elements inside your module. That's more a judgement call only you can make based on your module's particular needs. Doing so will require you to do more detailed mocks of DOM elements in your tests, but sometimes it's just easier than passing in dozens of elements into <code>init()</code> (just pass in the main container instead).</p></li> </ol> <hr> <p>Note: I strongly recommend using <a href="http://requirejs.org/" rel="nofollow">RequireJS</a> or another AMD module loader for managing your modules. This will keep things like <code>myModule</code> above out of the global namespace. Setting up Require with QUnit is a little persnickety, though, and might be a problem to tackle later once you get a handle on unit testing.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload