froots

if (typeof (AC) === "undefined") {
    AC = {}
}
AC.ImageReplacer = Class.create({
    _defaultOptions: {
        listenToSwapView: true,
        filenameRegex: /(.*)(\.[a-z]{3}($|#.*|\?.*))/i,
        filenameInsert: "_☃x",
        ignoreCheck: /(^http:\/\/movies\.apple\.com\/|\/105\/|\/global\/elements\/quicktime\/|_(([2-9]|[1-9][0-9]+)x|nohires)(\.[a-z]{3})($|#.*|\?.*))/i,
        attribute: "data-hires",

froots

// in /src directory

import {kphToMph} from './convert';

class Car {
  constructor(speed) {
    this.speed = speed;
  }

  getSpeedInMph() {

froots

_.chain(myData)
  .flatten()
  .log()
  .reverse()
  .log()
  .filter(function(item) { return item.active; })
  .value();

froots

before_install:
  - "export PHANTOMJS_VERSION=2.1.1"
  - "phantomjs --version"
  - "export PATH=$PWD/travis_phantomjs/phantomjs-$PHANTOMJS_VERSION-linux-x86_64/bin:$PATH"
  - "phantomjs --version"
  - "if [ $(phantomjs --version) != '$PHANTOMJS_VERSION' ]; then rm -rf $PWD/travis_phantomjs; mkdir -p $PWD/travis_phantomjs; fi"
  - "if [ $(phantomjs --version) != '$PHANTOMJS_VERSION' ]; then wget https://github.com/Medium/phantomjs/releases/download/v$PHANTOMJS_VERSION/phantomjs-$PHANTOMJS_VERSION-linux-x86_64.tar.bz2 -O $PWD/travis_phantomjs/phantomjs-$PHANTOMJS_VERSION-linux-x86_64.tar.bz2; fi"
  - "if [ $(phantomjs --version) != '$PHANTOMJS_VERSION' ]; then tar -xvf $PWD/travis_phantomjs/phantomjs-$PHANTOMJS_VERSION-linux-x86_64.tar.bz2 -C $PWD/travis_phantomjs; fi"
  - "phantomjs --version"

froots

export function random(vmin, vmax) {
  return [
    vmin[0] + Math.random() * (vmax[0] - vmin[0]),
    vmin[1] + Math.random() * (vmax[1] - vmin[1])
  ];
}

froots

##Introduction

One definition of unit testing is the process of taking the smallest piece of testable code in an application, isolating it from the remainder of your codebase and determining if it behaves exactly as expected. In this section, we'll be taking a look at how to unit test Backbone applications using a popular JavaScript testing framework called Jasmine.

For an application to be considered 'well'-tested, distinct functionality should ideally have its own separate unit tests where it's tested against the different conditions you expect it to work under. All tests must pass before functionality is considered 'complete'. This allows developers to both modify a unit of code and it's dependencies with a level of confidence about whether these changes have caused any breakage.

As a basic example of unit testing is where a developer may wish to assert whether passing specific values through to a sum function results in the correct output being returned. For an example more relevant to this book,

froots

beforeEach(function() {
  global.fs = require('fs');
  sinon.stub(fs, 'readFileSync').onlyWithArgs('my-file.txt').returns('Contents of file');

  // Then require the module under test, which uses fs.readFileSync() internally
  // require() uses original method with correct calling context
  global.myModule = require('../src/my-module');
});

it('does something with the file', function() {

froots

define([
  "modules/todo",
  "modules/todos"
], function(Todo, Todos) {

  describe("Todo", function() {
    it("should set an attribute", function() {
      var todo = new Todo({ title: "Do washing" });
      expect(todo.get("title")).toEqual("Do washing");
    });

froots

// ----------------------------------------
// /path/to/dependency.js
define(function() {
  return {
    doSomethingWithIt: function() {
      // blah
    }
  };
});

froots

I can only comment on Backbone.js, which as part of a 10-person team I'm currently using for a medium-sized single-page ('enterprisey') web application on the front-end. I would also say that the app is pretty much a read-only experience in that 99% of server requests are simple GET requests. There is a fair amount of data filtering and a bit of complexity in the view (dragging, scrolling, etc) which made us realise that using jQuery and a bunch of plugins alone would result in a big sloppy mess.

We were looking for something that could handle JavaScript routing and history management, as well providing a structure for separating data from the DOM and jQuery. In the future, we are also hoping to create versions for modern mobile browsers without having to re-write the entire application, for example by swapping out jQuery for Zepto.js on iOS devices. On top of all this we wanted something that would stand up to unit and functional testing without being a major pain in the backside (or backbone).

We looked a