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.
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
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]
- 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]
- 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]
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]
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).
