Directives with isolate scope do not inherit their scope from their parent.  Thus, the pattern to test them is slightly different.



When testing a directive, you'll often want to setup some fixture element to attach your directive to.  This will act as the DOM that you will compile with scope.  At that point, the variables that you attached to scope will be available within the directive under test.

For example, if I had a directive called `AccountList` with isolate scope:

```coffeescript
angular.module('app').directive 'AccountList', ->
  restrict: 'EA'
  replace: true
  scope:
    accounts: '='
  # etc ...
```

Then I would setup my test something like this:

```coffeescript
describe 'AccountList', ->

  elm = null

  beforeEach inject ($rootScope, $compile) ->
    accounts = []
    for num in [1..5]
      accounts.push createFakeAccount()
    $rootScope.accounts = accounts

    elm = angular.element """
      <account-list accounts="accounts"></account-list>
    """

    e = $compile(elm)($rootScope)
    e.scope().$digest()

  # actual specs, using elm ...
```

A few points:

- `inject()` comes from `angular-mock`.  It is currently only supported in Jasmine.
- Before each test of the `AccountList` directive, a set of 5 accounts will be put in scope so the directive, presumably, has something to display.
- `$rootScope` is going to be the only scope that you can get to easily from your tests.  You can attach variables to it directly as above or call `$rootScope.$new()` to generate a new scope if you'd like.
- We initially `$compile` the fixture element, passing in `$rootScope`.
- To get Angular to actually act internally on the variables that we've passed into the directive and put them on scope, we must call the important line of code: `e.scope().$digest()`.

Now you should be ready to rock and roll with your tests.  Isolate scopes can be tricky.  Testing them, a bit tricky as well.

Do you know a better way?

Directives with isolate scope do not inherit their scope from their parent.  Thus, the pattern to test them is slightly different.

Test Angular Directive With Isolate Scope

Code that utilizes `setTimeout` or `setInterval` becomes asynchronous.  Jasmine has some nice helpers to make your test synchronous again.



## Code Using setTimeout

Any Javascript code that wants to delay certain actions or give intervals between actions will use `setTimeout` or `setInterval` respectively.  There are also libraries that create some niceties for working in these situations, notably [underscore](http://underscorejs.org)'s `_.throttle` and `_.debounce` functions.  Underneath all of these higher-level functions, they're using the native `setTimeout` construct, so the same strategies will apply.  In your source, you end up with something like this:

```coffeescript
$(document).on 'keyup', '.autocomplete-field', _.debounce(autocomplete, 500)
```

This code binds a keyup event listener on a contrived `.autocomplete-field`.  Of course, we don't want to do an expensive `autocomplete` lookup on every keypress.  So, we'll slow it down a bit with `_.debounce`.

## Testing Asynchronous Code in Jasmine

Now we go to test it in Jasmine (failing):

```coffeescript
  describe 'Autocomplete Field', ->

    it 'calls autocomplete when typing', ->
      called = false
      autocomplete = ->
        called = true

      keyup = $.Event('keyup')
      $('.autocomplete-field').trigger keyup
      called.should.be.true
```

In this test, or `autocomplete` spy will never be called, thus `called` will never be true.  There are a few ways to fix this.

## Mocking the Jasmine Clock

One way to fix the test is to remove `_.debounce` from our source code.  That would make the test pass.  The other is to setup our Jasmine to handle the `setTimeout` used in `_.debounce`.  Let's do the latter, and raise our fists to the sky in triumph over our testing foe (winning):

```coffeescript
  describe 'Autocomplete Field', ->

    beforeEach ->
      jasmine.Clock.useMock()

    it 'calls autocomplete when typing', ->
      called = false
      autocomplete = ->
        called = true

      keyup = $.Event('keyup')
      $('.autocomplete-field').trigger keyup
      jasmine.Clock.tick 501
      called.should.be.true
```

The needed code is simple to add.  Use `jasmine.Clock.useMock()` to setup the fake ticker.  Then call `tick()` on it whenever you want your test to simulate time massage.

The cool thing is that this does not slow down your tests.  You could set the clock tick to be 50100000 or some crazy number, and it will still execute as fast as your single JavaScript thread will let you.

Boom.  Another testing hurdle cleared.  Sometimes it's harder to write the test than the code.

Code that utilizes setTimeout or setInterval becomes asynchronous.  Jasmine has some nice helpers to make your test synchronous again.

Test setTimeout with Jasmine

As more application logic gets pushed into the browser for client-heavy apps, the need for javascript testing increases.  Lately, I've been doing some Jasmine unit testing of an application that uses RequireJS.  Here are some general pointers and potential pitfalls to watch for.



Jasmine Standalone
------------------

After messing with potentially running the tests with the Jasmine Maven plugin, inside NodeJS, and headless webkit, I came back to the simplest solution.  I came back because after much heartache, I just wanted something to work.  [Jasmine standalone](http://pivotal.github.com/jasmine/download.html) has done the trick.  

Test Runner Setup
-----------------

[RequireJS paths](http://requirejs.org/docs/api.html#config) can be tricky.  For some reason, the trickiness seems to increase inside the testing environment.  To try and make relative pathing easier, I've included my test directory inside my app's js directory, like so:

```bash
js/
  test/
    tests/
    runner.html        
```

Jasmine standalone just uses a plain old HTML file for its runner.  My RequireJs Jasmine runner structure looks like this:

```html
<!DOCTYPE html>
<html>
<head>
  <title>Spec Runner</title>
  
  <link rel="shortcut icon" type="image/png" href="vendor/jasmine_favicon.png">
  <link rel="stylesheet" type="text/css" href="vendor/jasmine.css">
  <script type="text/javascript" src="vendor/jasmine.js"></script>
  <script type="text/javascript" src="vendor/jasmine-html.js"></script>
  

  
  <script type="text/javascript" src="../vendor/jquery.js"></script>
  <script type="text/javascript" src="../require.js"></script>
  

  <script type="text/javascript">

    // This is key!
    require.config({
      baseUrl: '../'
    });
    
    require([
      '../test/tests/MyCode.spec'
    ],
      function() {
        $(function() {
          jasmine.getEnv().addReporter(new jasmine.TrivialReporter());
          jasmine.getEnv().execute();
        });
      });
    
  </script>
</head>
<body>
  
</body>
</html>
```

Import everything that is global via the old-fashioned method -- just a `<script/>` tag in the `<head/>`.  Then, write and import your specs as RequireJS modules, and just require them in your runner.  

A Runner Per main.js
--------------------

When I'm writing RequireJS modules in the app, I'm using relative paths.  These paths are always relative to the main module that uses these other require modules.  Thus, when you configure your runner, the `baseUrl` *needs* to point to the directory of the main module that in turn imports the modules under test.  And thus it follows that you'll actually need a separate runner for each main module in your app.  So, if you're a true single-page app, you'll only have one module.  But, for example, in the app I'm currently dev'ing, we have a public main.js and an admin main.js, so we have a public-runner.html and an admin-runner.html.

This is only an issue if your app uses relative paths.  If you use absolute paths in your app modules, the new issue will be that you'll have to be able to run your tests from the exact context from which your app usually runs.  

Require and Jquery
------------------

Just a note:  Even though I use `require-jquery.js` in my app, I found that for some reason Jasmine didn't appreciate that, and I had to import `jquery.js` and `require.js` separately.  If anyone knows why, I'd love to be enlightened.

Run on an HTTP Server
---------------------

This probably goes without saying for anyone that has used require for some time, but since require dependencies are asynchronously loaded, you're going to run into problems with cross domain policies in your local dev.  I use Chrome, and I immediately start seeing errors if I run from the filesystem:

```bash
XMLHttpRequest cannot load file:///.../MyCodeDependency.js. Cross origin requests are only supported for HTTP.
Uncaught Error: NETWORK_ERR: XMLHttpRequest Exception 101
```

You could start Chrome with a flag to ignore this cross-domain policy, but I prefer to just spin up a little http server action with [nginx](http://nginx.org/en/) and edit `/etc/nginx/sites-available/default` to point the server root at your projects `js/` directory and restart nginx (`sudo service nginx restart`).  Then get to your runner at something like `http://localhost/test/runner.html`.

Require Test Fixtures
---------------------

Another reason to run your tests on an http server is for ease of importing text fixtures.  The way we've set up our runner, the baseUrl is configured to be the js root directory, which allows our app code to work unchanged, but now we've made it potentially harder for us to get to test dependencies that aren't in the application code area.  This may just be my own ignorance of RequireJS shining through, but when I set `baseUrl: '../admin/'` for my `admin-runner.html` and try to import a test fixture w/ relative paths in the test, the paths are supremely messed up.  Thus, with this directory structure:

```bash
js/
  test/
    tests/
      admin/
        TestNeedingFixture.spec.js
      fixtures/
        data.js
    admin-runner.html    
```

I'm forced to import with server absolute paths like this:

```javascript
define(['OtherAdminCode', '/test/tests/fixtures/data.js'], function (OtherAdminCode, data) {
  describe('AdminCode', function () {  
    it ('is awesome', function () {
      expect(somethingWithData).toBeAwesome();
    });
  });
});
```

So, again, if I wasn't running tests on an Http server, this wouldn't work.

Secrets of the Fire Swamp
-------------------------

RequireJS has made my heavy-Javascript app dev much more enjoyable.  I don't have to deal with massive, monolithic js files.  Instead, I have lots of little cohesive files, and I have a nice tool that helps me import them where needed.  RequireJS does still have a little bit of mystique for me, however.  The paths can be hit and miss.  Once I find a pattern that seems to work, I stick to it like glue.  And that usually works for me, but as we've seen, once we switch contexts (like into the context of the jasmine test runner), those paths may again be in question.  That's why, as we've seen, you should do the wacking one-off pathing on the test side of things so your app code can remain clean and unchanged.  Eat, test, and be merry.

As more application logic gets pushed into the browser for client-heavy apps, the need for javascript testing increases.  Lately, I've been doing some Jasmi