search

jejacks0n / teaspoon

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

Taking too much time to generate coverage #186

Closed Sanjith closed 10 years ago

Sanjith commented 10 years ago

I'm using rails 3.2.9 and ruby 1.9.3, while executing bundle exec teaspoon --coverage-reports=text,html it is starting the server but taking too much time (more than 30 min) for running

Log: Starting the Teaspoon server... listening on addr=0.0.0.0:57773 fd=12 worker=0 spawning... master process ready worker=0 spawned pid=17391 worker=0 ready Teaspoon running default suite at http://127.0.0.1:57773/teaspoon/default

Can you tell me whether I'm doing wrong or I need to set any configuration for timeout?

jejacks0n commented 10 years ago

30 minutes? or 30 seconds?

Sanjith commented 10 years ago

30 minutes or some times it hung up.

Sanjith commented 10 years ago

and also I'm getting this type of error after generating coverage

[BUG] Segmentation fault ruby 1.9.3p429 (2013-05-15 revision 40747) [x86_64-linux]

-- Control frame information -----------------------------------------------

-- C level backtrace information ------------------------------------------- /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x1904e6) [0x7f0d75d754e6] vm_dump.c:796 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x62931) [0x7f0d75c47931] error.c:258 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(rb_bug+0xb3) [0x7f0d75c487d3] error.c:277 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x11e2d6) [0x7f0d75d032d6] signal.c:633 /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7f0d7585b4a0] array.c:1322 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(st_lookup+0xe) [0x7f0d75d0b13e] st.c:326 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x17e167) [0x7f0d75d63167] vm_method.c:374 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x185cbb) [0x7f0d75d6acbb] vm_insnhelper.c:1371 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x186399) [0x7f0d75d6b399] vm.c:1236 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x187211) [0x7f0d75d6c211] vm.c:686 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x189f5c) [0x7f0d75d6ef5c] vm_insnhelper.c:404 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x181cab) [0x7f0d75d66cab] insns.def:1018 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x186399) [0x7f0d75d6b399] vm.c:1236 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x187211) [0x7f0d75d6c211] vm.c:686 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(rb_exec_end_proc+0x1fa) [0x7f0d75c5034a] eval_jump.c:129 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x6b3fa) [0x7f0d75c503fa] eval.c:92 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(ruby_cleanup+0x131) [0x7f0d75c50571] eval.c:133 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x19654e) [0x7f0d75d7b54e] thread.c:549 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/lib/libruby.so.1.9(+0x19684c) [0x7f0d75d7b84c] thread_pthread.c:657 /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7f0d7560fe9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f0d759193fd] rational.c:1817

-- Other runtime information -----------------------------------------------

and so on...

00400000-00401000 r-xp 00000000 08:01 21639571 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/bin/ruby 00600000-00601000 r--p 00000000 08:01 21639571 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/bin/ruby 00601000-00602000 rw-p 00001000 08:01 21639571 /home/sanjithkumar/.rvm/rubies/ruby-1.9.3-p429/bin/ruby 008e5000-0496d000 rw-p 00000000 00:00 0 [heap] 7f0d60000000-7f0d60021000 rw-p 00000000 00:00 0 7f0d60021000-7f0d64000000 ---p 00000000 00:00 0 7f0d679b9000-7f0d679be000 r-xp 00000000 08:01 6036551 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f0d679be000-7f0d67bbd000 ---p 00005000 08:01 6036551 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f0d67bbd000-7f0d67bbe000 r--p 00004000 08:01 6036551 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f0d67bbe000-7f0d67bbf000 rw-p 00005000 08:01 6036551 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f0d67bbf000-7f0d67bc1000 r-xp 00000000 08:01 6036540 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f0d67bc1000-7f0d67dc1000 ---p 00002000 08:01 6036540 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f0d67dc1000-7f0d67dc2000 r--p 00002000 08:01 6036540 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f0d67dc2000-7f0d67dc3000 rw-p 00003000 08:01 6036540 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f0d67dc3000-7f0d67dff000 r-xp 00000000 08:01 2625038 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7f0d67dff000-7f0d67ffe000 ---p 0003c000 08:01 2625038 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7f0d67ffe000-7f0d67fff000 r--p 0003b000 08:01 2625038 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7f0d67fff000-7f0d68000000 rw-p 0003c000 08:01 2625038 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7f0d68000000-7f0d687ab000 rw-p 00000000 00:00 0 7f0d687ab000-7f0d69fd4000 rw-p 00000000 00:00 0 7f0d69fd4000-7f0d6c000000 ---p 00000000 00:00 0 7f0d6c147000-7f0d6c164000 r-xp 00000000 08:01 6031799 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0d6c164000-7f0d6c363000 ---p 0001d000 08:01 6031799 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0d6c363000-7f0d6c364000 r--p 0001c000 08:01 6031799 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0d6c364000-7f0d6c365000 rw-p 0001d000 08:01 6031799 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0d6c365000-7f0d6c38b000 r-xp 00000000 08:01 2624971 /lib/x86_64-linux-gnu/libexpat.so.1.6.0 7f0d6c38b000-7f0d6c58b000 ---p 00026000 08:01 2624971 /lib/x86_64-linux-gnu/libexpat.so.1.6.0 7f0d6c58b000-7f0d6c58d000 r--p 00026000 08:01 2624971 /lib/x86_64-linux-gnu/libexpat.so.1.6.0 7f0d6c58d000-7f0d6c58e000 rw-p 00028000 08:01 2624971 /lib/x86_64-linux-gnu/libexpat.so.1.6.0 7f0d6c58e000-7f0d6c683000 r-xp 00000000 08:01 2622117 /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1 7f0d6c683000-7f0d6c882000 ---p 000f5000 08:01 2622117 /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1 7f0d6c882000-7f0d6c883000 r--p 000f4000 08:01 2622117 /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1 7f0d6c883000-7f0d6c884000 rw-p 000f5000 08:01 2622117 /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1

and so on...

jejacks0n commented 10 years ago

bad compile of phantomjs or istanbul? what's the behavior like without the reports -- working fine otherwise?

Sanjith commented 10 years ago

yes, without reports it is working fine. What may be the solution for this bad compilation?

jejacks0n commented 10 years ago

can you run istanbul via the command line? eg. istanbul help

Sanjith commented 10 years ago

Yes, I did

jejacks0n commented 10 years ago

Not sure then. I can't really replicate your setup and see it. It just shells out to istanbul with the output from the test run. That must be bombing in istanbul, as I can't really see any exceptions raised from teaspoon.

Sanjith commented 10 years ago

Yeah, I found the failure case for this compilation..

I have jquery related files under jQuery folder. For ignoring those files I put the suite.no_coverage like below..

suite.no_coverage = [%r{/lib/ruby/gems/}, %r{/vendor/assets/}, %r{/support/}, %r{/(.+)_helper.}, %r{/jQuery/}, %r{/javascripts/jasmine_examples/}]

When I removed jQuery from the suite.no_coverage then there is no compilation failure. But, coverage includes jquery files also.

suite.no_coverage = [%r{/lib/ruby/gems/}, %r{/vendor/assets/}, %r{/support/}, %r{/(.+)_helper.}, %r{/javascripts/jasmine_examples/}]

jejacks0n commented 10 years ago

yeah, there's some room for improvement in istanbul. I have seen it fail, and sadly it doesn't fail gracefully. Though it's the best solution I could find.

jejacks0n commented 10 years ago

Also -- you could consider using jquery-rails, as it will be automatically ignored since the source file will be in gems.

Sanjith commented 10 years ago

Yeah, Now, I'm trying that one. And what about server running time?

jejacks0n commented 10 years ago

it's still running really long? I thought you said it hung when you ran istanbul.

Sanjith commented 10 years ago

No, when I ran teaspoon coverage (bundle exec teaspoon --coverage-reports=text,html), taking too much time to generate coverage.

jejacks0n commented 10 years ago

I thought you said you had it figured out.

Sanjith commented 10 years ago

I figured out bad compilation, which is giving lot of errors... but not the server running time...

jejacks0n commented 10 years ago

I don't know how else to help you.. it seems like istanbul is breaking on some of your javascripts.. you should remove all but the code that you're testing and implementing.. are you testing jquery? No, probably not, because that would just be silly.

So it shouldn't be included in the coverage reports. As far as teaspoon taking a long time, it's not.. it sounds like istanbul is taking a long time. And for that, I'm sorry, but also not responsible.

You can do something like this in your teaspoon_env:

require "teaspoon/coverage"

module Teaspoon
  class Coverage
    def generate_reports(&block)
       File.open("coverage.json", "w") { |f| f.write(@data.to_json) }
       puts "coverage was generated.. go check it and run it with istanbul manually."
    end
  end
end
jejacks0n commented 10 years ago

@Sanjith That's a bummer. It sounds like it runs fine without coverage reports. correct? If so that's great, and I'll stop trying to help you figure out why your coverage reports bomb out.

Sanjith commented 10 years ago

Yeah, Thank you for your help here :-)