Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Force Jasmine run to fail if any uncaught errors occur #326

Closed
brentsnook opened this issue Feb 6, 2013 · 11 comments

Comments

@brentsnook
Copy link

commented Feb 6, 2013

I think the test run should fail if any uncaught errors occur on the page.

We had a nasty situation where a compilation error in a Jasmine spec file caused the test run to pass as if nothing had gone wrong. The syntax error prevented the examples from being registered and it was as if the spec hadn't even existed. I can see how one syntax error could cause a whole spec to fall into decay if it isn't regularly touched.

I tried to hack in a fix as suggested at https://gist.github.com/mattyod/3911612 but the problem with this is getting that spec to load first before any of the others are evaluated. The hacky workaround is the name this file beginning with 'aaa' or something so it loads first.

Here's the Gist: https://gist.github.com/brentsnook/4721960

@ragaskar

This comment has been minimized.

Copy link
Contributor

commented Feb 6, 2013

Interesting. This is probably a good solution for web runners.

FWIW, you can just throw this in spec_helpers, that will load it prior to specs being run. spec files are also uniq'd before being loaded, so you can do something like the following in jasmine.yml:

spec_files: 
  - load_this_first.js
  - **/*spec.js
@lukeasrodgers

This comment has been minimized.

Copy link

commented Feb 6, 2013

If this were to be implemented, I think it should be as a command-line config option. When introducing jasmine into an environment where the code has not been written to allow for easy testing, your test suite could be full of errors that you just don't care about (yet, anyway). Also this change would probably require some people to rewrite specs, if not the actual code under test, to handle error throwing/catching differently.

@brentsnook

This comment has been minimized.

Copy link
Author

commented Feb 6, 2013

@ragaskar Thanks - much better than naming the spec aaa

@lukeasrodgers That'd be great as long as it was easily configurable from the Jasmine gem too. Something like a "strict" option

@infews

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2014

We have a story in the icebox for catching syntax errors. We want to add this at some point as many have asked for it.

Closing for now as it's a feature request and it's in Tracker.

@jchesterpivotal

This comment has been minimized.

Copy link

commented Jul 25, 2017

As a note, we have encountered this as well. Is there any sense of when it might be addressed? The Tracker icebox entry seems to have been untouched since 2015.

This can leave folk like myself with a false sense of security, because everything "passes". It's only when you see different numbers of tests run in different browsers or headless browsers that it becomes obvious that something is amiss.

To me BDD and TDD are about improving assurance and trust in the code, to allow more fearless refactoring and improvement. That I will never be able to truly know, starting with baseline Jasmine, that all the tests and specs I provided were actually run, is upsetting.

@sgravrock

This comment has been minimized.

Copy link
Member

commented Jul 25, 2017

I understand why this feature is desirable. I hack it into boot.js pretty much every time I start a project that uses Jasmine standalone. It hasn't been implemented in Jasmine yet because it's a breaking change and it's likely to be a little tricky to get right for all users. There are plenty of systems that trigger the global error event during successful initialization, and we don't want to break their test suites on a point release. We also need to think carefully about situations where the code under test depends on libraries that raise errors during initialization. So while I'd also like to see this feature, it's going to take some careful work and I think it has to wait for a major version bump.

@berlin-ab

This comment has been minimized.

Copy link

commented Oct 23, 2017

Bumping this feature request. We just introduced this workaround to our project. It would be nice if it were a configurable option at least.

@slackersoft

This comment has been minimized.

Copy link
Member

commented Nov 28, 2017

This functionality should be coming in 3.0. Check out the 3.0-features branch.

No, I don't have an ETA for release right now :)

@ardalis

This comment has been minimized.

Copy link

commented Feb 6, 2018

A couple of months later, any ETA for 3.0 now? :)

@slackersoft

This comment has been minimized.

Copy link
Member

commented Feb 6, 2018

Jasmine 3.0 was released today. Please check out the release notes and use the 2.99 release to check for changed functionality.

@ardalis

This comment has been minimized.

Copy link

commented Feb 7, 2018

Sweet! Nice timing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.