jejacks0n / teaspoon

Teaspoon: Javascript test runner for Rails. Use Selenium, BrowserStack, or PhantomJS.
1.43k stars 243 forks source link

Failed to load after test suites run #202

Closed psharpNumerex closed 10 years ago

psharpNumerex commented 10 years ago

I'm getting a Teaspoon running mobile_tests suite at http://127.0.0.1:64597/teaspoon/mobile_tests ......................................................................................................

Finished in 0.64800 seconds 102 examples, 0 failures

Teaspoon running web_tests suite at http://127.0.0.1:64597/teaspoon/web_tests .................................................................................................................................................................................................................................

Finished in 0.87600 seconds 225 examples, 0 failures Failed to load: http://127.0.0.1:64597/teaspoon/web_tests?reporter=Console

AFTER the test suites have all run AND passed.

Using Rails 3.2 and phantom.js 1.9.7

Any suggestions for how to track this sucker down?

jejacks0n commented 10 years ago

Hmm.. so check here: https://github.com/modeset/teaspoon/blob/master/lib/teaspoon/drivers/phantomjs/runner.js#L85

So, I would assume there's something that's making that hit more than once, or something like that?

psharpNumerex commented 10 years ago

It's clearly something within that test suite causing it, but I'm having trouble narrowing it down.

What frustrating is that the behavior is different on our Bamboo CI server.

Teaspoon running mobile_tests suite at http://127.0.0.1:57287/teaspoon/mobile_tests ......................................................................................................

Finished in 0.96800 seconds 102 examples, 0 failures

Teaspoon running web_tests suite at http://127.0.0.1:57287/teaspoon/web_tests Failed to load: http://127.0.0.1:57287/teaspoon/web_tests?reporter=Console

However, if I run just the web_tests suite on Bamboo then I see the same behavior as local, where it outputs the Failure to load message AFTER the tests have run.

jejacks0n commented 10 years ago

I understand it's frustrating. are you doing anything odd with window.load, or long lived incomplete ajax or image loads? I've not seen this issue come up before.

psharpNumerex commented 10 years ago

Bingo, I think you hit it. Or at least part of it. I tracked it down to a fixture.load by commenting out all actual tests in the file and just leaving that statement. I removed the two img tags in the file and the offending (and empty) file now runs w/out the Failure to load.

The images are not that terribly large, however

psharpNumerex commented 10 years ago

Interesting.

Removed tests from suite until it would run the suite w/out the error. Run the file on its own and consistently see the error. Remove the img tags from the fixture, consistently run the file on its own w/out the error. Run the suite again and the error is still there. Remove the file from the suite and the error disappears.

Something funky clashing with the requires, possibly?

jejacks0n commented 10 years ago

If you track it down to something I can fix, I will fix it. =) It's a complex issue.

I do appreciate your effort and ability to communicate what you're experiencing and why.

psharpNumerex commented 10 years ago

I imagine there's a hidden land mine somewhere in the testing code we've written.

Seeing some of this in the logs:

Started GET "/teaspoon/undefined" for 127.0.0.1 at 2014-04-18 17:01:17 -0500 Processing by Teaspoon::SuiteController#show as / Parameters: {"suite"=>"undefined"} Completed 500 Internal Server Error in 0.6ms

So I'm thinking a fixture loading may be getting munged somewhere, but the inconsistent behavior of running the file vs the suite is a head scratcher

jejacks0n commented 10 years ago

are you preloading your fixtures? might want to try that.

psharpNumerex commented 10 years ago

Tracked it down, it was an ajax call on a js file load. Thanks for all the help!

Would there be any way to get more info out of the Failed to load? I was trying to think of a clean way to have it output at least the test file that was the culprit.