Skip to content
This repository has been archived by the owner on Jan 16, 2022. It is now read-only.

Adding Jasmine-Parser gem to generate JS stack trace in Rspec #140

Closed
wants to merge 3 commits into from

Conversation

dimacus
Copy link

@dimacus dimacus commented Mar 8, 2013

Hey guys,

Finally got some stuff together, think of this as a preview commit because i'm looking for your feedback on how to make this better. But here it goes.

I notice that stack traces in files were not supported at all in rspec, and especially on IE. So, to solve this issue, I've made a small gem that parses all of the spec files and creates a stack trace, which later gets injected into rspec's stack trace for a failure.

Here is what it looks like now on 2 tests, which I force to fail http://i.imgur.com/f7Bvjhv.jpg
1 bash-1

Couple of notes on the gem

  1. My next goal is to improve the performance of the parsing. Rkelly is not the fastest JS parser I know : ( However, making the parser go through the spec files while we wait for the browser tests to finish does save a lot of time. 3,700 tests take about 2 mins to parse, and only chrome which takes 2 mins to run has to wait on the parser
  2. This gem works pretty well in tracking down shared examples across many files and almost infinitely nested shared examples. I still have some work to do to make it recognize every way a shared example can be declared, but so far out of 3700 examples, parser cannot track down only about 300
  3. This was extensively tested on Rspec1 I need more help testing rspec 2
  4. Works like a charm on windows!!!!
  5. I’m horribly unhappy with how I’m inserting the JS stack trace into the Rspec’s backtrace… please please please let me know there is a better way
  6. I’ve tried to make this gem insert itself into jasmine as painlessly as possible, and tried to make it fail in a non-destructive way as possible.
  7. I need to add a couple of tests which make sure the failing tests are showing up in console properly. Any pointers on that are appreciated
  8. Sorry for 3 commits, my git hiccupped and forced me to do a merge… I’ll collapse it into a single commit after you give me some feedback.

Parser source code lives here: https://github.com/groupon/jasmine-parser
I’ll continue working on it, to make it better.

Finally, my hope is to use this gem to add future feature to jasmine, where user can run a single test or a folder. This way the full suite does not need to be loaded into the browser… my hope is to make it a little closer to rspec behavior

… jasmine… foo/bar_spec.js:13

@slackersoft
Copy link
Member

We've changed a lot about the internals of the jasmine gem for 2.0. Notably, removing the RSpec dependency and changing how we handle custom runners and formatters.

The stacktraces that are printed should be coming straight from the javascript error now, so we would be curious how much the pain you were feeling around bad stacktraces in the jasmine:ci output are addressed now.

Closing this for now, since javascript stacktraces aren't getting clobbered by the RSpec reporter anymore.

@slackersoft slackersoft closed this Oct 1, 2013
@dimacus
Copy link
Author

dimacus commented Oct 2, 2013

well technically the stack traces were not clobbered per se... when it
comes to IE they are just simply non-existent. The pain point came from
failures of tests which work just fine on FF and Chrome but would fail
miserably on IE. Lack of stack trace meant that there is a lot of grepping
going on just to find what test failure happened.

I got the stack traces working in our CI for by doing the above solution,
and i think i'll hold on upgrading to 2.0 bc the loss of stack traces in IE
is too significant. If you guys do like the this solution, i might be able
to work on implementing it with 2.0 gem. If not then i won't bother much

On Tue, Oct 1, 2013 at 4:51 PM, Gregg Van Hove notifications@github.comwrote:

We've changed a lot about the internals of the jasmine gem for 2.0.
Notably, removing the RSpec dependency and changing how we handle custom
runners and formatters.

The stacktraces that are printed should be coming straight from the
javascript error now, so we would be curious how much the pain you were
feeling around bad stacktraces in the jasmine:ci output are addressed now.

Closing this for now, since javascript stacktraces aren't getting
clobbered by the RSpec reporter anymore.


Reply to this email directly or view it on GitHubhttps://github.com//pull/140#issuecomment-25488225
.

-Dima Kovalenko

Good judgment comes from experience, and experience comes from bad judgment.
--Frederick P. Brooks

@ragaskar
Copy link
Contributor

ragaskar commented Oct 3, 2013

This seems cool! I don't know if we want to add this to the gem proper, as at the moment it looks like it will draw in a bunch of dependencies, but if there's anything we can do to make it easier for you to maintain your gem, let us know.

We are trying to get away from rspec, let us know if there could be changes to the reporting interface that would help make what you're doing easier.

Thanks!

@dimacus
Copy link
Author

dimacus commented Oct 3, 2013

so the only tie into the rspec in my fix was to hijack the stack trace by
monkey patching into it. I don't see a reason why it cannot parse things
and if something fails my thing returns you a string or an array with the
stack trace building up to the whole scenario name.

Honestly, the biggest pain in the ass was for me to solve all of the
"shared" and "nested" examples... but once i did that, the tests which are
shared and looped started to be so much simpler to deal with.

P.S. I don't mind keeping this as a separate gem, just give me ability to
"start parsing" the JS files in beging/during test run, and hand you off a
stack trace for any test that you ask for by full name. (The way i did it
before was to hijack the hash you had with full test name => stack trace,
and just returning you a string with "\n" for stack trace so it pretty
prints)

On Thu, Oct 3, 2013 at 1:45 PM, Rajan Agaskar notifications@github.comwrote:

This seems cool! I don't know if we want to add this to the gem proper, as
at the moment it looks like it will draw in a bunch of dependencies, but if
there's anything we can do to make it easier for you to maintain your gem,
let us know.

We are trying to get away from rspec, let us know if there could be
changes to the reporting interface that would help make what you're doing
easier.

Thanks!


Reply to this email directly or view it on GitHubhttps://github.com//pull/140#issuecomment-25642049
.

-Dima Kovalenko

Good judgment comes from experience, and experience comes from bad judgment.
--Frederick P. Brooks

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants