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