removing the first pass of Jekyll files
This commit is contained in:
parent
5a4aea156d
commit
225494c82c
|
@ -1,6 +0,0 @@
|
|||
# jekyll configuration
|
||||
|
||||
# miscellaneous configuration
|
||||
title: "Jasmine"
|
||||
|
||||
# end of configuration
|
|
@ -1,52 +0,0 @@
|
|||
<nav>
|
||||
<ul>
|
||||
<li><a href="index.html">Welcome</a></li>
|
||||
<li><a href="download.html">Download</a></li>
|
||||
<li><a href="release-notes.html">Release Notes</a></li>
|
||||
<li>Documentation</li>
|
||||
<ul>
|
||||
<li><a href="user-guide.html">User Guide</a></li>
|
||||
<li><a href="background.html">Background</a></li>
|
||||
<li><a href="suites-and-specs.html">Suites and Specs</a></li>
|
||||
<li><a href="matchers.html">Matchers</a></li>
|
||||
<li><a href="before-and-after.html">Before and After</a></li>
|
||||
<li><a href="spies.html">Spies</a></li>
|
||||
<li><a href="async.html">Asynchronous Specs</a></li>
|
||||
</ul>
|
||||
<li><a href="gem.html">Using the Jasmine Gem</a></li>
|
||||
<li><a href="jsdoc/index.html">API Documentation</a></li>
|
||||
<li><a href="http://github.com/pivotal/jasmine#README">Contributor Guide</a></li>
|
||||
<li><a href="related.html">Related Projects</a></li>
|
||||
<li><a href="whos-using-jasmine.html">Who's Using Jasmine</a></li>
|
||||
</ul>
|
||||
</nav>
|
||||
<script>
|
||||
new TWTR.Widget({
|
||||
version: 2,
|
||||
type: 'profile',
|
||||
rpp: 10,
|
||||
interval: 6000,
|
||||
width: 250,
|
||||
height: 300,
|
||||
theme: {
|
||||
shell: {
|
||||
background: '#333333',
|
||||
color: '#ffffff'
|
||||
},
|
||||
tweets: {
|
||||
background: '#e4e4e2',
|
||||
color: '#444444',
|
||||
links: '#216604'
|
||||
}
|
||||
},
|
||||
features: {
|
||||
scrollbar: false,
|
||||
loop: false,
|
||||
live: true,
|
||||
hashtags: true,
|
||||
timestamp: true,
|
||||
avatars: true,
|
||||
behavior: 'all'
|
||||
}
|
||||
}).render().setUser('jasminebdd').start();
|
||||
</script>
|
150
async.html.md
150
async.html.md
|
@ -1,150 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Asynchronous Specs
|
||||
---
|
||||
|
||||
### Asynchronous Specs
|
||||
|
||||
You may be thinking, "That's all very nice, but what's this about asynchronous tests?"
|
||||
|
||||
Well, say you need to make a call that is asynchronous - an AJAX API, event callback, or some other JavaScript library. That is, the call returns immediately, yet you want to make expectations 'at some point in the future' after some magic happens in the background.
|
||||
|
||||
Jasmine allows you to do this with `runs()`, `waits()` and `waitsFor()` blocks.
|
||||
|
||||
#### `runs(function)`
|
||||
|
||||
`runs()` blocks by themselves simply run as if they were called directly. The following snippets of code provide similar results:
|
||||
|
||||
{% highlight javascript %}
|
||||
it('should be a test', function () {
|
||||
var foo = 0
|
||||
foo++;
|
||||
|
||||
expect(foo).toEqual(1);
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
and
|
||||
|
||||
{% highlight javascript %}
|
||||
it('should be a test', function () {
|
||||
runs( function () {
|
||||
var foo = 0
|
||||
foo++;
|
||||
|
||||
expect(foo).toEqual(1);
|
||||
});
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
Multiple `runs()` blocks in a spec will run serially. For example,
|
||||
|
||||
{% highlight javascript %}
|
||||
it('should be a test', function () {
|
||||
runs( function () {
|
||||
var foo = 0
|
||||
foo++;
|
||||
|
||||
expect(foo).toEqual(1);
|
||||
});
|
||||
runs( function () {
|
||||
var bar = 0
|
||||
bar++;
|
||||
|
||||
expect(bar).toEqual(1);
|
||||
});
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
`runs()` blocks share functional scope -- `this` properties will be common to all blocks, but declared `var`'s will not!
|
||||
|
||||
{% highlight javascript %}
|
||||
it('should be a test', function () {
|
||||
runs( function () {
|
||||
this.foo = 0
|
||||
this.foo++;
|
||||
var bar = 0;
|
||||
bar++;
|
||||
|
||||
expect(this.foo).toEqual(1);
|
||||
expect(bar).toEqual(1);
|
||||
});
|
||||
runs( function () {
|
||||
this.foo++;
|
||||
var bar = 0
|
||||
bar++;
|
||||
|
||||
expect(foo).toEqual(2);
|
||||
expect(bar).toEqual(1);
|
||||
});
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
#### `waits(timeout)`
|
||||
|
||||
`runs()` blocks exist so you can test asynchronous processes. The function `waits()` works with `runs()` to provide a naive
|
||||
timeout before the next block is run. You supply a time to wait before the next `runs()` function is executed. For example:
|
||||
|
||||
{% highlight javascript %}
|
||||
it('should be a test', function () {
|
||||
runs(function () {
|
||||
this.foo = 0;
|
||||
var that = this;
|
||||
setTimeout(function () {
|
||||
that.foo++;
|
||||
}, 250);
|
||||
});
|
||||
|
||||
runs(function () {
|
||||
expect(this.foo).toEqual(0);
|
||||
});
|
||||
|
||||
waits(500);
|
||||
|
||||
runs(function () {
|
||||
expect(this.foo).toEqual(1);
|
||||
});
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
What's happening here?
|
||||
|
||||
* The first call to `runs()` sets call for 1/4 of a second in the future that increments `this.foo`.
|
||||
* The second `runs()` is executed immediately and then verifies that `this.foo` was indeed initialized to zero in the previous `runs()`.
|
||||
* Then we wait for half a second.
|
||||
* Then the last call to `runs()` expects that `this.foo` was incremented by the `setTimeout`.
|
||||
|
||||
`waits()` allows you to pause the spec for a fixed period of time, in order to give your code the opportunity to perform
|
||||
some other operation. But what if you don't know exactly how long you need to wait?
|
||||
|
||||
#### `waitsFor(function, optional message, optional timeout)`
|
||||
|
||||
`waitsFor()` provides a better interface for pausing your spec until some other work has completed. Jasmine will wait until
|
||||
the provided function returns `true` before continuing with the next block. This may mean waiting an arbitrary period of
|
||||
time, or you may specify a maxiumum period in milliseconds before timing out:
|
||||
|
||||
{% highlight javascript %}
|
||||
describe('Spreadsheet', function() {
|
||||
it('should calculate the total asynchronously', function () {
|
||||
var spreadsheet = new Spreadsheet();
|
||||
spreadsheet.fillWith(lotsOfFixureDataValues());
|
||||
spreadsheet.asynchronouslyCalculateTotal();
|
||||
|
||||
waitsFor(function() {
|
||||
return spreadsheet.calculationIsComplete();
|
||||
}, "Spreadsheet calculation never completed", 10000);
|
||||
|
||||
runs(function () {
|
||||
expect(spreadsheet.total).toEqual(123456);
|
||||
});
|
||||
});
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
In this example, we create a spreadsheet and fill it with some sample data. We then ask the spreadsheet to start calculating
|
||||
its total, which presumably is a slow operation and therefore happens asynchronously. We ask Jasmine to wait until the
|
||||
spreadsheet's calculation work is complete (or up to 10 seconds, whichever comes first) before continuing with the rest of
|
||||
the spec. If the calculation finishes within the allotted 10 seconds, Jasmine continues on to the final `runs()` block, where
|
||||
it validates the calculation. If the spreadsheet hasn't finished calculations within 10 seconds, the spec stops and reports
|
||||
a spec failure with the message given in the `waitsFor()` block.
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Background & History
|
||||
---
|
||||
|
||||
# Why Another JavaScript TDD/BDD Framework?
|
||||
|
||||
There are some great JavaScript testing frameworks out there already, so why did we write another?
|
||||
|
||||
None of the existing frameworks quite worked the way we wanted. Many only work from within a browser. Most don't support testing asynchronous code like event callbacks. Some have syntax that's hard for JS developers or IDEs to understand.
|
||||
|
||||
So we decided to start from scratch.
|
||||
|
||||
# Enter Jasmine
|
||||
|
||||
Jasmine is our dream JavaScript testing framework. It's heavily influenced by, and borrows the best parts of, ScrewUnit, JSSpec, [JSpec](http://github.com/visionmedia/jspec/tree/master), and of course RSpec.
|
||||
|
||||
Jasmine was designed with a few principles in mind. We believe that a good JavaScript testing framework:
|
||||
|
||||
* should not be tied to any browser, framework, platform, or host language.
|
||||
* should have idiomatic and unsurprising syntax.
|
||||
* should work anywhere JavaScript can run, including browsers, servers, phones, etc.
|
||||
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
|
||||
* should play well with IDEs (e.g. test code should pass static analysis).
|
||||
|
||||
Some of our goals while writing Jasmine:
|
||||
|
||||
* it should encourage good testing practices.
|
||||
* it should integrate easily with continuous build systems.
|
||||
* it should be simple to get started with.
|
||||
|
||||
The result is Jasmine, and we love test-driving our code with it. Enjoy.
|
|
@ -1,101 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Before and After a Spec
|
||||
---
|
||||
|
||||
#### beforeEach
|
||||
|
||||
A suite can have a `beforeEach()` declaration. It takes a function that is run before each spec. For example:
|
||||
|
||||
{% highlight javascript %}
|
||||
describe('some suite', function () {
|
||||
var suiteWideFoo;
|
||||
|
||||
beforeEach(function () {
|
||||
suiteWideFoo = 1;
|
||||
});
|
||||
|
||||
it('should equal bar', function () {
|
||||
expect(suiteWideFoo).toEqual(1);
|
||||
});
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
A runner can also have `beforeEach()` declarations. Runner `beforeEach()` functions are executed before every spec in all suites, and execute BEFORE suite `beforeEach()` functions. For example:
|
||||
|
||||
{% highlight javascript %}
|
||||
var runnerWideFoo = [];
|
||||
|
||||
beforeEach(function () {
|
||||
runnerWideFoo.push('runner');
|
||||
});
|
||||
|
||||
describe('some suite', function () {
|
||||
beforeEach(function () {
|
||||
runnerWideFoo.push('suite');
|
||||
});
|
||||
|
||||
it('should equal bar', function () {
|
||||
expect(runnerWideFoo).toEqual(['runner', 'suite']);
|
||||
});
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
#### afterEach
|
||||
|
||||
Similarly, there is an `afterEach()` declaration. It takes a function that is run after each spec. For example:
|
||||
|
||||
{% highlight javascript %}
|
||||
describe('some suite', function () {
|
||||
var suiteWideFoo;
|
||||
afterEach(function () {
|
||||
suiteWideFoo = 0;
|
||||
});
|
||||
|
||||
it('should equal 1', function () {
|
||||
expect(suiteWideFoo).toEqual(1);
|
||||
});
|
||||
|
||||
it('should equal 0 after', function () {
|
||||
expect(suiteWideFoo).toEqual(0);
|
||||
};
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
A runner can also have an `afterEach()` declarations. Runner `afterEach()` functions are executed after every spec in all suites, and execute AFTER suite `afterEach()` functions. For example:
|
||||
|
||||
{% highlight javascript %}
|
||||
var runnerWideFoo = [];
|
||||
|
||||
afterEach(function () {
|
||||
runnerWideFoo.push('runner');
|
||||
});
|
||||
|
||||
describe('some suite', function () {
|
||||
afterEach(function () {
|
||||
runnerWideFoo.push('suite');
|
||||
});
|
||||
|
||||
it('should be empty', function () {
|
||||
expect(runnerWideFoo).toEqual([]);
|
||||
});
|
||||
|
||||
it('should be populated after', function () {
|
||||
expect(runnerWideFoo).toEqual(['suite', 'runner']);
|
||||
};
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
### Single-spec After functions
|
||||
|
||||
A spec may ask Jasmine to execute some code after the spec has finished running; the code will run whether the spec finishes successfully or not. Multiple after functions may be given.
|
||||
|
||||
{% highlight javascript %}
|
||||
describe('some suite', function () {
|
||||
it(function () {
|
||||
var originalTitle = window.title;
|
||||
this.after(function() { window.title = originalTitle; });
|
||||
MyWindow.setTitle("new value");
|
||||
expect(window.title).toEqual("new value");
|
||||
});
|
||||
{% endhighlight %}
|
81
gem.html.md
81
gem.html.md
|
@ -1,81 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Using the Jasmine Gem
|
||||
---
|
||||
It's easy to integrate Jasmine with your Ruby project.
|
||||
|
||||
## Setup ##
|
||||
|
||||
### For Rails 2 projects ###
|
||||
|
||||
Install the Jasmine gem, add example specs to your project, and run them:
|
||||
{% highlight sh %}
|
||||
$ gem install jasmine
|
||||
$ script/generate jasmine
|
||||
$ rake spec
|
||||
{% endhighlight %}
|
||||
|
||||
### For Rails 3 projects ###
|
||||
|
||||
Add jasmine to your Gemfile:
|
||||
{% highlight ruby %}
|
||||
gem "jasmine"
|
||||
{% endhighlight %}
|
||||
|
||||
Then update your gems, add example specs to your project, and run them:
|
||||
{% highlight sh %}
|
||||
$ bundle install
|
||||
$ bundle exec jasmine init
|
||||
{% endhighlight %}
|
||||
|
||||
Better Rails 3/RSpec 2 support is coming soon!
|
||||
|
||||
### For other Ruby projects ###
|
||||
|
||||
Install the Jasmine gem, create an example project, and run your specs:
|
||||
|
||||
{% highlight sh %}
|
||||
$ gem install jasmine
|
||||
$ jasmine init
|
||||
$ rake jasmine:ci
|
||||
{% endhighlight %}
|
||||
|
||||
## Running specs ##
|
||||
|
||||
The Jasmine gem provides two Rake tasks:
|
||||
|
||||
{% highlight sh %}
|
||||
$ rake jasmine
|
||||
{% endhighlight %}
|
||||
|
||||
This task starts a server which you can connect to through your browser and interactively run specs.
|
||||
|
||||
{% highlight sh %}
|
||||
$ rake jasmine:ci
|
||||
{% endhighlight %}
|
||||
|
||||
This task runs your Jasmine specs automatically (by launching Firefox, by default) and reports the result.
|
||||
|
||||
When used with Rails 2, Jasmine gem creates a special RSpec spec which runs all your JavaScript specs and reports the
|
||||
results as though they were Ruby specs. If you use a compatible IDE (such as RubyMine), you can navigate to the
|
||||
JavaScript source for your specs directly from the spec runner interface.
|
||||
|
||||
## CI/build integration ##
|
||||
|
||||
The Jasmine gem makes it easy to include your Jasmine specs in your continuous integration build. If you are using
|
||||
Rails 2, your Jasmine specs will automatically be included with other specs. Otherwise, you can explicitly run your
|
||||
Jasmine specs like this:
|
||||
|
||||
{% highlight sh %}
|
||||
$ rake jasmine:ci
|
||||
{% endhighlight %}
|
||||
|
||||
## Configuration ##
|
||||
|
||||
Customize spec/javascripts/support/jasmine.yml to enumerate the source files, stylesheets, and spec files you would
|
||||
like the Jasmine runner to include. You may use dir glob strings.
|
||||
|
||||
## Runner ##
|
||||
|
||||
The Jasmine gem currently uses Selenium to launch a browser (Firefox by default) in order to run your specs. In the
|
||||
future, we'll provide other options for running your specs.
|
60
matchers.md
60
matchers.md
|
@ -1,60 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Matchers
|
||||
---
|
||||
|
||||
### Expectation Matchers
|
||||
|
||||
Jasmine has several built-in matchers. Here are a few:
|
||||
|
||||
>`expect(x).toEqual(y);` compares objects or primitives `x` and `y` and passes if they are equivalent
|
||||
>
|
||||
>`expect(x).toBe(y);` compares objects or primitives `x` and `y` and passes if they are the same object
|
||||
>
|
||||
>`expect(x).toMatch(pattern);` compares `x` to string or regular expression `pattern` and passes if they match
|
||||
>
|
||||
>`expect(x).toBeDefined();` passes if `x` is not `undefined`
|
||||
>
|
||||
>`expect(x).toBeNull();` passes if `x` is `null`
|
||||
>
|
||||
>`expect(x).toBeTruthy();` passes if `x` evaluates to true
|
||||
>
|
||||
>`expect(x).toBeFalsy();` passes if `x` evaluates to false
|
||||
>
|
||||
>`expect(x).toContain(y);` passes if array or string `x` contains `y`
|
||||
>
|
||||
>`expect(x).toBeLessThan(y);` passes if `x` is less than `y`
|
||||
>
|
||||
>`expect(x).toBeGreaterThan(y);` passes if `x` is greater than `y`
|
||||
>
|
||||
>`expect(fn).toThrow(e);` passes if function `fn` throws exception `e` when executed
|
||||
|
||||
<small>The old matchers `toNotEqual`, `toNotBe`, `toNotMatch`, and `toNotContain` have been deprecated and will be removed in a future release. Please change your specs to use `not.toEqual`, `not.toBe`, `not.toMatch`, and `not.toContain` respectively.</small>
|
||||
|
||||
Every matcher's criteria can be inverted by prepending `.not`:
|
||||
|
||||
>`expect(x).not.toEqual(y);` compares objects or primitives `x` and `y` and passes if they are *not* equivalent
|
||||
|
||||
#### Writing New Matchers
|
||||
|
||||
We've provided a small set of matchers that cover many common situations. However, we recommend that you write custom matchers when you want to assert a more specific sort of expectation. Custom matchers help to document the intent of your specs, and can help to remove code duplication in your specs.
|
||||
|
||||
It's extremely easy to create new matchers for your app. A matcher function receives the actual value as `this.actual`, and zero or more arguments may be passed in the function call. The function should return `true` if the actual value passes the matcher's requirements, and `false` if it does not.
|
||||
|
||||
Here's the definition of `toBeLessThan()`:
|
||||
|
||||
{% highlight javascript %}
|
||||
toBeLessThan: function(expected) {
|
||||
return this.actual < expected;
|
||||
};
|
||||
{% endhighlight %}
|
||||
|
||||
To add the matcher to your suite, call `this.addMatchers()` from within a `before` or `it` block. Call it with an object mapping matcher name to function:
|
||||
|
||||
{% highlight javascript %}
|
||||
beforeEach(function() {
|
||||
this.addMatchers({
|
||||
toBeVisible: function() { return this.actual.isVisible(); }
|
||||
});
|
||||
});
|
||||
{% endhighlight %}
|
|
@ -1,58 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Related Projects
|
||||
---
|
||||
|
||||
# Related Projects
|
||||
|
||||
----
|
||||
|
||||
[jasmine-ajax](http://github.com/pivotal/jasmine-ajax)
|
||||
> AJAX mocking for Jasmine.
|
||||
|
||||
[jasmine-dom](https://github.com/jeffwatkins/jasmine-dom)
|
||||
> This add-on provides a set of custom matchers for working with DOM nodes and an API for handling HTML fixtures in your spec.
|
||||
|
||||
[jasmine-iphone](http://github.com/pivotal/jasmine-iphone)
|
||||
> Use Jasmine to drive your iPhone UI Automation tests.
|
||||
|
||||
[jasmine-jstd-adapter](http://github.com/ibolmo/jasmine-jstd-adapter)
|
||||
> Jasmine adapter for JsTestDriver.
|
||||
|
||||
[jasmine-jquery](http://github.com/velesin/jasmine-jquery)
|
||||
> jasmine-jquery provides extensions for Jasmine to support the jQuery framework and an API for handling HTML fixtures in your specs.
|
||||
|
||||
[jasmine-maven-plugin](http://github.com/searls/jasmine-maven-plugin)
|
||||
> A Maven Plugin for processing JavaScript sources, specs, and executing Jasmine.
|
||||
|
||||
[jasmine-node](http://github.com/mhevery/jasmine-node)
|
||||
> Makes Jasmine available in node.js.
|
||||
|
||||
[jasmine-reporters](http://github.com/larrymyers/jasmine-reporters)
|
||||
> A collection of jasmine.Reporter classes that can be used with Jasmine.
|
||||
|
||||
[Jasmine Species](http://rudylattae.github.com/jasmine-species/) [[repo](https://github.com/rudylattae/jasmine-species)]
|
||||
> Provides extended BDD grammar and reporting for Jasmine. It allows for constructs like "Feature -> Scenario", "Given -> When -> Then" and other useful BDD styles.
|
||||
|
||||
[jasmine-tmbundle](http://github.com/pivotal/jasmine-tmbundle)
|
||||
> A TextMate bundle for the Jasmine JavaScript BDD Framework.
|
||||
|
||||
[jasmine-webos](http://pivotal.github.com/jasmine-webos/)
|
||||
> Jasmine webOS allows you to use Jasmine to test-drive Palm® webOS™ applications.
|
||||
|
||||
[jazz_money](http://github.com/pivotalexperimental/jazz_money)
|
||||
> Run your Jasmine specs without a browser.
|
||||
|
||||
[mootools-runner](http://github.com/mootools/mootools-runner)
|
||||
> The MooTools Specs runner uses Jasmine as a UnitTest-Library; it is possible to run specs via the browser, via JSTestDriver and via NodeJS.
|
||||
|
||||
[Webr](http://github.com/thatdutchguy/webr)
|
||||
> Headless javascript testing using jasmine, v8, jsdom and node-htmlparser.
|
||||
|
||||
[vim snippets](http://www.vim.org/scripts/script.php?script_id=3249)
|
||||
> A set of Vim snipMate snippets for Jasmine
|
||||
|
||||
----
|
||||
|
||||
If you'd like your project added, email <a href="mailto:jasmine-js@googlegroups.com">jasmine-js@googlegroups.com</a>.
|
||||
Please include your project's name, a brief description, and web site/repository urls. We reserve the right to edit.
|
|
@ -1,134 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Release Notes
|
||||
---
|
||||
|
||||
# Release Notes
|
||||
|
||||
-----
|
||||
## Release 1.0.1.1 — November 9, 2010
|
||||
-----
|
||||
|
||||
### Jasmine Gem
|
||||
|
||||
#### Bugs fixed
|
||||
<ul>
|
||||
<li>Rails 3.0 and RSpec 2.0 are now supported.</li>
|
||||
</ul>
|
||||
|
||||
#### Known issues
|
||||
<ul>
|
||||
<li>Rails 3 generators are not yet implemented -- coming soon!</li>
|
||||
</ul>
|
||||
|
||||
-----
|
||||
## Release 1.0.1 — October 5, 2010
|
||||
-----
|
||||
|
||||
### Jasmine Core
|
||||
|
||||
#### Bugs fixed
|
||||
<ul>
|
||||
<li>Bug fixes for Internet Explorer (thanks fschwiet, fabiomcosta, and jfirebaugh).</li>
|
||||
</ul>
|
||||
|
||||
### Jasmine Gem
|
||||
|
||||
#### Bugs fixed
|
||||
<ul>
|
||||
<li>Bug fix for Windows (thanks jfirebaugh).</li>
|
||||
</ul>
|
||||
|
||||
-----
|
||||
## Release 1.0 — September 14, 2010
|
||||
-----
|
||||
|
||||
### Jasmine Core
|
||||
|
||||
#### Features
|
||||
<ul>
|
||||
<li><code>waitsFor()</code> arguments can now be specified in any order. Timeout and message are optional.</li>
|
||||
<li>The default <code>waitsFor()</code> timeout period is now specified in <code>env.defaultTimeoutInterval</code>; the default value is 5 seconds.</li>
|
||||
<li>Added link to jasmine site from html runner.</li>
|
||||
<li>Added license file to standalone distribution.</li>
|
||||
<li>New friendly version number.</li>
|
||||
</ul>
|
||||
|
||||
#### Bugs fixed
|
||||
<ul>
|
||||
<li><code>waitsFor()</code> hanged forever if latch function never returned true.</li>
|
||||
<li>The <code>not.toThrow()</code> matcher threw an exception when used with no args.</li>
|
||||
<li>The <code>toThrow()</code> matcher, when inverted, gave misleading failure messages.</li>
|
||||
<li>Spy matchers, when inverted, gave misleading failure messages.</li>
|
||||
</ul>
|
||||
|
||||
#### Deprecations
|
||||
<ul>
|
||||
<li>Deprecated <code>waits()</code> block in favor of <code>waitsFor()</code>; <code>waits()</code> will be removed in a future release.</li>
|
||||
<li>Deprecated <code>toNotBe()</code>, <code>toNotEqual()</code>, <code>toNotMatch()</code>, and <code>toNotContain()</code> matchers; they will be removed in a future release.</li>
|
||||
<li>Console X was removed from the distribution as it was no longer used.</li>
|
||||
<li>To give us some flexibility for future features, wrapped matcher functions now return <code>undefined</code> (they previously returned <code>true</code> or <code>false</code>, but this was undocumented).</li>
|
||||
</ul>
|
||||
|
||||
### Jasmine Gem
|
||||
|
||||
#### Features
|
||||
<ul>
|
||||
<li>Jasmine now supports JRuby.</li>
|
||||
<li>Jasmine now supports Ruby 1.9.</li>
|
||||
</ul>
|
||||
|
||||
#### Bugs fixed
|
||||
<ul>
|
||||
<li>Various generator issues fixed.</li>
|
||||
</ul>
|
||||
|
||||
#### Known issues
|
||||
<ul>
|
||||
<li>Rails 3 and RSpec 2 are not yet fully supported.</li>
|
||||
</ul>
|
||||
|
||||
-----
|
||||
## Release 0.11.1 — June 25, 2010
|
||||
-----
|
||||
|
||||
### Jasmine Core
|
||||
|
||||
##### Features
|
||||
<ul>
|
||||
<li>Jasmine no longer logs "Jasmine Running…" messages to the log by default. This can be enabled in runner.html by adding 'trivialReporter.logRunningSpecs = true;'.</li>
|
||||
<li>The <code>wasCalled()</code>, <code>wasCalledWith()</code>, <code>wasNotCalled()</code> and <code>wasNotCalledWith()</code> matchers have been deprecated. The new matchers <code>toHaveBeenCalled()</code> and <code>toHaveBeenCalledWith()</code> have been added. You can use the <code>not</code> prefix to achieve equivalent of the <code>wasNot…()</code> expectation (e.g. <code>not.toHaveBeenCalled()</code>).</li>
|
||||
</ul>
|
||||
|
||||
#### Notables
|
||||
<ul>
|
||||
<li>A barebones version of Jasmine is now available on <a href="http://pivotal.github.com/jasmine/">http://pivotal.github.com/jasmine/</a>.</li>
|
||||
</ul>
|
||||
|
||||
-----
|
||||
## Release 0.11.0 — June 23, 2010
|
||||
-----
|
||||
### Jasmine Core
|
||||
|
||||
#### Features
|
||||
<ul>
|
||||
<li>The version number has been removed from the generated single-file /lib/jasmine.js. We're also now uploading this file, with the version number in the filename, to github's Downloads page.</li>
|
||||
<li>Old-style matchers (those using this.report(), from before 0.10.x) are no longer supported. See the <span class="caps">README</span> for instructions on writing new-style matchers.</li>
|
||||
<li><strong>jasmine.log</strong> pretty-prints its parameters to the spec's output.</li>
|
||||
<li>Jasmine no longer depends on 'window'.</li>
|
||||
<li><span class="caps">HTML</span> runner should show number of passes/fails by spec, not expectation.</li>
|
||||
<li>Small modification to JsApiReporter data format.</li>
|
||||
</ul>
|
||||
|
||||
#### Bugs fixed:
|
||||
<ul>
|
||||
<li>If multiple beforeEach blocks were declared, they were executed in reverse order.</li>
|
||||
<li>Specs with duplicate names confused TrivialReporter output.</li>
|
||||
<li>Errors in describe functions caused later tests to be weirdly nested.</li>
|
||||
<li>Nested specs weren't reported properly by the JsApiReporter.</li>
|
||||
</ul>
|
||||
|
||||
#### Known issues:
|
||||
<ul>
|
||||
<li>If you turn on the mock clock, you'll get a spurious log message at the end of your spec.</li>
|
||||
</ul>
|
116
spies.html.md
116
spies.html.md
|
@ -1,116 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Spies
|
||||
---
|
||||
|
||||
### Spies
|
||||
|
||||
Jasmine integrates 'spies' that permit many spying, mocking, and faking behaviors.
|
||||
|
||||
Here are a few examples:
|
||||
|
||||
{% highlight javascript %}
|
||||
var Klass = function () {
|
||||
};
|
||||
|
||||
Klass.staticMethod = function (arg) {
|
||||
return arg;
|
||||
};
|
||||
|
||||
Klass.prototype.method = function (arg) {
|
||||
return arg;
|
||||
};
|
||||
|
||||
Klass.prototype.methodWithCallback = function (callback) {
|
||||
return callback('foo');
|
||||
};
|
||||
|
||||
...
|
||||
|
||||
describe("spy behavior", function() {
|
||||
it('should spy on a static method of Klass', function() {
|
||||
spyOn(Klass, 'staticMethod');
|
||||
Klass.staticMethod('foo argument');
|
||||
|
||||
expect(Klass.staticMethod).toHaveBeenCalledWith('foo argument');
|
||||
});
|
||||
|
||||
it('should spy on an instance method of a Klass', function() {
|
||||
var obj = new Klass();
|
||||
spyOn(obj, 'method');
|
||||
obj.method('foo argument');
|
||||
|
||||
expect(obj.method).toHaveBeenCalledWith('foo argument');
|
||||
|
||||
var obj2 = new Klass();
|
||||
spyOn(obj2, 'method');
|
||||
expect(obj2.method).not.toHaveBeenCalled();
|
||||
});
|
||||
|
||||
it('should spy on Klass#methodWithCallback', function() {
|
||||
var callback = jasmine.createSpy();
|
||||
new Klass().methodWithCallback(callback);
|
||||
|
||||
expect(callback).toHaveBeenCalledWith('foo');
|
||||
});
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
Spies can be very useful for testing AJAX or other asynchronous behaviors that take callbacks by faking the method firing an async call.
|
||||
|
||||
{% highlight javascript %}
|
||||
var Klass = function () {
|
||||
};
|
||||
|
||||
var Klass.prototype.asyncMethod = function (callback) {
|
||||
someAsyncCall(callback);
|
||||
};
|
||||
|
||||
...
|
||||
|
||||
it('should test async call') {
|
||||
spyOn(Klass, 'asyncMethod');
|
||||
var callback = jasmine.createSpy();
|
||||
|
||||
Klass.asyncMethod(callback);
|
||||
expect(callback).not.toHaveBeenCalled();
|
||||
|
||||
var someResponseData = 'foo';
|
||||
Klass.asyncMethod.mostRecentCall.args[0](someResponseData);
|
||||
expect(callback).toHaveBeenCalledWith(someResponseData);
|
||||
|
||||
});
|
||||
{% endhighlight %}
|
||||
|
||||
There are spy-specfic matchers that are very handy.
|
||||
|
||||
`expect(x).toHaveBeenCalled()` passes if `x` is a spy and was called
|
||||
|
||||
`expect(x).toHaveBeenCalledWith(arguments)` passes if `x` is a spy and was called with the specified arguments
|
||||
|
||||
`expect(x).not.toHaveBeenCalled()` passes if `x` is a spy and was not called
|
||||
|
||||
`expect(x).not.toHaveBeenCalledWith(arguments)` passes if `x` is a spy and was not called with the specified arguments
|
||||
|
||||
<small>The old matchers `wasCalled`, `wasNotCalled`, `wasCalledWith`, and `wasNotCalledWith` have been deprecated and will be removed in a future release. Please change your specs to use `toHaveBeenCalled`, `not.toHaveBeenCalled`, `toHaveBeenCalledWith`, and `not.toHaveBeenCalledWith` respectively.</small>
|
||||
|
||||
Spies can be trained to respond in a variety of ways when invoked:
|
||||
|
||||
`spyOn(x, 'method').andCallThrough()`: spies on AND calls the original function spied on
|
||||
|
||||
`spyOn(x, 'method').andReturn(arguments)`: returns passed arguments when spy is called
|
||||
|
||||
`spyOn(x, 'method').andThrow(exception)`: throws passed exception when spy is called
|
||||
|
||||
`spyOn(x, 'method').andCallFake(function)`: calls passed function when spy is called
|
||||
|
||||
Spies have some useful properties:
|
||||
|
||||
`callCount`: returns number of times spy was called
|
||||
|
||||
`mostRecentCall.args`: returns argument array from last call to spy.
|
||||
|
||||
`argsForCall[i]` returns arguments array for call `i` to spy.
|
||||
|
||||
Spies are automatically removed after each spec. They may be set in the beforeEach function.
|
||||
|
|
@ -1,96 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Suites & Specs
|
||||
---
|
||||
|
||||
## Specs
|
||||
|
||||
Each spec is, naturally, a JavaScript function. You tell Jasmine about a spec with a call to `it()` with a description string and the function. The string is a description of a behavior that you want your production code to exhibit; it should be meaningful to you when reading a report.
|
||||
|
||||
it('should increment a variable', function () {
|
||||
var foo = 0;
|
||||
foo++;
|
||||
});
|
||||
|
||||
## Expectations
|
||||
|
||||
Within your spec you will express expectations about the behavior of your application code. This is done using the `expect()` function and any of various expectation matchers, like this:
|
||||
|
||||
it('should increment a variable', function () {
|
||||
var foo = 0; // set up the world
|
||||
foo++; // call your application code
|
||||
|
||||
expect(foo).toEqual(1); // passes because foo == 1
|
||||
});
|
||||
|
||||
Results of the expectations will be reported to you when the spec is run.
|
||||
|
||||
### Suites
|
||||
|
||||
Specs are grouped in Suites. Suites are defined using the global `describe()` function:
|
||||
|
||||
describe('Calculator', function () {
|
||||
it('can add a number', function () {
|
||||
...
|
||||
});
|
||||
|
||||
it('has multiply some numbers', function () {
|
||||
...
|
||||
});
|
||||
});
|
||||
|
||||
The Suite name is typically the name of a class or other applicaton component, and will be reported with results when your specs are run.
|
||||
|
||||
Suites are executed in the order in which `describe()` calls are made, usually in the order in which their script files are included. Additionally, specs within a suite share a functional scope. So you may declare variables inside a describe block and they are accessible from within your specs. For example:
|
||||
|
||||
describe('Calculator', function () {
|
||||
var counter = 0
|
||||
|
||||
it('can add a number', function () {
|
||||
counter = counter + 2; // counter was 0 before
|
||||
expect(bar).toEqual(2);
|
||||
});
|
||||
|
||||
it('can multiply a number', function () {
|
||||
counter = counter * 5; // counter was 2 before
|
||||
expect(bar).toEqual(10);
|
||||
});
|
||||
});
|
||||
|
||||
Be aware that code directly inside the `describe()` function is only executed once, which is why `counter` in the above example is not reset to `0` for the second spec. If you want to initialize variables before each spec, use a `beforeEach()` function.
|
||||
|
||||
### Nested Describes
|
||||
|
||||
Jasmine supports nested describes. An example:
|
||||
|
||||
describe('some suite', function () {
|
||||
|
||||
var suiteWideFoo;
|
||||
|
||||
beforeEach(function () {
|
||||
suiteWideFoo = 0;
|
||||
});
|
||||
|
||||
describe('some nested suite', function() {
|
||||
var nestedSuiteBar;
|
||||
beforeEach(function() {
|
||||
nestedSuiteBar=1;
|
||||
});
|
||||
|
||||
it('nested expectation', function () {
|
||||
expect(suiteWideFoo).toEqual(0);
|
||||
expect(nestedSuiteBar).toEqual(1);
|
||||
});
|
||||
|
||||
});
|
||||
|
||||
it('top-level describe', function () {
|
||||
expect(suiteWideFoo).toEqual(0);
|
||||
expect(nestedSuiteBar).toEqual(undefined);
|
||||
});
|
||||
});
|
||||
|
||||
### Disabling Tests & Suites
|
||||
|
||||
Specs may be disabled by calling `xit()` instead of `it()`. Suites may be disabled by calling `xdescribe()` instead of `describe()`.
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: User Guide
|
||||
---
|
||||
|
||||
# Quick Start
|
||||
|
||||
## For JavaScript-only projects:
|
||||
1. Get the latest standalone release from the [downloads page](index.html).
|
||||
2. Open `SpecRunner.html` in your favorite browser.
|
||||
|
||||
## Other distributions:
|
||||
* For integration with the Ruby environment, including automated execution with Selenium, please use the [jasmine gem](gem.html).
|
||||
|
||||
# Which Release Should I Use?
|
||||
|
||||
Please use the latest version unless you have a good reason not to. Some of this documentation may not be applicable to older versions. Please see [Release Notes](release-notes.html) for change information.
|
||||
|
||||
## Maintainers
|
||||
* [Davis W. Frank](mailto:dwfrank@pivotallabs.com) ([infews](http://github.com/infews)), Pivotal Labs
|
||||
* [Rajan Agaskar](mailto:rajan@pivotallabs.com) ([ragaskar](http://github.com/ragaskar)), Pivotal Labs
|
||||
* [Christian Williams](mailto:xian@pivotallabs.com) ([Xian](http://github.com/Xian)), Pivotal Labs
|
||||
|
||||
## Developers
|
||||
We welcome your contributions! Just fork the GitHub project ([Jasmine core](http://github.com/pivotal/jasmine) or
|
||||
[Ruby gem](http://github.com/pivotal/jasmine-gem)), and submit a pull request. Lots of extra points if you include
|
||||
tests for your changes!
|
||||
|
||||
## Acknowledgments
|
||||
* A big shout out to the various JavaScript test framework authors, especially TJ for [JSpec](http://github.com/visionmedia/jspec/tree/master) - we played with it a bit before deciding that we really needed to roll our own.
|
||||
* Thanks to Pivot [Jessica Miller](http://www.jessicamillerworks.com/) for our logo and fancy pass/fail/pending icons
|
||||
* Huge contributions have been made by [Adam Abrons](mailto:adam@pivotallabs.com), [Lee Byrd](mailto:lee@pivotallabs.com), [Erik Hanson](mailto:erik@pivotallabs.com), [Carl Jackson](mailto:carl@pivotallabs.com), and many other Pivots.
|
|
@ -1,101 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Related Projects
|
||||
---
|
||||
|
||||
# Who's Using Jasmine?
|
||||
|
||||
----
|
||||
|
||||
## Count it Down
|
||||
|
||||
This is my entry in the 10K Apart Challenge. It is a countdown clock. Enter a clock title and an end date and time and
|
||||
it will count it down for you. It sports smooth clock animations, before specific digits change they will flash red,
|
||||
and you can share your clock w/ friends through a url generated by your title and end date and time.
|
||||
|
||||
Jasmine was essential in this project. First I wrote all the specs for an uncompressed version. When it was time to
|
||||
compress every little bit of code, I updated my specs w/ the renaming and refactoring for a smaller size. It was very
|
||||
intense, for example the Clock class because just 'K' and all the jquery methods were aliased to 'a' or 'rc' or 'x'.
|
||||
Without Jasmine double checking all of my renaming, I would have gone insane.
|
||||
|
||||
-- Roy Kolak
|
||||
|
||||
**web**: [http://10k.aneventapart.com/Entry/165](http://10k.aneventapart.com/Entry/165)
|
||||
| **source**: [http://github.com/roykolak/count-it-down](http://github.com/roykolak/count-it-down)
|
||||
|
||||
----
|
||||
|
||||
## Diaspora
|
||||
|
||||
The privacy aware, personally controlled, do-it-all, open source social network.
|
||||
|
||||
We're currently backfilling specs for existing js (which has been an educational process) and will be TDDing it
|
||||
moving forward.
|
||||
|
||||
-- Sarah Mei
|
||||
|
||||
**web**: [http://www.joindiaspora.com/](http://www.joindiaspora.com/)
|
||||
| **source**: [https://github.com/diaspora/diaspora](https://github.com/diaspora/diaspora)
|
||||
|
||||
----
|
||||
|
||||
## EaselTV
|
||||
|
||||
We're using Jasmine at EaselTV for some JS/HTML based TV apps.
|
||||
|
||||
**web**: [http://easeltv.com/](http://easeltv.com/)
|
||||
|
||||
----
|
||||
|
||||
## Maptini
|
||||
|
||||
Real time collaborative mind mapping for Web, iPhone, & iPad. The web version is all html5 + javascript.
|
||||
|
||||
**web**: [http://maptini.com/](http://maptini.com/)
|
||||
|
||||
----
|
||||
|
||||
## VerticalResponse
|
||||
|
||||
**web**: [http://www.verticalresponse.com/](http://www.verticalresponse.com/)
|
||||
|
||||
----
|
||||
|
||||
## Weplay
|
||||
|
||||
Weplay aims to be the online home of youth sports. Our users are coaches, players, and parents involved in team sports
|
||||
including soccer, football, baseball, cheerleading and more. We provide tools including scheduling, messaging,
|
||||
photo/video sharing and virtual awards, for coaches and parents to organize their team's online presence. Our younger
|
||||
users also use Weplay to engage with their friends, play games, and earn incentives. A vibrant community is also
|
||||
emerging around our offerings for Skills & Drills and Questions & Answers.
|
||||
|
||||
Our platform is built on Ruby and Rails and our development practices are based largely on Agile and behavior driven
|
||||
development. While Cucumber and RSpec have been our primary testing tools for driving our server-side development since
|
||||
our beginning nearly three years ago, we have had to evolve our front-end testing solution. We started with no testing
|
||||
and eventually incorporated Selenium feature testing into our Cucumber build. I've led the efforts to applying
|
||||
test-driven javascript coding practices, originally with ScrewUnit + Screwdriver, then BlueRidge and now Jasmine.
|
||||
|
||||
A recent contribution to our Weplay fork of jasmine is the ability to specify Sprocket-style "require" lines
|
||||
(i.e., <code>//= "public/javascript/awesome.js"</code>) to target src javascript files on a per-spec basis.
|
||||
|
||||
-- Ross Kaffenberger
|
||||
|
||||
**web**: [http://www.weplay.com](http://www.weplay.com)
|
||||
| **source**: [http://github.com/weplay](http://github.com/weplay) *
|
||||
<br/>
|
||||
<small>While our parent project repository is privately hosted, we currently incorporate and contribute to 63 (yikes!)
|
||||
public repositories, including jasmine and jasmine-gem.</small>
|
||||
|
||||
----
|
||||
|
||||
## Wikimedia Foundation Multimedia Usability Project
|
||||
|
||||
Improved uploader tool for Wikimedia Commons.
|
||||
|
||||
**web**: [http://wikimedia.org/](http://wikimedia.org/)
|
||||
| **source**: [http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/UploadWizard/test/](http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/UploadWizard/test/)
|
||||
|
||||
----
|
||||
|
||||
If you'd like your project added, email <a href="mailto:jasmine-js@googlegroups.com">jasmine-js@googlegroups.com</a>.
|
||||
Please include your project's name, a brief description, and web site/repository urls. We reserve the right to edit.
|
Loading…
Reference in New Issue