The specs for my rails project have been really slow lately. I did a git bisect to see if I could determine what has been slowing it and I found that certain commits that were previously running just fine are now just as slow as the current HEAD.
This leads me to believe that my problem is being caused by a gem updating or something else that's not under my source control. The problem still occurs on other dev machines so I don't think it's my personal environment either.
What's the best way to track down my slowest tests and then figure out what's slowing them down so much?
This flag will tell you which tests are the bottlenecks:
$ rspec --profile
Check out the test prof gem:
https://test-prof.evilmartians.io/#/?id=recipes
https://github.com/palkan/test-prof
Related
Is there any way to retest previously broken tests?
So, say, I run rspec and several tests in different files and directories fail.
I fix something and now I have to manually specify all files and folders I want to retest or run tests for whole project again(It takes considerable amount of time for big projets).
What I was looking for is something like a flag
rspec --prev-failed-only
I realize that such flag would require considerable amount of additional actions from rspec, like storing results of previous tests and so on. But I think it would be super convenient to me.
Is there any such(or similar) tool/gem?
rspec-rerun gem does what you want : https://github.com/dblock/rspec-rerun
https://github.com/rspec/rspec-core/issues/456 has a good discussion on the topic of making rspec itself be able to rerun failed tests.
On the Giant Robots podcast, Sam Phippen of the core team mentioned this feature is due to be added to RSpec soon.
In case anyone else finds this, a month after the question was asked (open source <3 ) rspec 3.3 introduced the --only-failures option, also the delightfully handy --next-failure (-n) option. rspec --help for more info.
I'm using Test::Unit on a large app with a large number of gem dependencies (>75). I'm trying to develop using BDD, but it takes minutes for the app to load it's dependencies before it can run the tests. Is there a way to preload the dependencies and just auto-run the test on changes, or a similar solution?
I would look into Spork. It works wonders.
https://github.com/sporkrb/spork
https://github.com/sporkrb/spork-testunit
I am using RSpec and there's a great tool for it, called Spork. It basically loads your app once and then just reloads modified parts. If you combine it with Guard, you get "continuous testing". That is, you hit 'Save' in your editor and tests start executing, giving you instant feedback. This still amazes me after some months :)
Edit
As #THEM points out, there's a plugin for Spork to support TestUnit. You should look into it.
There was also an interesting article about test speed on the 37Signals blog a while back. Might be of interest even if you end up going with Spork or another solution.
I'm looking to speed up our rails application tests. We're already around 600 tests, it's getting higher and it's starting to take a long time to run.
I know there are some tools to speed up the tests. Some we are already using, some we will start using, and im quite sure some we can't use due to our rails version (2.3.8).
But I came here for a different reason. Few weeks ago, I started using a computer that didn't run our tests for a while, and the tests run really really fast. Instead of taking the usual 20-30 minutes, it was completed within 5-7 minutes, if not less.
At first I thought something is wrong, but the more times I run - it started to become slower and slower until it took me 20-30 minutes to run, again.
Now the tests were the same tests, tools were and are the same. I can't think off anything dramatically that changed, besides the fact that I haven't run the tests for a while (few weeks~) and then run again. Could it be something related to tmp files or any of this sort that can be deleted or tweaked to get our tests to run faster?
Thanks for your help.
Some tips to speed up testing:
Make sure you are using transactional fixtures
Try only initializing instead of persisting objects in the database
put config.whiny_nils = false on your config/environments/test.rb
If you're using Devise, put config.stretches = Rails.env.test? ? 1 : 10 on your config/initializers/devise.rb
Upgrade to 1.9.3
PS: Just saw you're using Rails 2.3.8, so this won't work for you, but I'll leave it here in case someone wants to use:
Put this patch into your application (be sure to remove it when upgrading to 3.2)
When I run my cucumber scenarios as a whole, or with the command: cucumber
I get 7 failing steps. When I run them individually with the work in progress tag they pass fine.
I don't think it's a database state issue.. I'm running with transactions and I also tried running without and cleaning the database with database cleaner.... still does not help.
I tried to run the debugger but it does not seem to work when I run the command cucumber. It only works when I run with the work in progress tag: cucumber -p wip
I thought it might be that things are running too fast and capybara is not checking things properly?
Any ideas?
Eureka! I've been having this same problem for awhile now - my tests got slower and slower the more I added - also, some tests would fail randomly, but only when run as a whole suite - after my tests would finish I would just run the feature again and viola! all passing. Very frustrating - but the MOST frustrating part was the speed - recently I upgraded to snow leopard and compiled everything to 64bits. The result? My tests went from taking 7 minutes to 32!
There's a clue in that however - 64 bit apps use more memory to do do the same thing, apparently - however, when I was running my tests the memory on my machine was never coming close to maxing out. Hint #2? Webrat was going fast, it was only when using culerity/celerity to test javascript that things were really slowing down.
After poking around I found out that jruby tells java to give it a maximum 'heap size' of 512 mbs. JRuby allows you to set java options when it is invoked, and culerity allows an environment variable to invoke jruby any way you like. Sure enough, around that time, java would stop consuming memory and the processor would try to set itself on fire. So are you ready? Here it is:
JRUBY_INVOCATION="jruby -J-Xmx1024m" cucumber
That increased my heap size to a gigabyte and my test time dropped down to 7 minutes! Is that it? Did I get it? I sure hope it helps!
We've recently upgraded our Rails application.
To be extra sure everything works, I've tried to get the tests and specs of the various used plugins (26 at current count) to work, thinking then to add those to our continuous integration, which only runs the main application's specs.
I've run into a lot of problems even getting the specs/tests to run at all, not even getting to any individual test failures. For example, I've run across this problem: http://rails_security.lighthouseapp.com/projects/15332/tickets/7-rake-spec-plugin-fails-on-rails-2-1 (thanks by the way for that ticket, even though the issue wasn't fixed).
So the question is: Are we unusual in that we've ever cared about running plugin tests ? It doesn't seem to feature much here on SO. My nagging feeling is that they should be run as much as the main specs, but you could also argue that since the main specs work, the plugins must also work.
Alot of it depends on the plugin/gem being used.
If I know the author/community of the gem is competant I will skip the tests and simply use the latest stable release and freeze that gem. I will then track the progress of the development using github.
If the plugin/gem is written by an unknown party I will run the tests and freeze the gem/plugin and again monitor the development.
Sometimes however I will write my own contributions to the gem and fork the code. I will clone the repo in github and base my installations from that. At which point any and all changes result in a complete test run.
With all things in the open source world there is an element of trust between the creator and the users of those pieces of code. The tests themselves don't tell me much about the codebase, it shows there are tests and thats it. Do they test everything ? Are there edge cases ? . Its this element of trust I have with certain developers in the community that means I forgo worrying over running tests for those gems.
Its a slippery slope testing everything, where does it stop ? Would you test rails every release ? No, you assume the community has done this for you already.