Although Zeus takes a less aggressive approach than Spork, one major drawback is the fairly strict usage requirements Ruby 1.9.3+ (recommended using backported GC from Ruby 2.0) as well as an operating system that supports FSEvents or inotify is required. The spec_helper does not need to be modified, however, you will have to run `zeus start` in a console to start the zeus server before running your tests. Here you can find a Guardfile configuration for using Zeus.
#Rspec allow raise error code#
If you have some code examples using Spin or any other solution let us know. The drawback of using Spork is that it aggressively monkey-patches your code and you could lose some hours trying to understand why a file is not reloaded. With this configuration you will reload the whole app if a preloaded file (like initializers) change and you will run the single tests really, really fast.
Here you can find a spec helper and a Guardfile configuration based on Spork. Those solutions will preload all libraries you (usually) do not change and reload controllers, models, view, factories and all the files you change most often. To solve this problem use solutions like Zeus, Spin or Spork. This can take time and it can break your development flow. When running a test on Rails the whole Rails app is loaded. Find an example vim keybinding here and learn more about guard-rspec. Then, you can use a rake task to run the entire suite before pushing code. Sometimes your TDD workflow works best with a keybinding that makes it easy to run just the examples you want when you want to.
Guard is a fine tool but as usual it doesn't fit all of your needs. Good describe 'GET /devices' do let! ( :resource ) end
0 kommentar(er)
