I have the following line in my Sinatra app:
Mongoid.load!('./config/database/mongoid.yml')
This is nice, but I don't want to keep my connection details in a YAML file, and add it to .gitignore. I want to keep them in ENV.
I was able to bypass this in the past by adding stuff like username: <%= ENV['MONGODB_USER'] %> to the YAML config file, then reading it as ERB, saving it and reading it again with Mongoid.load! before Heroku wiped the disk. Needless to say, that's pretty nutty.
All I could find is the definition of .load! over here and it doesn't look like there's any way around this.
Is there some hidden way to programmatically configure Mongoid connections?
Thanks in advance.
Building on mu's answer:
You can give Mongoid a hash to use for initialization like this:
Mongoid.load_configuration(clients: {
default: {
database: database,
hosts: [ host ]
}
})
Note that the hash you pass to load_configuration is not expected to start with an environment key like you would normally have in mongoid.yml.
Mongoid.load! doesn't do very much:
def load!(path, environment = nil)
settings = Environment.load_yaml(path, environment)
if settings.present?
Sessions.disconnect
Sessions.clear
load_configuration(settings)
end
settings
end
All it does is a bit of bookkeeping, loads the YAML, and hands off to load_configuration to do the heavy lifting. There's nothing stopping you from building the settings Hash by hand and calling Mongoid.load_configuration yourself.
Related
I'm writing automated tests using Selenium WebDriver with Ruby. So, I'm thinking to keep elements in another file and actual code in another file. And for Ruby, I found yaml gem which allows to store data and access it. Hence I stored elements in lib.yml and test code in test.rb as following:
lib/lib.yml
homepage:
frame: 'mainPage'
email: 'loginPage-email'
password: 'loginPage-password'
login_button: 'btnLogin'
tests/test.rb
require 'selenium-webdriver'
require 'yaml'
driver = Selenium::WebDriver.for :firefox
driver.get 'http://www.abc.com'
config = YAML.load_file('./lib/lib.yml')
driver.switch_to.frame(config['homepage']['frame'])
email = driver.find_element(:id, config['homepage']['email'])
password = driver.find_element(:id, config['homepage']['password'])
email.clear
email.send_keys 'abc#gmail.com'
password.clear
password.send_keys 'password'
driver.find_element(:id, config['homepage']['login_button']).click
driver.quit
This way maintenance becomes easier. I just want to make sure if doing so is a good way or not. I'm asking because I'm trying this first time and don't know what difficulties I'll run into if I choose this for larger project.
I know, using Page object model, we can achieve same thing. But I don't know about Page object. So should I avoid using yml gem and directly go for page object gem?
Also, can someone explain how using yml will not be good idea(if it's not)?
Note:
In above code, config['homepage']['something'] is repetitive code. I'll write method to avoid repetition for that.
Yeah this definitely is useful... It keeps the changes to minimum when there is UI change in future.. You always have just one place to edit... Is there any data you have to pass to your code? How are storing the automation data passed to your test.. The only concern might be you might end up with too many yaml files which could be difficult to keep track...
In your specific case I don't see how this adds much value. Half of the settings (frame, login_button) won't change for your tests, so I suggest leaving them directly in the code where they are used. The html structure is not something that usually changes.
The other two values (email, password) seem like they might change when you want to try out different users (i.e. different cases). If you have one test with several example inputs then I suggest using a more readable solution as Cucumber.
(I'd suggest using capybara anyway for testing browser interaction, as it abstracts away many details of the underlying driver)
Apart from that, yaml is usually the ruby way for storing configuration.
I added one more step: Declared locator (id, name etc) in the yaml itself.
Ex:(yaml)
Declared env.rb which load the environment from yaml files
env.yml:
LOGIN:
UserName: {id: UserName}
Password: {id: Password}
RememberME: {id: RememberMe}
Submit: {xpath: "//input[#value='Log On']"}
Then added "pages\Login.rb"
#Loads all objects from yaml
def get_objects
username=#browser.find_element( $object_array['LOGIN']['UserName'])
password=#browser.find_element( $object_array['LOGIN']['Password'])
remember_me=#browser.find_element( $object_array['LOGIN']['RememberME'])
submit= #browser.find_element($object_array['LOGIN']['Submit'])
end
#Added methods in this class like
def loginas(uname,pass)
username.send_keys uname
password.send_keys pass
remember_me.click
submit.click
end #loginas_siteadmin
Created Tests file Login_tests.rb
lp=LoginPage::new(#browser)
lp.navigate
lp.loginas('SiteAdmin','password123')
This way your scripts and maintainable and most importantly you are free of any other external gem or dependency.
I'm working with some code that uses the fakeredis gem for specs, but whenever I run those specs from a REPL, fakeredis stays around and commands like Redis.new will just give me fakeredis. I need to be able to disable it to be able to access the real redis store again.
Is there a way to disable/enable it in the REPL?
Two solutions, either remove the fakeredis memory class:
Redis::Connection.drivers.delete_if {|d| d == Redis::Connection::Memory }
or append the Ruby adapter again:
Redis::Connection.drivers << Redis::Connection::Ruby
Source: https://github.com/guilleiguaran/fakeredis/issues/63
So I've been trying to figure this out, and the best solution I can came up with his global variables - but that seems so dirty and 1974 - Am I missing a feature of Rake/ Test::Unit?
I have a Rake file in which I'm running tests:
Rake::TestTask.new(:test) do |t|
t.test_files = FileList['test_*.rb']
end
and test_1.rb has something like this:
require "test/unit"
class TestStuff < Test::Unit::TestCase
def setup
#thingy = Thing.New(parameter1, parameter2)
end
def test_this_thing
#thing.do()
end
end
My problem is, Thing.new() requires arguments, and those arguments are specific to my environment. In reality, I'm running Selenium-WebDriver, and I want to pass in a browser type, and a url, etc... sometimes I want ff, othertimes I want chrome... sometimes this URL, sometimes that... depending on the day, etc.
The simplest thing seems to do something like:
#all that rake stuff
$parameter1 = x
$parameter2 = y
and then make Thing.new() look up my global vars:
#thingy = Thing.New($parameter1, $parameter2)
This seems sloppy.. and it just doesn't feel right to me. I'm still trying to get this 'test harness' up and running, and want to do it right the first time. That's why I chose Rake, based on a lot of other feedback.
Keep in mind, I'll probably have 100's of tests, ultimately, and they'll all need to do get this information... I thought Rake was good at making sure all of this was easy, but it doesn't seem to be.
Where did I go wrong?
I have used YAML files to store my configuration (browser config, environments including URLs, etc).
You can also use an environmental variable to define simple configurations. You can access environmental variables via ENV['foobar'] in Ruby.
So, for example, my browser call might look like this inside my setup method:
driver = Selenium::WebDriver.for (ENV['SWD_BROWSER'] || "firefox").to_sym
and in my Rake file (or in the shell console) define the environmental variable to use.
In my Capistrano's deploy.rb file, I set up different environments such as server names, ports, etc. I also require the users to send a callback to another server, also defined in the deploy.rb. How do I cleanly pass this value to my app?
Something to this effect:
config/deploy.rb:
set :callback_url, "http://somecallbackurl.com:12345/bla"
app/controllers/myapp.rb:
def get_callback_url
???
end
I'm using Sinatra.
I found a solution, and that is to use the environment variables.
Set it from deploy.rb
run "export CALLBACK_URL=#{callback_url}"
From app:
def get_callback_url
ENV['CALLBACK_URL']
end
I wouldn't say it's the cleanest solution, but it works.
I'd probably recommend using a shared YAML file to store this kind of configuration, and loading it separately. For example, have a file named something like config/settings.yml, containing something like:
:callback_url: "http://somecallbackurl.com:12345/bla"
In config/deploy.rb, you could have:
settings = YAML.load_file('config/settings.yml')
set :callback_url, settings[:callback_url]
And in config/initializers/settings.rb, you could have:
settings = YAML.load_file('config/settings.yml')
CALLBACK_URL = settings[:callback_url]
Finally, in app/controllers/myapp.rb, you would do:
def get_callback_url
CALLBACK_URL
end
Using a shared YAML file is just the first thing I thought of. Another approach would be defining some constants in a ruby file, and requiring that file both in an initializer, and in deploy.rb. The basic idea is that you don't really want your app to depend on your capistrano environment, so you should find a way to separate the shared configuration.
I've got a Rails 3.1 project that I'm working on, but I don't want controller_name.css.sass and controller_name.js.coffee to be generated each time I run rails generate controller controller_name. I could swear I've seen the setting somewhere on the internet, but I can't find it now for the life of me. What is it?
Keep in mind that I'm still wanting to use the Asset Pipeline and the CoffeeScript/Sass integration, but I'm organizing those files in my own way.
I'm pretty sure the answer is a command line argument, but bonus points for turning it off with a generator setting or a hidden file or something.
EDIT: I've found the command line flag for it.
rails generate controller controller_name --assets=false
Or something of the like (that line actually errors out, but it also doesn't generate the assets). The API here shows :assets => true as a default option. How do I change that to false and have it always be false every time I generate a controller?
Add these lines to application.rb:
config.generators.stylesheets = false
config.generators.javascripts = false
New syntax is rails generate controller Resources --no-assets.
Don't forget you can also use g in place of generate. And you can skip the creation of a controller helper using the --no-helper flag.
For just one time, use:
rails generate controller controller_name --no-assets
An update on #Dmitry Maksimov's answer for Rails 4.2. You can disable generation of controller-specific asset files by default with the following in your config/application.rb file (source: the guide):
config.generators do |g|
g.assets false
end
My whole options in the application.rb file:
config.generators do |g|
g.stylesheets = false
g.javascripts = false
g.test_framework :rspec, fixture: false
g.template_engine :haml
g.fixture_replacement :factory_girl, dir: 'spec/factories'
end