We still support IE 10 and 11, but the Node selenium-webdriver has
serious problems with it. Until that's fixed or worked around, IE builds
won't pass. This gets us otherwise green so we can easily see if
anything else is broken.
When using the following code to simulate a node error:
spyOn(process, 'kill').and.throwError({code: 'ESRCH'})
The object passed in will be converted to a string by the Error
constructor and result in '[object Object]' which is not very useful.
This PR changes the ``throwError`` spy strategy to only convert
strings into an Error object, but any other objects which are passed
in will be thrown as is. This means the spy strategy can never emulate
throwing a bare string ``throw 'error'``, but this would be a backward
incompatible change.
This should fix CI, and can be reverted once a new version of
jasmine-browser that contains 33bd0fcb0ba990102dcd846e673d07b11041dd44
has been published.
Use setSpecProperty to attach key/value pairs to spec results that can be
picked up in specialized jasmine reporters. Example use-cases
include:
* Tagging specs with URLs or string-tokens referencing test-plan docs.
* Recording performance information for blocks of JS.
Similarly setSuiteProperty attaches key/value pairs to suite results
Previously, suite duration was always reported as 0 and spec duration
was always reported as null. Suites always used a no-op timer, and
specs set their result.duration after the result had already been sent
to reporters.
Fixes#1676.
Custom object formatters allow users to customize how an object is
stringified in matcher failure messages. This can already be done by
adding a `jasmineToString` method to the objects in question. But
it's not always desirable or possible to do that, particularly when
objects of a given "type" do not inherit from a specific prototype.
For instance, suppose a web service returns a list of foos that are
deserialized from JSON, e.g.:
{ fooId: 42, /* more properties */ }
The only way to define `jasmineToString` on those is by writing code to
add it to each instance at runtime. But a custom object formatter can
recognize that the object it's looking at is a foo and format it
accordingly:
jasmine.addCustomObjectFormatter(function(obj) {
if (typeof obj.fooId !== 'number') {
return undefined;
}
return '[Foo with ID ' + obj.fooId + ']';
});
Unlike `jasmineToString`, custom object formatters are scoped to a
particular spec or suite and don't require any changes to the code
under test.
This will allow us to add support for custom object formatters, which
will be a per-runable resource like custom matchers, by injecting them
into the pretty-printer.
This makes it easier to write high quality matchers and asymmetric equality
testers, and is also a step toward supporting custom object formatters.
Previously, Jasmine passed custom object formatters as the second argument
to matcher factories and as and the second argument to asymmetric equality
testers' `asymmetricMatch` method. Matchers and asymmetric equality testers
were responsible for passing the custom object formatters to methods like
`matchersUtil#equals`:
function toEqual(util, customEqualityTesters) {
return {
compare: function(actual, expected) {
// ...
result.pass = util.equals(actual, expected, customEqualityTesters, diffBuilder);
And:
ArrayContaining.prototype.asymmetricMatch = function(other, customTesters) {
// ...
for (var i = 0; i < this.sample.length; i++) {
var item = this.sample[i];
if (!j$.matchersUtil.contains(other, item, customTesters)) {
return false;
}
}
With this change, that is no longer necessary. Matchers and asymmetric
equality testers can ignore the existence of custom equality testers and
still fully support them:
function toEqual(util) {
return {
compare: function(actual, expected) {
// ...
result.pass = util.equals(actual, expected, diffBuilder);
And:
ArrayContaining.prototype.asymmetricMatch = function(other, matchersUtil) {
// ...
for (var i = 0; i < this.sample.length; i++) {
var item = this.sample[i];
if (!matchersUtil.contains(other, item)) {
return false;
}
}
The old interfaces are still supported, for now, but will be deprecated
in a future commit and removed in the next major release after that.
In addition to making matchers and custom equality testers simpler,
this change sets the stage for adding support for custom object
formatters. Those will be architecturally similar to custom equality
testers, and by injecting a `MatchersUtil` instance everywhere we can
add them without requiring user code to pass them around as used to be
the case with custom object formatters.
* Use Windows instead of Linux so we can get current browsers from Sauce.
* Test against the version of Firefox that corresponds to ESR as well as
latest.
* Test the latest Edge rather than a specific older version.
* Test Safari 8 and 13 instead of 8, 9 and 10. What works in those versions
is likely to work in the ones in between.
Property tests can only run in Node, so they were previously in another
directory that only gets run in Node. Now they're next to the related
non-property tests and marked pending in the browser. This makes it more
likely that a developer who normally only runs tests in the browser will
notice and run them.
* See #1764 from @dubzzz
* Property tests are only run in Node, not browser.
* The Travis build sets JASMINE_LONG_PROPERTY_TESTS to enable much more
thorough (but slow) testing.
When I first saw it(), I was wondering if the name "it" is
an abbreviation of anything. After some search, I finally
realized that the name is only a pronoun. Therefore, I
think it's worthwhile to include it in the documentation.
If the tests only fail on one browser, it's usually IE. So testing
IE first gives us faster feedback in cases where we're actively
watching the Travis build.
Turns this output:
Expected $[0].foo = Object({ a: 4, b: 5 }) to equal <jasmine.objectContaining(Object({ a: 1, c: 3 }))>.
into this:
Expected $[0].foo.a = 4 to equal 1.
Expected $[0].foo.c = undefined to equal 3.
And turns this output:
Expected spy jasmineDone to have been called with:
[ ... snipped very long expected call ]
but actual calls were:
[ ... snipped very long actual call ]
Call 0:
Expected $[0] = Object({ overallStatus: 'failed', totalTime: 1, incompleteReason: undefined, order: Order({ random: true, seed: '88732', sort: Function }), failedExpectations: [ Object({ matcherName: 'toBeResolved', passed: false, message: 'Suite "a suite" ran a "toBeResolved" expectation after it finished.
Did you forget to return or await the result of expectAsync?', error: undefined, errorForStack: Error, actual: [object Promise], expected: [ ], globalErrorType: 'lateExpeztation' }) ], deprecationWarnings: [ ] }) to equal <jasmine.objectContaining(Object({ failedExpectations: [ <jasmine.objectContaining(Object({ passed: false, globalErrorType: 'lateExpectation', message: 'Suite "a suite" ran a "toBeResolved" expectation after it finished.
Did you forget to return or await the result of expectAsync?', matcherName: 'toBeResolved' }))> ] }))>.
into this:
Expected spy jasmineDone to have been called with:
[ ... snipped very long expected call ]
but actual calls were:
[ ... snipped very long actual call ]
Call 0:
Expected $[0].failedExpectations[0].globalErrorType = 'lateExpeztation' to equal 'lateExpectation'.
This makes it easier to see where each failure message begins and ends.
Before:
Some context: a
multiline
message
After:
Some context:
a
multiline
message
It's very easy to forget to `await` or `return` the promise returned
from `expectAsync`. When that happens, the expectation failure will
occur after the spec or suite's result has been reported to reporters,
and the failure will typically not be shown to the user. This change
adds a top-level suite failure in that case, similar to the way we
report unhandled exceptions or promise rejections that occur after the
runable completes. Adding the error at the top level gives us the best
chance of getting in before the set of failures we add it to is sent
to reporters.
See #1752.
PhantomJS is at end of life, and the last version of Selenium that supported
it was 3.6.0, released almost three years ago. We can't test Jasmine against
PhantomJS without pinning key pieces of the project to increasingly outdated
versions of key libraries.
If the actual value of a test was a string, this was matching against arrays
that contained the strings. This was due to the use of the contains matcher,
which against string looks for substrings, when it was intended to look for
array elements.
The first number is the error message in HTML5 browser, which does not include
the call stack. The error instance allows logging the complete call stack in
reporters.
There are now multiple ways to do async functions, and callbacks
are probably the least common in new code, so the message should
be more general rather than referring to callbacks.
The global window error handler is used to handle errors thrown from within asynchronous functions and tests. The first parameter is the error; the fifth parameter is the full error object including the stacktrace. Searching for the first occurrence of an error instance to work with browsers, which may not comply with the HTML5 standard.
This breaks each call out onto its own line, so that it's much easier to
see where each call starts and how they differ. E.g. previously the output
would be:
Expected spy foo to have been called with [ 'bar', 'baz', 'qux' ] but actual calls were [ [ 42, 'wibble' ], [ 'bar' 'qux' ], [ 'grault '] ]
Now it's:
Expected spy foo to have been called with:
[ 'bar', 'baz', 'qux' ]
but actual calls were:
[ 42, 'wibble' ],
[ 'bar' 'qux' ],
[ 'grault '].
The PrettyPrint handler for scalars uses toString() but if that method
has been spyed on, then the stringify fails with
TypeError: Cannot read property 'length' of undefined.
By hanlding this case earlier in format() we avoid the error.
Add unit test covering this case.
Wrap spec start/complete in Timer start/elapsed.
configuration.timeSpecDuration = false will disable feature.
* Add Suite result.duration, elapsed time in ms
* Remove timeSpecDuration option.
* Respond to review, use noopTimer
With the current set up, error message is only printed out when error name is available.
There are situations where the ErrorEvent object does not have a `name` property, but the message is still relevant.
For more details see #1594
This function will spy on all writable and configurable functionss of
an object that is passed in. It can be used like this:
spyOnAllFunctions(obj);
This commit addresses https://github.com/jasmine/jasmine/issues/1421
This makes failures somewhat easier to read. We still preserve whitespace
within lines to make whitespace-only failures readable, e.g.
expect('foo bar').toEqual('foo bar'). See #296.
Adds a badge showing the number of people helping this repo on CodeTriage.
[](https://www.codetriage.com/jasmine/jasmine)
## What is CodeTriage?
CodeTriage is an Open Source app that is designed to make contributing to Open Source projects easier. It works by sending subscribers a few open issues in their inbox. If subscribers get busy, there is an algorithm that backs off issue load so they do not get overwhelmed
[Read more about the CodeTriage project](https://www.codetriage.com/what).
## Why am I getting this PR?
Your project was picked by the human, @schneems. They selected it from the projects submitted to https://www.codetriage.com and hand edited the PR. How did your project get added to [CodeTriage](https://www.codetriage.com/what)? Roughly 8 months ago, [alopezsanchez](https://github.com/alopezsanchez) added this project to CodeTriage in order to start contributing. Since then, 2 people have subscribed to help this repo.
## What does adding a badge accomplish?
Adding a badge invites people to help contribute to your project. It also lets developers know that others are invested in the longterm success and maintainability of the project.
You can see an example of a CodeTriage badge on these popular OSS READMEs:
- [](https://www.codetriage.com/rails/rails) https://github.com/rails/rails
- [](https://www.codetriage.com/crystal-lang/crystal) https://github.com/crystal-lang/crystal
## Have a question or comment?
While I am a bot, this PR was manually reviewed and monitored by a human - @schneems. My job is writing commit messages and handling PR logistics.
If you have any questions, you can reply back to this PR and they will be answered by @schneems. If you do not want a badge right now, no worries, close the PR, you will not hear from me again.
Thanks for making your project Open Source! Any feedback is greatly appreciated.
- Ensure *All's only execute if at least one child will run
- Specs will report a status of `excluded` instead of disabled
[finishes #153967580]
- #1418
Signed-off-by: Elenore Bastian <ebastian@pivotal.io>
CodeClimate's recommendations have been a mix of irrelevant and
actively harmful for some time. The latest problem is that it applies
length and complexity requirements equally to all functions whether
they act as privacy scopes, namespaces, classes or just regular old
functions.
Static analysis tools are only worthwhile if their recommendations add
enough value to offset the cost of slogging through them -- in other
words, if the signal to noise ratio is high enough. CodeClimate hasn't
carried its own weight for a long time, and it's only gotten worse with
each recent update.
- Pass file and line number to reporters when present
- Show file and line number in the HTML reporter when present
- Visually separate adjacent errors in the HTML reporter
[#24901981]
* Extracted sub-matchers for the two major existing strategies
(matching all errors, and matching by type and/or message)
* Reduced the use of mutable state
This enables some useful simplifications at the cost of making it
impossible (for now) to expect a function to throw an error with a falsy
message.
[#20622765]
CodeClimate makes recommendations that, while helpful for production
code, can be harmful for test code. In particular, following its
recommendations would lead us to aggressively de-duplicate even small
amounts of test setup code. That can create unwanted coupling, obscure
the intent of the tests, and make it harder to maintain tests as their
setup needs diverge.
Follow-up to some recent commits that fixed issues around
jasmine.anything() matching. This simply adds some extra tests that
exercise usage of Symbols with jasmine.anything() and as Map keys.
The previous Map equality code was assuming that the set of keys would
be identical between the two Maps. This change adds insertion-order
tracking for each key with its corresponding key. If one of the two keys
is an asymmetric equality obj, the keys are eq()'d, and if it succeeds,
the corresponding values are compared. Otherwise, the "main" key is
looked up directly in the other object; this is to prevent
similar-looking obj keys with different obj identities from comparing
equal.
Fixes#1432.
The original asymmetric matcher code for Any did not work with symbols
since `symbolInstance instanceof Symbol` is actually `false` (but,
`symbolInstance.constructor` is `Symbol). This simply adds an extra
clause that explicitly checks for symbol (if available) like the other
primitive types.
Also added some missing specs for other types, like Map, Set, etc.
Fixes#1431.
We want to make sure that Travis checks against the latest version of
our dependencies, and also maintain compatibility across multiple
versions of Node.
Signed-off-by: Steve Gravrock <sgravrock@pivotal.io>
The old contributing docs had a misaligned nested unordered-list, which
resulted in it creating a new list instead of being nested under its
parent.
It also seems like it would be useful to have the "revert your changes"
prose as part of the "Before Committing" section, since otherwise people
may miss it and have to amend.
The previous code was using `== null` to handle both `null` and
`undefined`, resulting in a jshint warning. The conditional is meant to
check for non-primitive values, and it happens to be the case that a
falsey value in JS is always a primitive, or `null` or `undefined`.
clearTimeout was not correctly handling the case of clearing a
timeout that is also scheduled to run at the same tick.
This fix adds a deletedKeys array that is checked whilst we are
running the scheduled functions for the current clock tick. If
a function exists in deletedKeys it will not be ran. deletedKeys
is then reset to an empty array.
Note: afterEach() functions are still run, because skipping them is
highly likely to pollute specs that run after the failure.
[Finishes #92252330]
- Fixes#577
- Fixes#807
Besides surfacing the error in the hopefully-correct place, this also
prevents the queue runners for sibling suites from interleaving, which
in turn prevents all kinds of internal state corruption.
Signed-off-by: Gregg Van Hove <gvanhove@pivotal.io>
It's possible for async code to cause an error when Jasmine
doesn't have any listeners registered internally. This causes
Jasmine to crash (Node) or log to the console (browser)
because of trying to call the nonexistent handler. This change
doesn't fix the overall problem but it does ensure that the
original error is logged rather than Jasmine's internal error.
Made installation instructions more version-agnostic (using {#.#.#} instead of what was hard-coded to 2.0.0), corrected example HTML file (../jasmine-core/... instead of ../jasmine-2.0.0/... in the paths for the core files).
It was discovered that afterAll hooks run in the same order that you add them,
while afterEach hooks were running in reverse order. This commit makes their
order consistent, and adds regression tests.
Relevant issue - https://github.com/jasmine/jasmine/issues/1311
This allows custom equality testers to affect asymmetric matches.
This avoid suprises when combining addCustomEqualityTester with
objectContaining or arrayContaining.
Closes#1138
examples:
```JavaScript
var mySpy = jasmine.createSpyObj("mySpy", { getAge: 55, getLanguage: "JavaScrizzle" });
var age = mySpy.getAge();
expect(age).toEqual(55);
expect(mySpy.getAge).toHaveBeenCalled();
```
Also does:
Add "isObject_" method to utils to make it easier for "createSpy" to support an array or object of stubs
- Since we're stating that compass is a development dependency in our
gemspec, and we use bundle to install it, we should make sure that
grunt is using the correct (bundled) version of compass.
- This is especially important since many of the older versions of compass
are buggy (see https://github.com/gruntjs/grunt-contrib-compass/issues/204)
- If the spied method is not an own property of the object being spied
upon, the method is deleted from the object on teardown instead of
being set to the original implementation.
- #737
The `Suite` constructor function does not expect or use the its only `attrs`
parameter's `queueRunner` attribute, so setting it serves no purpose and
only clutters the code and makes it more difficult to understand.
This is a fix for issue #917.
It seems that 'symbols' was originally included as a performance optimization, to avoid repeated find() calls for '.jasmine-symbol-summary'. However this find() occasionally fails during initialize if the dom has not loaded completely.
This change will not affect performance, as symbols is still cached. However it improves upon the original code in that the find happens at a stage much later than initialize.
Rephrase confusing statement:
From:
If when you run ($ grunt)...you see that JSHint runs your system is ready.
To:
Now run ($ grunt)...if you see that JSHint runs, your system is ready.
The only difference between this commit and the previous is that I have
used a difference scheme for naming Jasmine CSS classes.
Instead of appending "_jasmine-css" to all Jasmine CSS selectors, I have
now preprended "jasmine-" instead.
As described in Issue Report 844...
https://github.com/jasmine/jasmine/issues/844
...style rules in the app-being-tested may incidentally affect elements
in the Jasmine HTML Report container, as long as there is a chance that
the app-being-tested has CSS style rules for classes (or IDs) that
Jasmine uses.
This fix attempts to bring Jasmine to a state where each and every class
it uses always ends with "_jasmine-css" which should be unique enough to
ensure that CSS in the app-being-tested won't affect the Jasmine report,
because no app-being-tested is ever likely to use classes that end with
"_jasmine-css"
I'll be surpised if this commit is good enough as it is now, on the
first attempt to fix#844, because of reasons I'll explain in either
the Issue or the Pull Request.
I removed the `.showDetails` and `.summaryMenuItem` styles from the Sass
file because I believe that no HTML elements with those classes will
ever be generated by Jasmine and that they are dead code that someone
forgot to remove.
This is my first contribution to the Jasmine project and so I might be
doing something wrong, but I believe just this one change will propagate
to all the generated code when it is built, and that I should not be
altering any other code in any other place to accomplish the change I
intend.
This is related to Jasmine Issue 847:
https://github.com/jasmine/jasmine/issues/847
# Problem
To bring this lib in using Sprockets, you must do this:
```javascript
//= require jasmine/lib/jasmine-core
```
Sprockets can read `bower.json` and, if `main` is explicitly stated in the file, you can do the much more future-proof and compact:
```javascript
//= require jasmine
```
# Solution
Explicitly specify it.
# Caveats
I am not super-versed in Bower or JS packaging, so this is proposed in the vein of "this fixes my problem and seems consistent with other JS libs I've looked at", but I'm open to other solutions.
- execute beforeAll/afterAll once per suite instead of once per child
when running focused specs/suites Fixes#773
- refuse to execute an order if it would cause a suite with a beforeAll
or afterAll to be re-entered after leaving once
- report children of an xdescribe similarly to how they would be
reported if they were themselves x'd out Fixes#774
- only process the tree once instead of figuring it out again at each
level
[finishes #87545620]
Fixes#776
- If the mock clock was installed in a beforeAll, the QueueRunner would use the mock clock for its own clock. If the mock clock was ticked more than the default timeout, async specs would timeout.
[fixes#783#792]
In GJS, jasmineGlobal was not getting set to the global object; when
importing jasmine.js in GJS, "this" resolves to the jasmine.js module
object, not the global object. Solve this specifically for GJS by
assuming that `window.toString === '[object GjsGlobal]'` only in GJS; if
this is the case, assign "window" to "jasmineGlobal".
Adding a "var" to the declaration of "getJasmineRequireObj" is also
necessary, or else "getJasmineRequireObj" won't be exported in the
Jasmine module.
See #751
SpiderMonkey complains about functions not always returning a value. In
most cases that is a conscious code style choice, so it is not fixed
here.
In one case (MockDate) the interpreter thought you could have fallen off
the end of a "switch" statement, although the number of arguments
prevented that. This was fixed by changing the last case to "default".
In another case (QueueRunner) the function really did return a value
sometimes and nothing other times, although as far as I could see, it
could only ever return "undefined". The function now explicitly only
returns no value.
See #751
- This requires passing if runnables are set to the Suite. Hopefully in
the future we will change how focused runnables and *Alls interact so
this is no longer necessary.
[#732]
IE 8 doesn't have Array.prototype.indexOf so this breaks there.
Reverting until we can figure out a better way to solve across all
supported browsers.
This reverts commit 663fbd0cdb.
For some reason, when you put this spec in a describe block, it causes
specs to hang on IE8. I tried to debug this for a while, and I have no
idea what is happening.
[#79533268]
- Behaves similarly to to specResults
- Since suites were stored in an object instead of an array and the
current interface exposes this object, we now must keep track of suites
twice in the reporter. We cannot just construct the object lazily,
because then the object will not update with new suite results
like it does currently (see JsApiReporterSpec:148).
[#79533268]
- Focused runnables now walk up the tree to unfocus the first focused
ancestor. Because of the way the tree is constructed, this makes sure
that each focused runnable has no focused ancestors.
[#78289686]
Add specs to test if issue #655 is present: the handler of an interval
cannot successfully clear the same interval that generated it's
invocation.
The most direct test consist in setting an interval with a handler that
calls clearInterval over that same interval and make the clock tick for
double of it's period. If the issue is present the interval's handler
will be called twice. If the issue is not present, the first invocation
of the handler will avoid a second one (because of the clearInterval).
Another test is included in order to check if recurring scheduled
functions are rescheduled before being called. Doing this in the reverse
order is the exact cause of the issue.
Required duplicating some of the logic for constructing a suite from
describe so that we could mark a suite as focused in fdescribe, but
otherwise this prevents focused tests from being run more than once.
[#73742944]
Yo, this probably isn't the best behavior. Rspec and Ginkgo definitely
do not exhibit this behavior when you nest focused runnables inside
other focused runnables. We thought fixing it, but it seems like a
nontrivial refactoring would be necessary to clean this up.
[#73742944]
- Fix bug where beforeAlls were being mutated in Suite#execute
- When Env.execute() receives a list of runnables, beforeAlls and
afterAlls are collected as beforeEachs and afterEachs. This allows
runnables to be specified in any order, regardless of if any of them
have before/afterAlls.
- Spec constructor takes a single function that returns both before and
afters, instead of two functions. This breaks the current interface
for constructing a Spec.
[#73742528]
We found that this test was always passing and had strange interactions
with the ordering of other specs. Rewriting it to explicitly finish the
afterAll after a specified interval makes it fail correctly.
[#73742528]
This makes the specs green and appears to work for most cases. I have a
number of concerns about the implementation and would appreciate
ideas/feedback.
- Suite#addExpecationResult infers if it is coming from an afterAll fn
based on if the first child of the suite is finished. This assumes
that the first child of the suite is a spec (this appears to be true
as long as there is at least one spec in the suite)
- Suites behave like unfinished specs. Because suites will propagate
expectation failures to their children suites, the afterAll
expectation reporting appears to work for suites without specs
unless you have:
1) An otherwise empty suite with an afterAll
2) An afterAll'd suite whose first suite is empty (or whose first
suite's first suite is empty (and so on))
- Changed afterAllError to afterAllEvent, so it can accommodate both
errors and expectation failures. The reporter now receives a string
instead of the actual error object. The loss of the object doesn't
affect our reporters, but may be a nice-to-have for other reporters/
the future.
- The gap between the expectations caught in Suite and QueueRunner (who
triggers reporting via an injected callback) is an array injected into
QR by the Suite. The array is then flushed at some point (currently
after the attempt… functions). This works, but is a bit goofy.
[#73741654]
As described in issue #655, the handler of an interval cannot
successfully clear the same interval that generated it's invocation.
Solve this issue by changing the order in which interval's handlers are
called and then rescheduled to: first reschedule it and then call it.
The actual order (call first then reschedule) produces that, during the
execution of the interval's handler, the handler is not registered as
a function to run after a timeout or interval ("scheduledFunctions"),
because it was previously unregistered. Consequently, if the handler
calls clearInterval, that function wont be able to find the handler and
remove it completely.
Previously, was only printing out the stack while the html reporter
would print out the message as well as the stack. Now they should be
more consistent.
As noticed by @despairblue in #638
Fixes incorrect use of signature args
- Not currently an issue, since always called with '2', but could break unexpectedly if argSlice is used without reading the body.
jasmine_selenium_runner on master now has a fix for printing circular
objects which is needed since Jasmine has some circular objects that are
included now that we return passedExpectations (but was a bug with
failedExpectations anyways)
- Having the 'empty' state for a spec result can be considered a
breaking change to the reporter interface
- Instead, we determine if a spec has no expectations using the added
key of 'passedExpectations' in combination of the 'failedExpectations'
to determine that there a spec is 'empty'
[fixes#73741032]
If an async test has timed-out, there could still be some expectations
that are scheduled to run after the fact in which case curerntSpec will
be null. Rather than the type error that would result, we now indicate
that 'expect' was used at an unexpected time.
This also helps cases where an 'expect' is being used at a top-level,
showing an error message in the console for this case as well.
[fixes#602]
- jasmine-core can now self test with the jasmine-npm
- Add node examples files
- Add node_boot.js for node environment
- Move jasmine-core npm packaging to .npmignore
- removing src_dir and src_files from jasmine.json b/c jasmine-npm does not support requiring source files automatically.
will print out.
Currently, jasmine's pretty printer will iterate over an entire array,
formatting every element recursively. For very large arrays, this can
crash the page, or cause a 'slow script' warning.
This commit exposes a 'MAX_PRETTY_PRINT_ARRAY_LENGTH' option. If an
array larger than this is encountered, recursion will stop and the
array length will be printed instead e.g. "Array[20000000]".
The 'MAX_PRETTY_PRINT_ARRAY_LENGTH' option defaults to 100. This is
length of array will not kill your browser, but will allow you
to see big arrays, if you can stomach the output.
- Add console.error to the HtmlReporter when there is a spec without any expectation
- Change the spec's link text and color to include a warning
- Create a status for specs to label them as "empty"
- console is not accessible to IE unless you have developer tools open,
so protect against that by mocking console.
[#59424794]
- Switch from showing error stack to showing message/description since only chrome/ff support stack
- Fallback to error.description if error.message is undefined
- Made exceptionList variable name consistent between both reporters
- Add 'afterAllException' hook to reporter dispatch, we might want to make this more generic in the future
- Add afterAllException function to HtmlReporter
[#66789174]
- QueueRunner now responsible for timing out async specs instead of
Spec
- Make sure only spec functions are timeoutable and not suites (due to
the refactor)
By deferring the evaluation of these messages, we can avoid the
expensive creation of them when in the majority use case (tests are
passing) they are not needed.
These failure messages were causing performance problems with larger
objects needed to be pretty printed as discussed in #520 and brought up
by @rdy.
[fixes#65925900][fixes#520]
Updating the passing and failing colors in HTML reporter to
help red/green color blind users using the colors suggested by @dleppik
Console reporter still likely needs similar changes but there's less
options there
[#463, #509, finishes #60613086]
All timeouts and intervals set during a tick were being scheduled to run
at delay + end-of-tick, instead of delay + time-of-outer-timeout.
Scheduled run-at times were shifted because currentTime was being
incremented before executing scheduled functions.
Additionally, the execute loop was iterating over a functions-to-run
array, created from scheduledFunctions before starting. Any changes to
scheduledFunctions were being ignored during the tick, and the next tick
would ignore any functions which should have been executed in the past.
The commit is a rewrite of DelayedFunctionScheduler, preserving the
public interface. Execution of scheduled functions updates currentTime
on each iteration, and each time takes the functions with the lowest
runAtMillis from the schedule, if they aren't higher than endTime.
When an async spec throws a (sync) exception for some reason, the
exception was correctly caught and reported by Jasmine but the timeout
timer continued to run in the background.
For instance, running the (rather stupid) example below would report
the exception immediately but would also make the process loop for 5s
(and report the exception depending on the reported being used).
describe('exception', function () {
it('is caught but timer continues to run', function (done) {
throw new Error('Oh no!');
});
});
This happened because the timout timer is set in Spec while the
"try... catch" block is in the queue runner. The "callDone" function
of "timeoutable" that resets the timer was thus not called.
The commit simply introduces a "try... catch" block within the
`timeoutable` function to ensure that "callDone" gets called even
when an exception is thrown.
- Passing in a 'negativeCompare' will cause that function to be used when it is a 'not' assertion
- Otherwise, the reversal of the compare's result will be used instead
[finishes #59703824]
- Users can no longer spelunk the spec tree from topSuite
- Users no longer have access to currentSuite/currentSpec
- Other miscellaneous (arguably less useful) methods have also been tucked
away into the closure, like suiteFactory
- Specs are passing by default unless told otherwise
- Getting the result.status of a spec before the spec has run is now
undefined instead of pending
[finishes #59422744]
An update of fb3e1acb09
ES5 strict mode does not promote an undefined 'this' to the global object. The only way to get the global object in strict mode is to say 'this' while in the global scope.
- Will replace rake core_specs.
- Remove obsolete dependencies & files -- most of these were for build tasks we
are no longer using. Notably, rspec and spec_helper were deleted.
On a very large test suite (8000 specs), a significant amount
of time is spent just drawing the spec dots. Some sort of
worse-than-linear artifact that summons itself only when you
have 8000 floated elements trying to hang out together.
This performance penalty is not seen with inline-block.
In Chrome 29:
Floated dots: 16.795s
Inline-block dots: 2.774s
Setting the dots to 'display: none;' takes about the same time
as the inline-block figure, so this is probably a low enough bound
(no need for chunked rendering or who knows what).
- Update compass configuration to build jasmine.scss into lib
- Remove src/html/jasmine.css (since jasmine.scss builds directly into
lib now)
- Bump lib/jasmine-core/jasmine.css to be latest from scss
Allows a user to specify their desired timeout interval for async specs
and change it on a per spec basis (for particularly slow specs, for example).
As pointed out by @Eric-Wright in #422. [finishes #55996798]
Change the 'this' user functions are called with to be an empty object
instead of the QueueRunner so that if the user puts properties on it,
they won't conflict.
Also, changes async specs to be called with a proper 'this', as pointed
out by @Eric-Wright in #419 and #420.
[finishes #56030080]
Spec still can't work for maximumSpecCallbackDepth = 1 until further
mock clock enhancements. Fixes the specs running twice issue caused by
the previous commit.
- DRYs up the browser checking code
- Adds in Firefox as another flag
- Makes it possible to do checks like `if (env.ieVersion)` to target all
IE versions
Jasmine spies now have a 'and' property which allows the user to
change the spy's execution strategy-- such as '.and.callReturn(4)'
and a 'calls' property which allows inspection of the calls a spy
has received.
* This is a breaking change *
There is a CallTracker that keeps track of all calls and arguments
and a SpyStrategy which determines what the spy should do when it
is called.
Still not green, but getting close. Summary of Older IE discrepancies:
- Older IE doesn't have apply/call on the timing functions
- Older IE doesn't allow applying falsy arguments
- Older IE doesn't allow setting onclick to undefined values
- Older IE doesn't have text property on dom nodes
Similar to the changes in Jasmine core and console, this gets the
HTML specs of Jasmine using j$ instead of jasmine so that they use
the source files instead of the built distribution
- included what was thrown for failure messages in toThrow and toThrowError
- fixed typo from 'execption' to 'exception' in toThrowError failure messages
- clarified failure messages in toThrowError to include specific error types
[Fixes#52680709]
Since this information is desired in ConsoleReporter, HtmlReporter,
and now JsApiReporter, the executionTime is passed through in
jasmineDone from Env instead of making each reporter compute it.
Fixes#30, [Finishes #45659879]
since the passed in errorType could be a custom user function,
we instead detect if its an instanceof Error by using a Surrogate
(inspired by Backbone's use of surrogacy)
In Safari Mac 6.0.4 (and possibly other versions), a new error does
not have the stack property. Throwing the error and then catching it
ensures that the stack property has the correct value.
This fix gets the specs to run green in Safari.
- It still supports no expected, which means that something was thrown
- Expected value is now tested via equality in order to pass
Adding toThrowError:
- toThrowError() passes if an Error type was thrown
- toThrowError(String) & toThrowError(RegExp) compare Expected to the Error message
- toThrowError(Error constructor) compares Expected to the constructor of what was thrown
- toThrowError(Error constructor, String) & toThrowError(Error constructor, RegExp) compares both the Error and the message
Also, equality now handles Errors, enforcing the message as part of the equality.
Canonical Jasmine version now lives in `package.json` (Node formatted) and is copied into Jasmine source (JavaScript and Ruby)
Jasmine distribution now has MIT license and Pivotal Labs copyright at the top of each distributed file.
If ommited or null, delay for refered methods will default to 0. This
will make setTimeout and setInterval methods to behave as expected by
[HTML5 specs](http://www.w3.org/TR/html51/webappapis.html#timers):
"Let timeout [delay] be the second argument to the method, or zero if the
argument was omitted."
This commit also fixes an issue with tick() being called without arguments,
that causes the scheduler to break and stop working after this call.
* canonical version number of jasmine-core is now is package.json
* `grunt buildDistribution` builds jasmine.js, jasmine-html.js, jasmine.css and outputs them to the dist dir
* `grunt buildStandaloneDist` builds the example spec runner files and compresses them to dist/jasmine-VERSION.zip
* `grunt compass` compiles jasmine.css
* jasmine.Env handling of version is backwards compatible, but uses the version string directly (and nicely deprecated)
* Ruby/thor tasks that did the above deleted
Move from embedded "fork" of jsHint to using grunt's jsHint module.
Cleaned ALL jsHint errors.
Added jasmine.util.isUndefined as alternative to extra careful protection against undefined clobbering
- xit
- it with a null function body ( it("should be pending");
- calling pending() inside a spec
- having a spec without any expectations
Pending and Filtered specs now call Reporter interface specStarted so that reporting acts as expected.
Pending and Filtered spec names are present and styled in the HTML reporter
Using xit used to disable a spec. Disabling is now just when a spec is filtered out at run time (usually w/ the reporter).
Suites are still disabled with xdescribe and means its specs are never executed.
* New reporter interface across all reporters
* xdescribe & xit now store disabled specs
* Rewrite of HtmlReporter to support new interface and be more performant
- HTMLReporters should be rewritten to make this sort of thing easier.
- Fix HTMLReporter try/catch switch
- We can't really call resultCallback & throw, so that's been reverted
for now.
- This is necessary for the user to see spec results fill-in
progressively.
- There is a slight performance loss. 250 - 500ms seems to deliver the
same amount of loss. This is still at parity with Jasmine 1.x
- setTimeout will clear stack, prevent overflow. We run this once every
thousand specs.
- Browser users will probably want a time-based clear rather than spec
count based clear, as a thousand tests is typically quite slow. The
reporter should provide this.
- THere seems to be a performance regression. Large test suites may
throw
- Regressions: Mock Clock won't install correctly, async specs are
temporarily not supported.
- Async spec runs/waits interface is gone. Blocks are gone.
- Move most global usage into jasmine.Env constructor.
- Remove optional 'Jasmine running' from HtmlReporter -- caused
NS_FACTORY_ERROR in firefox when tested
- consequently, Runner & Suite no longer have results.
- Results come back to reporters from Spec, we should not have a need to
walk them later via suite/runner (in fact, no reporter used results on
suite/runner -- only bad tests)
- Remove/clean up tests relying on #results
- Remove integration tests that duplicate already tested behavior
- Allow users to set the pretty-printer's recursion depth
- When pretty-printing objects, don't include inherited properties.
- Change toBeCloseTo matcher to be more consistent
- Added toBeNaN matcher
- Add checkbox to test runner which toggles catching of exceptions duri
- Add config option which stops jasmine from capturing exceptions in a
Currently, jasmine's pretty printer traverses objects
to 40 levels of nesting. If an object is more deeply
nested than that, an exception is thrown. I find that
after a few levels of nesting, the output becomes
difficult to read. The process of serializing such
deep objects also sometimes crashes the browser or
causes a 'slow script' warning.
This commit exposes a 'MAX_PRETTY_PRINT_DEPTH' option.
It also causes the pretty printer to skip over
parts of an object that are nested to deeply by simply
printing out 'Object' or 'Array', rather than throwing
an exception.
When making assertions about complex objects, Jasmine's
failure message are sometimes gigantic and difficult
to read because the string representation of an object
contains all of the methods and properties in its
prototype chain. This commit causes the pretty printer
to only display on object's own properties.
`example_source_tags` and `example_spec_tags` each returned what the other
should have returned. I noticed this bug because it made the comments in
SpecRunner.html about where to include spec and source files incongruous with
the example tags that followed.
The current code makes the assumption that if window is undefined it is
being run in an environment which supports the CommonJS Modules spec.
This is not the case when Jasmine is being run in rhino or SpiderMonkey
(smjs) without EnvJS.
The fix is simply to check that exports is an object.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
This blocks will be run even when a preceeding block sets the abort
flag. This is so that we can support afterEach calls running when the
spec fails due to a timeout.
This stops it throwing errors in IE and other browsers. I think the newer Firefox and Chrome versions are the only browsers to not die when running it.
- Allow users to set the pretty-printer's recursion depth
- When pretty-printing objects, don't include inherited properties.
- Change toBeCloseTo matcher to be more consistent
- Added toBeNaN matcher
- Add checkbox to test runner which toggles catching of exceptions duri
- Add config option which stops jasmine from capturing exceptions in a
Currently, jasmine's pretty printer traverses objects
to 40 levels of nesting. If an object is more deeply
nested than that, an exception is thrown. I find that
after a few levels of nesting, the output becomes
difficult to read. The process of serializing such
deep objects also sometimes crashes the browser or
causes a 'slow script' warning.
This commit exposes a 'MAX_PRETTY_PRINT_DEPTH' option.
It also causes the pretty printer to skip over
parts of an object that are nested to deeply by simply
printing out 'Object' or 'Array', rather than throwing
an exception.
When making assertions about complex objects, Jasmine's
failure message are sometimes gigantic and difficult
to read because the string representation of an object
contains all of the methods and properties in its
prototype chain. This commit causes the pretty printer
to only display on object's own properties.
This stops it throwing errors in IE and other browsers. I think the newer Firefox and Chrome versions are the only browsers to not die when running it.
This blocks will be run even when a preceeding block sets the abort
flag. This is so that we can support afterEach calls running when the
spec fails due to a timeout.
* bigfix/after_waitsFor:
Test that show that afterEach and after are not being called when a waitsFor times out.
Test that afterEach is called after a failing spec.
Consolidate all waitsFor specs in the same describe block.
The current code makes the assumption that if window is undefined it is
being run in an environment which supports the CommonJS Modules spec.
This is not the case when Jasmine is being run in rhino or SpiderMonkey
(smjs) without EnvJS.
The fix is simply to check that exports is an object.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
`example_source_tags` and `example_spec_tags` each returned what the other
should have returned. I noticed this bug because it made the comments in
SpecRunner.html about where to include spec and source files incongruous with
the example tags that followed.
Move Browser & Node specs to test against lib/jasmine.js instead of the separate source. Yes, this makes development a little harder but it's better to test that jasmine.js was built correctly.
We welcome your contributions! Thanks for helping make Jasmine a better project for everyone. Please review the backlog and discussion lists before starting work. What you're looking for may already have been done. If it hasn't, the community can help make your contribution better. If you want to contribute but don't know what to work on, [issues tagged ready for work](https://github.com/jasmine/jasmine/labels/ready%20for%20work) should have enough detail to get started.
## Links
- [Jasmine Google Group](http://groups.google.com/group/jasmine-js)
- [Jasmine-dev Google Group](http://groups.google.com/group/jasmine-js-dev)
- [Jasmine on PivotalTracker](https://www.pivotaltracker.com/n/projects/10606)
## General Workflow
Please submit pull requests via feature branches using the semi-standard workflow of:
```bash
git clone git@github.com:yourUserName/jasmine.git # Clone your fork
cd jasmine # Change directory
git remote add upstream https://github.com/jasmine/jasmine.git # Assign original repository to a remote named 'upstream'
git fetch upstream # Fetch changes not present in your local repository
git merge upstream/main # Sync local main with upstream repository
git checkout -b my-new-feature # Create your feature branch
git commit -am 'Add some feature'# Commit your changes
git push origin my-new-feature # Push to the branch
```
Once you've pushed a feature branch to your forked repo, you're ready to open a pull request. We favor pull requests with very small, single commits with a single purpose.
## Background
### Directory Structure
*`/src` contains all of the source files
*`/src/core` - generic source files
*`/src/html` - browser-specific files
*`/spec` contains all of the tests
* mirrors the source directory
* there are some additional files
*`/dist` contains the standalone distributions as zip files
*`/lib` contains the generated files for distribution as the Jasmine Rubygem and the Python package
### Self-testing
Note that Jasmine tests itself. The files in `lib` are loaded first, defining the reference `jasmine`. Then the files in `src` are loaded, defining the reference `jasmineUnderTest`. So there are two copies of the code loaded under test.
The tests should always use `jasmineUnderTest` to refer to the objects and functions that are being tested. But the tests can use functions on `jasmine` as needed. _Be careful how you structure any new test code_. Copy the patterns you see in the existing code - this ensures that the code you're testing is not leaking into the `jasmine` reference and vice-versa.
### `boot.js`
This file does all of the setup necessary for Jasmine to work. It loads all of the code, creates an `Env`, attaches the global functions, and builds the reporter. It also sets up the execution of the `Env` - for browsers this is in `window.onload`. While the default in `lib` is appropriate for browsers, projects may wish to customize this file.
For example, for Jasmine development there is a different `dev_boot.js` for Jasmine development that does more work.
### Compatibility
Jasmine supports the following environments:
* Browsers
* IE10+
* Edge Latest
* Firefox Latest
* Chrome Latest
* Safari 8+
* Node.js
* 8
* 10
* 12
## Development
All source code belongs in `src/`. The `core/` directory contains the bulk of Jasmine's functionality. This code should remain browser- and environment-agnostic. If your feature or fix cannot be, as mentioned above, please degrade gracefully. Any code that depends on a browser (specifically, it expects `window` to be the global or `document` is present) should live in `src/html/`.
### Install Dependencies
Jasmine Core relies on Node.js.
To install the Node dependencies, you will need Node.js, Npm, and [Grunt](http://gruntjs.com/), the [grunt-cli](https://github.com/gruntjs/grunt-cli) and ensure that `grunt` is on your path.
$ npm install --local
...will install all of the node modules locally. Now run
$ npm test
...you should see tests run and eslint checking formatting.
### How to write new Jasmine code
Or, How to make a successful pull request
* _Do not change the public interface_. Lots of projects depend on Jasmine and if you aren't careful you'll break them
* _Be environment agnostic_ - server-side developers are just as important as browser developers
* _Be browser agnostic_ - if you must rely on browser-specific functionality, please write it in a way that degrades gracefully
* _Write specs_ - Jasmine's a testing framework; don't add functionality without test-driving it
* _Write code in the style of the rest of the repo_ - Jasmine should look like a cohesive whole
* _Ensure the *entire* test suite is green_ in all the big browsers, Node, and ESLint - your contribution shouldn't break Jasmine for other users
Follow these tips and your pull request, patch, or suggestion is much more likely to be integrated.
### Running Specs
Jasmine uses some internal tooling to test itself in browser on Travis. This tooling _should_ work locally as well.
$ node spec/support/ci.js
You can also set the `JASMINE_BROWSER` environment variable to specify which browser should be used.
The easiest way to run the tests in **Internet Explorer** is to run a VM that has IE installed. It's easy to do this with VirtualBox.
1. Download and install [VirtualBox](https://www.virtualbox.org/wiki/Downloads).
1. Download a VM image [from Microsoft](https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/). Select "VirtualBox" as the platform.
1. Unzip the downloaded archive. There should be an OVA file inside.
1. In VirtualBox, choose `File > Import Appliance` and select the OVA file. Accept the default settings in the dialog that appears. Now you have a Windows VM!
1. Run the VM and start IE.
1. With `npm run serve` running on your host machine, navigate to `http://10.0.2.2:8888` in IE.
## Before Committing or Submitting a Pull Request
1. Ensure all specs are green in browser *and* node
1. Ensure eslint and prettier are clean as part of your `npm test` command. You can run `npm run cleanup` to have prettier re-write the files.
1. Build `jasmine.js` with `npm run build` and run all specs again - this ensures that your changes self-test well
1. Revert your changes to `jasmine.js` and `jasmine-html.js`
* We do this because `jasmine.js` and `jasmine-html.js` are auto-generated (as you've seen in the previous steps) and accepting multiple pull requests when this auto-generated file changes causes lots of headaches
* When we accept your pull request, we will generate these files as a separate commit and merge the entire branch into main
Note that we use Travis for Continuous Integration. We only accept green pull requests.
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at jasmine-maintainers@googlegroups.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
We welcome your contributions! Jasmine is currently maintained by Davis Frank ([infews](http://github.com/infews)), Rajan Agaskar ([ragaskar](http://github.com/ragaskar)), and Christian Williams ([Xian](http://github.com/Xian)). You can help us by removing all other recipients from your pull request.
Copyright (c) 2008-2010 Pivotal Labs. This software is licensed under the MIT License.
Jasmine is a Behavior Driven Development testing framework for JavaScript. It does not rely on browsers, DOM, or any JavaScript framework. Thus it's suited for websites, [Node.js](http://nodejs.org) projects, or anywhere that JavaScript can run.
Documentation & guides live here: [http://jasmine.github.io](http://jasmine.github.io/)
For a quick start guide of Jasmine, see the beginning of [http://jasmine.github.io/edge/introduction.html](http://jasmine.github.io/edge/introduction.html).
Upgrading from Jasmine 2.x? Check out the [3.0 release notes](https://github.com/jasmine/jasmine/blob/v3.0.0/release_notes/3.0.md) for a list of what's new (including breaking changes).
## Contributing
Please read the [contributors' guide](https://github.com/jasmine/jasmine/blob/main/.github/CONTRIBUTING.md).
Follow the instructions in `CONTRIBUTING.md` during development.
### Git Rules
Please attempt to keep commits to `main` small, but cohesive. If a feature is contained in a bunch of small commits (e.g., it has several wip commits or small work), please squash them when pushing to `main`.
### Version
We attempt to stick to [Semantic Versioning](http://semver.org/). Most of the time, development should be against a new minor version - fixing bugs and adding new features that are backwards compatible.
The current version lives in the file `/package.json`. This version will be the version number that is currently released. When releasing a new version, update `package.json` with the new version and `grunt build:copyVersionToGem` to update the gem version number.
This version is used by both `jasmine.js` and the `jasmine-core` Ruby gem.
Note that Jasmine should only use the "patch" version number in the following cases:
* Changes related to packaging for a specific platform (npm, gem, or pip).
* Fixes for regressions.
When jasmine-core revs its major or minor version, the binding libraries should also rev to that version.
## Release
When ready to release - specs are all green and the stories are done:
1. Update the release notes in `release_notes` - use the Anchorman gem to generate the markdown file and edit accordingly
1. Update the version in `package.json`
1. Run `npm run build`.
1. Copy version to the Ruby gem with `grunt build:copyVersionToGem`
### Commit and push core changes
1. Commit release notes and version changes (jasmine.js, version.rb, package.json)
1. Push
1. Wait for Travis to go green
### Build standalone distribution
1. Build the standalone distribution with `grunt buildStandaloneDist`
1. This will generate `dist/jasmine-standalone-<version>.zip`, which you will upload later (see "Finally" below).
### Release the core Ruby gem
1.__NOTE__: You will likely need to push a new jasmine gem with a dependent version right after this release. See below.
1.`rake release` - tags the repo with the version, builds the `jasmine-core` gem, pushes the gem to Rubygems.org. In order to release you will have to ensure you have rubygems creds locally.
### Release the core Python egg
Install [twine](https://github.com/pypa/twine)
1.`python setup.py sdist`
1.`twine upload dist/jasmine-core-<version>.tar.gz` You will need pypi credentials to upload the egg.
### Release the core NPM module
1.`npm adduser` to save your credentials locally
1.`npm publish .` to publish what's in `package.json`
### Release the docs
Probably only need to do this when releasing a minor version, and not a patch version.
1.`rake update_edge_jasmine`
1.`npm run jsdoc`
1.`rake release[${version}]` to copy the current edge docs to the new version
1. Commit and push.
### Release the binding libraries
#### NPM
1. Create release notes using Anchorman as above
1. In `package.json`, update both the package version and the jasmine-core dependency version
1. Commit and push.
1. Wait for Travis to go green again.
1.`grunt release `. (Note: This will publish the package by running `npm publish`.)
#### Gem
1. Create release notes using Anchorman as above
1. Update the version number in `lib/jasmine/version.rb`.
1. Update the jasmine-core dependency version in `jasmine.gemspec`.
1. Commit and push.
1. Wait for Travis to go green again.
1.`rake release`
### Finally
For each of the above GitHub repos:
1. Visit the releases page and find the tag just published.
1. Paste in a link to the correct release notes for this release. The link should reference the blob and tag correctly, and the markdown file for the notes.
<divid="REMOVE_THIS_LINE_FROM_BUILD"><p>You must be trying to look at examples in the Jasmine source tree.</p><p>Please download a distribution version of Jasmine at <ahref="http://pivotal.github.com/jasmine/">http://pivotal.github.com/jasmine/</a>.</p></div>
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
/**
Starting with version 2.0, this file "boots" Jasmine, performing all of the necessary initialization before executing the loaded environment and all of a project's specs. This file should be loaded after `jasmine.js` and `jasmine_html.js`, but before any project source files or spec files are loaded. Thus this file can also be used to customize Jasmine for a project.
If a project is using Jasmine via the standalone distribution, this file can be customized directly. If a project is using Jasmine via the [Ruby gem][jasmine-gem], this file can be copied into the support directory via `jasmine copy_boot_js`. Other environments (e.g., Python) will have different mechanisms.
The location of `boot.js` can be specified and/or overridden in `jasmine.yml`.
* Require Jasmine's core files. Specifically, this requires and attaches all of Jasmine's code to the `jasmine` reference.
*/
varjasmine=jasmineRequire.core(jasmineRequire),
global=jasmine.getGlobal();
global.jasmine=jasmine;
/**
* Since this is being run in a browser and the results should populate to an HTML page, require the HTML-specific Jasmine code, injecting the same reference.
*/
jasmineRequire.html(jasmine);
/**
* Create the Jasmine environment. This is used to run all specs in a project.
*/
varenv=jasmine.getEnv();
/**
* ## The Global Interface
*
* Build up the functions that will be exposed as the Jasmine public interface. A project can customize, rename or alias any of these functions as desired, provided the implementation remains unchanged.
* Add all of the Jasmine global/public interface to the global scope, so a project can use the public interface directly. For example, calling `describe` in specs instead of `jasmine.getEnv().describe`.
*/
extend(global,jasmineInterface);
/**
* ## Runner Parameters
*
* More browser specific code - wrap the query string in an object and to allow for getting/setting parameters from the runner user interface.
* The `HtmlReporter` builds all of the HTML UI for the runner page. This reporter paints the dots, stars, and x's for specs, as well as all spec names and all failures (if any).
* Setting up timing functions to be able to be overridden. Certain browsers (Safari, IE 8, phantomjs) require this hack.
*/
window.setTimeout=window.setTimeout;
window.setInterval=window.setInterval;
window.clearTimeout=window.clearTimeout;
window.clearInterval=window.clearInterval;
/**
* ## Execution
*
* Replace the browser window's `onload`, ensure it's called, and then run all of the loaded specs. This includes initializing the `HtmlReporter` instance and then executing the loaded Jasmine environment. All of this will happen after all of the specs are loaded.
Starting with version 2.0, this file "boots" Jasmine, performing all of the necessary initialization before executing the loaded environment and all of a project's specs. This file should be loaded after `jasmine.js` and `jasmine_html.js`, but before any project source files or spec files are loaded. Thus this file can also be used to customize Jasmine for a project.
If a project is using Jasmine via the standalone distribution, this file can be customized directly. If a project is using Jasmine via the [Ruby gem][jasmine-gem], this file can be copied into the support directory via `jasmine copy_boot_js`. Other environments (e.g., Python) will have different mechanisms.
The location of `boot.js` can be specified and/or overridden in `jasmine.yml`.
* Require Jasmine's core files. Specifically, this requires and attaches all of Jasmine's code to the `jasmine` reference.
*/
varjasmine=jasmineRequire.core(jasmineRequire),
global=jasmine.getGlobal();
global.jasmine=jasmine;
/**
* Since this is being run in a browser and the results should populate to an HTML page, require the HTML-specific Jasmine code, injecting the same reference.
*/
jasmineRequire.html(jasmine);
/**
* Create the Jasmine environment. This is used to run all specs in a project.
*/
varenv=jasmine.getEnv();
/**
* ## The Global Interface
*
* Build up the functions that will be exposed as the Jasmine public interface. A project can customize, rename or alias any of these functions as desired, provided the implementation remains unchanged.
* Add all of the Jasmine global/public interface to the global scope, so a project can use the public interface directly. For example, calling `describe` in specs instead of `jasmine.getEnv().describe`.
*/
extend(global,jasmineInterface);
/**
* ## Runner Parameters
*
* More browser specific code - wrap the query string in an object and to allow for getting/setting parameters from the runner user interface.
* The `HtmlReporter` builds all of the HTML UI for the runner page. This reporter paints the dots, stars, and x's for specs, as well as all spec names and all failures (if any).
* Setting up timing functions to be able to be overridden. Certain browsers (Safari, IE 8, phantomjs) require this hack.
*/
window.setTimeout=window.setTimeout;
window.setInterval=window.setInterval;
window.clearTimeout=window.clearTimeout;
window.clearInterval=window.clearInterval;
/**
* ## Execution
*
* Replace the browser window's `onload`, ensure it's called, and then run all of the loaded specs. This includes initializing the `HtmlReporter` instance and then executing the loaded Jasmine environment. All of this will happen after all of the specs are loaded.
- Support for focused specs via `fit` and `fdescribe`
- Support for `beforeAll` and `afterAll`
- Support for an explicit `fail` function, both in synchronous and asynchronous specs
- Allow custom timeout for `beforeEach`, `afterEach`, `beforeAll`, `afterAll` and `it`
- Spies now track return values
- Specs can now specify their own timeouts
- Testing in Node.js via the official Jasmine Node Module
- Spec results now have `suiteResults` method that behaves similarly to to `specResults`
- HtmlReporter shows error alerts for afterAllExceptions
## Bugs
- CI now works for IE8 (this was releated to `ConsoleReporter` below)
- Detect global object properly when getting the jasmine require obj
- Fixes Issue #[569][issue_569] - [Tracker Story #73684570](http://www.pivotaltracker.com/story/73684570)
## Deprecations
### `ConsoleReporter` as part of Jasmine core
The Console Reporter exists nearly entirely for the old manner of running Jasmine's own specs in node.js. As we are now supporting node.js officially, this reporter code no longer needs to be in this repo and instead will be in the Jasmine npm.
For now you will see a deprecation message. It will be removed entirely in Jasmine 3.0.
## Documentation
- Release Notes from previous releases now live at [Jasmine's GitHub release page][releases]. See Tracker Story #[54582902][tracker_1]
- Better instructions for releasing new documentation
-`toContain` works with array-like objects (Arguments, HTMLCollections, etc)
- Merges #[699][issue_699] from @charleshansen
- Fixed isPendingSpecException test title
- Merges #[691][issue_691] from @ertrzyiks
- Fixed an issue with example code in the npm
- Merges #[686][issue_686] from @akoptsov
- When the Jasmine clock is installed and date is mocked, `new Date() instanceof Date` should equal `true` Issue #[678][issue_678] & Issue #[679][issue_679] from @chernetsov
- Support for an explicit `fail` function, both in synchronous and asynchronous specs
- Fixes Issue #[567][issue_567], Issue #[568][issue_568], and Issue #[563][issue_563]
- Allow custom timeout for `beforeEach`, `afterEach`, `beforeAll`, `afterAll` and `it`
- Fixes Issue #[483][issue_483] - specs can now specify their own timeouts
- Spies can track return values
- Fixes Issue #[660][issue_660], Merged Issue #[669][issue_669] from @mkhanal
- Interval handlers can now clear their interval
- Fixes Issue #[655][issue_655] Merged Issue #[658][issue_658] from @tgirardi
- Updated to the latest `json2.js`
- Merges #[616][issue_616] from @apaladox2015
------
_Release Notes generated with [Anchorman](http://github.com/infews/anchorman)_
* When stop on failure is enabled, skip subsequent it() and beforeEach(). Note: afterEach() functions are still run, because skipping them is highly likely to pollute specs that run after the failure.
* Report the random seed at the beginning and end of execution. This allows reporters to provide the seed to the user even in cases where Jasmine crashes before completing.
- Merges [#1348](https://github.com/jasmine/jasmine/issues/1348) from @sgravrock
* Add ES6 map support to Jasmine
- Merges [#1340](https://github.com/jasmine/jasmine/issues/1340) from @rmehlinger
_Release Notes generated with _[Anchorman](http://github.com/infews/anchorman)_
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.