So despite the fact I've created 3 rails apps of increasing complexity on my own. I haven't deployed any of them. I decided tonight to create another app (Well really redoing an older app with some new things I've learned) and it hit me.
I really don't completely understand the gemfile, well I do but I second guess myself quite a bit. It seems obvious and straightforward, yet here I am on Stackoverflow asking for clarification or at least to ease my second guessing.
My understanding of Gemfile is as follows.
Default are gems that are gems that will persist across all environments (Test, dev, and production), test gems only live in the test environment, dev gems in the development environment, and production gems in the production environment.
Up to this point I've kinda just been throwing most of my gems in the default, but I want to correct this before I make it a habit. I like using rails' built in testing (I know, boo, hiss) and I use minitest reporters, guard minitest and minit backtrace as my helpers. I'm told best practice would be to put them and any gem related to testing in the obvious test environment. I don't think I've ever setup a test db, much less used test environment. Why wouldn't those go under the development environment? Or is it when you run tests that's using a test environment even if you didn't explicitly create one?
Is it when you run tests that's using a test environment even if you didn't explicitly create one?
$ rails console test brings you to the test environment
Related
Can someone explain to me what the Rails environments are and what they do? I have tried researching myself, but could not find anything. From what I gather, the environments are:
Development
Productions
Test
Each "environment" is really just a config. You can launch your app in various different modes, and the modes are called "environments" because they affect the app's behaviour in lots of different ways. Ultimately, though, they are just configs.
BTW you can't have looked very hard when you looked "everywhere", because i just googled "rails environment" and the top result was this
http://guides.rubyonrails.org/configuring.html
which is the official explanation of configuring the rails environment.
From what you have provided in your question, it seems that you are asking:
"What are the difference between each environment configuration in Rails?"
Rails comes packages with 3 types of environments. Each have its own server, database, and configuration. See Rails Guides: Configuration for more information on options available to you.
Setting up the environment
To set your Rails environment, you will want to enter in command line:
export RAILS_ENV=<env>
Where <env> can be test, development, or production. Setting this environment variable is crucial, as it will determine what gems are installed, or what env is touched when running rails console or rails server.
Included in configuration is the gemset used for the app. When you run rails new, you will find a Gemfile with groups test, development, and production. These groups correspond to the environment currently set. When the environment is set to one of those, running bundle install installs all gems related to that group (and gems not listed in a group).
Included environments
test is designed for running tests/specs. This database will likely be bare bones, except for seeds you may call before running the suite. After each test is complete, the database will rollback to its state before the test began. I do not recommend launching rails server, as running tests (via MiniTest or RSpec) will do this for you, and close the server once the suite is finished.
development allows you to "test" your app with a larger database, typically a clone of production. This allows you to test actual real-world data without breaking production (the version that customers or end-users will experience). To view the development environment in action, change the RAILS_ENV and launch rails server. This is good for deciding how you want your pages to look (CSS, HTML). It is also good practice to briefly "test" your app yourself, clicking around making sure everything "looks" good and the JavaScript works.
production is reserved for the customer and end-user. Configuration includes the actual domain of the app, which ports to use, and initializers or tasks to run. You do not want to play around with your database, as it may be customer-impacting. Ideally, the app should work as best as it can, since this is considered your "final product."
Here are some good reads about Rails Environments
http://teotti.com/use-of-rails-environments/
and
https://signalvnoise.com/posts/3535-beyond-the-default-rails-environments
good luck !!
I had a problem in a UAT environment because there was a configuration problem in config/environments/uat.rb
Is there a way to test/validate environment files like uat.rb or production.rb to catch errors before deploying?
Loading the files with require in rspec might be a problem because it might affect other tests, not sure about this.
Thanks,
Before deploying on production, I always run my code in production mode on my development machine using environment flag:
rails s --environment=production
You have to choose what tests you write based on the projected ROI (return on investment) of writing those tests. Tests aren't free - far from it. They take time to create and maintain, they junk up your project, etc. Only write tests that you judge to be useful in the future.
I've had plenty of issues with configuration in the past and the solution has always been KISS - Keep it simple stupid. Most apps should require very little configuration, thus are hard to mis-configure.
Today I am going to get as far as I can setting up my testing environment and workflow. I'm looking for practical advice on how to setup the test environment from you guys who are very passionate and versed in Ruby Testing.
By the end of the day (6am PST?) I would like to be able to:
Type one 1-command to run test suites for ANY project I find on Github.
Run autotest for ANY Github project so I can fork and make TESTABLE contributions.
Build gems from the ground up with Autotest and Shoulda.
For one reason or another, I hardly ever run tests for projects I clone from Github. The major reason is because unless they're using RSpec and have a Rake task to run the tests, I don't see the common pattern behind it all.
I have built 3 or 4 gems writing tests with RSpec, and while I find the DSL fun, it's less than ideal because it just adds another layer/language of methods I have to learn and remember. So I'm going with Shoulda. But this isn't a question about which testing framework to choose.
So the questions are:
What is your, the SO reader and Github project committer, test environment setup using autotest so that whenever you git clone a gem, you can run the tests and autotest-develop them if desired?
What are the guys who are writing the Paperclip Tests and Authlogic Tests doing? What is their setup?
Thanks for the insight. There are tons of resources describing how to use the different testing frameworks, but almost nothing on the actual setup and workflow. Looking for answers that will make me a more effective tester.
The most common convention probably is rake test, rake spec, or maybe even just rake.
Of course, there is no question that this will fail with many projects, in particular the ones without tests or specs.
It might be possible to parse the output of rake -T if a Rakefile is there, and act on that, but there really is no way you will cover ALL projects on GitHub.
Up until now I've been deploying Rails apps to our Apache/Passenger setup using a simple Rake task that I wrote. I haven't tried to mess around with Capistrano or Vlad the Deployer.
However, now more developers are coming on board, and I'm interesting in arranging things so that the deployment process runs the tests first and won't deploy unless they all pass. So I'm revisiting the question.
It's been a while since I looked into this. What are most people doing these days? Still using Capistrano? Writing individual Rake tasks? Something else?
Capistrano is still the standard for typical Rails deployments, yes.
We're using Capistrano and Integrity for a CI server. Integrity is quite easy to hack on and you could really easily set it up to automatically deploy on a pass of all tests, and I'd recommend all of them as good tools; Integrity has plenty of plugins available. We currently have Integrity spit out each build's pass/fail and code coverage % into an IRC channel and manually deploy.
I have a terrible Rails test startup time. When running a single functional test that may take 2 seconds to run, the total time from execution to returning to the command line could be up to 10-15 seconds.
There are two gems I know are definitely getting in the way. A Facebook and Flickr gem (Facebooker, Flickraw).
Facebooker will always print the following message when any test is run:
/vendor/gems/facebooker-0.9.5/lib/facebooker.rb:23: warning: already initialized constant VERSION
And Flickraw appears to be making a network connection every single time to retrieve a list of what I believe are API calls it can make.
Can I selectively turn these gems off during test time? I'd really like to get my test run as close to how long the actual test takes to run as possible. Also, I have tried the rails_test_server gem and am having some difficulties as this is a very large project and the gem is hitting some conflicts somewhere in the project that I haven't resolved. But I believe this Facebook and Flickr gem problem should have a resolution somewhere.
How do you use those gems? Do you have a require somewhere in your config/environment.rb? If so you could add those requires to the development and production environment files, but not to the test environment file.
If you're able to run your application without loading all of the gems, that's probably a good indication that either you didn't really use the gem in the first place, or your tests are insufficient.
But yeah, the right way of doing this would be to move the gem loading into the development and production specific environment files.