Let's say you're working on a rails app that has a lot of initializers that call out to various external systems at startup.
When running rspec with rspec-rails it runs all the initializers, even if your test is something simple that doesn't require rails infrastructure.
I know you can use Spork to only incur this cost once but is there a way to not incur it at all? It seems silly to load up all of rails just for a simple PORO spec.
Don't use spork. If you want to use a preloader, look into zeus or spring.
You don't need to load your entire rails environment to test things that don't depend on rails. This can be as simple as explicitly requiring the dependencies you need per spec, or creating an entirely separate minimal_spec_helper for non-rails things or a rails_spec_helper for rails things.
Do your initializers really "call out to various external systems"? If this is what it sounds like, that your initializers are making external network/HTTP calls, that sounds like a terrible idea.
Related
A contractor for our startup installed the Selenium-based Nightwatch testing framework, since our stack is React-heavy. But he told me that it could even be used to test our Rails code. A new contractor said, to the contrary, that Nightwatch couldn't do unit tests of our Rails controllers and models (which makes sense to me).
Who is right? Do you suppose the first programmer had in mind just that we would do end-to-end testing (certain inputs lead to certain outputs), and that we need not test the details of the Rails code? Do we, as I suspect and as the new contractor asserts, need RSpec or some other Ruby-based testing framework to handle our Rails code, if we want to be a TDD shop?
Yes it can be used to test Rails. But only from the outside (only through the Browser). So no Unit/Controller/View Tests.
You'll need MiniTest or Rspec for those.
My two cents (also see comment by #SteveCarey): Since I prefer to stick with what comes with Rails and use as little external tools as possible:
Have a look at System Tests that have been introduced with Rails 5.1 or, if you are on a older version, see if you can write those tests using Capybara/Integration Tests.
Update:
You can find more details on testing framework here: http://guides.rubyonrails.org/v4.1/testing.html#brief-note-about-minitest
It was Test::Unit and nowadays is Minitest. But the basics are the same so it does not really matter.
Another popular testing framework is RSpec. Which you can use instead of Minitest/TestUnit if you want to. I prefer Minitest but there are pros and cons for both frameworks.
Rails 4.2 came with Unit-tests, Functional/Controller-tests and Integration-tests. The built in thing that resembles Nightwatch the most are Integration-tests: http://guides.rubyonrails.org/v4.1/testing.html#integration-testing
You can also look at libraries such as Capybara (https://github.com/teamcapybara/capybara) which calls itself an Acceptance Test framework. It integrates nicely with TestUnit/Minitest/Rspec.
While rspec automatically creates specs for any helpers created by the Rails generators, I was wondering if other Rails developers find it important/useful to spec the helpers in real-world or if they often don't bother, since the helpers are often tested by proxy through testing of the components that use them?
Personally I do test helper methods, because I like to test them in isolation. If the following feature specs fails I know I probably made a mistake in my test setup because I already ensured that the helper method works.
It is also easier to test all possible scenarios. If you want to test all possibilities as part of a whole you need more test setup and sacrifice performance.
Ideally, you want to write tests for everything, but in real world with time constraints, it is not uncommon to skip simple helper method tests because you implicitly test them while building the actual test. In the same way some developers may skip private method tests.
Currently I'm writing a unit test a method which the only thing that I need from Rails is to use the url helper methods, like 'product_url'
I really don't want to load the whole Rails environment, as we all know it's a bit expensive, just to be able to run the url helper methods.
Is that a way of loading only part of Rails environment, just the necessary to run these methods?
Thanks!
Alex
As far, as I know it is not so easy. But you can use spork server to have rails testing environment in memory to make your tests run fast and smooth.
I'm with #Nick_Kugaevsky– in fact, I'm a lot more negative than him. I just don't think it's possible. To have the concept of a helper, Rails has to load ActionPack, which is not very useful by itself. I guess you could figure out a way to work directly with ActionPack, but I'd be extremely surprised if that were possible.
You can try to mock all *_path in your tests.
I am writing a ruby scheduler - namely rufus-scheduler and there are commands i need to write in the initializers section inside the config folder to perform a task every 1 minute or so. I am trying to access a method from a module within this. So my code would look like
scheduler.every("1m") do
puts("HELLO #{Time.now}")
ModelName.methodname("WHAT ARE YOU DOING")
end
This somehow doesn't perform the necessary operation in the model. Also im not sure if this is the right way to do things - such as call a model inside a config file. Is there a better place to put this code in the Model? Or is calling a Model within config files perfectly good practice. I looked over the internet to see the usage of different types of files in ruby but couldn't find a proper material. Any help or guidance appreciated.
If you want to access models from stand-alone tasks the best way is to use the rails runner wrapper. For example, you'd call your script as:
rails runner call_model.rb
This loads in the Rails environment and then executes your script, eliminating the need to do that yourself. Models on their own will not work since they are lacking the context of Rails.
If that's not sufficient, you may need to load the Rails environment more directly by including config/environment.rb into your rufus-scheduler configuration.
It sounds like you actually want a real scheduled action of some sort. config files are for configuration, not for actual working code of that sort.
There are tons of ways to run scheduled tasks in rails.
google "rails daemons" or "rails scheduled tasks" to start you off.
Here's a good list of scheduled-task best practices using cron:
A cron job for rails: best practices?
I just get started using BDD in Rails application, but I'm not sure what are best practices and workflows? And what other things that I really need for testing for my project such as step definitions, controllers, models, and views? Do I need to test all of those?
I generally think of Cucumber as a way to do integration testing on your application. Combined with Webrat, you can test user workflows, views and so on in a great way. For unit tests, you'll want to go down to a lower level and test your models just with rspec. You may also want to do some functional tests on the controllers, and I probably wouldn't use Cucumber for that either.
Here are a couple of videos:
http://confreaks.com/videos/72-mwrc2009-bdd-with-cucumber
http://rubyconf2008.confreaks.com/rspec-and-cucumber.html
Ryan Bates has some good Railscasts on these topics:
Beginning with Cucumber
Webrat
More on Cucumber
This may be a matter of taste, but having tried out Rspec I prefer using the built-in Rails testing framework along with a gem called Shoulda. In my opinion, that combination lets you write much clearer, more succinct and understandable tests than Rspec by far. But not everyone would agree.
Shoulda's contexts let you organize your tests into logical hierarchies which really helps when you're trying to test all the possible paths some crazy, branching situation, like user logs in with right pw, wrong pw, right pw but registration not confirmed, etc.
In addition be sure to install the ZenTest gem. That lets you just execute the command $ autotest and your tests will run automatically every time you change a file.