search

cemerick / clojurescript.test

A maximal port of `clojure.test` to ClojureScript. DEPRECATED
165 stars 32 forks source link

Stacktraces from exception are hard to decipher #88

Closed jeluard closed 9 years ago

jeluard commented 9 years ago

It looks like release 0.3.3 introduced a change that makes stacktraces hard to decipher.

Here is what I have with 0.3.2:

  actual:
cljs.core.seq@target/cljs/unit-test.js:3236:34
cljs.core.seq_reduce</c@target/cljs/unit-test.js:4646:10
cljs.core.seq_reduce</a@target/cljs/unit-test.js:4662:9
cljs.core.reduce</c@target/cljs/unit-test.js:4679:211
cljs.core.reduce</a@target/cljs/unit-test.js:4685:9
cljs.core.into</b@target/cljs/unit-test.js:9961:5
cljs.core.into</a@target/cljs/unit-test.js:9967:9
lucuma.initialize_instance_BANG_@target/cljs/unit-test.js:18272:1

and with 0.3.3

cljs.core.seq@file:///var/folders/lh/2mf6z35s71zfpd3hbkkp8t3c0000gn/T/runner3705699464095786065.js.html:3240:34
c@file:///var/folders/lh/2mf6z35s71zfpd3hbkkp8t3c0000gn/T/runner3705699464095786065.js.html:4650:10
a@file:///var/folders/lh/2mf6z35s71zfpd3hbkkp8t3c0000gn/T/runner3705699464095786065.js.html:4666:9
c@file:///var/folders/lh/2mf6z35s71zfpd3hbkkp8t3c0000gn/T/runner3705699464095786065.js.html:4683:211
a@file:///var/folders/lh/2mf6z35s71zfpd3hbkkp8t3c0000gn/T/runner3705699464095786065.js.html:4689:9
b@file:///var/folders/lh/2mf6z35s71zfpd3hbkkp8t3c0000gn/T/runner3705699464095786065.js.html:9965:5
a@file:///var/folders/lh/2mf6z35s71zfpd3hbkkp8t3c0000gn/T/runner3705699464095786065.js.html:9971:9
lucuma.initialize_instance_BANG_@file:///var/folders/lh/2mf6z35s71zfpd3hbkkp8t3c0000gn/T/runner3705699464095786065.js.html:18276:1

Also note there is no error message shown, just the stacktrace.

Is this something we want to improve?

cemerick commented 9 years ago

Yeah, that was a consequence of my updating the phantom/slimerjs runner @ 64459d4 to pull the content of all of the scripts/expressions to be loaded into a generated HTML page. In short, injectJs (part of the phantom API) loads code within the browser page's context using various mechanisms (they're slightly different in phantom vs. slimerjs) that lead to security context violations in certain circumstances (most immediate being the new way core.async schedules go block state machine steps starting in one of the more recent builds there).

So, the new approach fixes the security context problem, but makes stack traces useless, as you've seen. A better approach would be for the test runner(s) to be written into /target (they go into /tmp right now), and then we can generate an HTML page to feed into the browser page context that loads all scripts named in the arguments to the test runner via relative paths. I think that will work, as long as there aren't other peculiarities about the security context when loading pages/resources from disk...

cemerick commented 9 years ago

Sorry for the troubles, but I've deprecated this project. Please see the notice at the top of the repo's README. This is a good thing, fundamentally. :-)