It's the first test im writing that requires :js => true so I installed selenium.
I am always able to login with some credentials I create before but unable to log in when I run them through selenium.
A sanity check to see if I'm still creating my user (recruiter)
puts "RECRUITER NAME => #{Recruiter.first.email}"
returns
RECRUITER NAME => company1#test.com
I always set my password to "testtesttest"
But it always fails to login.
Is it using a different (empty?) database? Am I missing some settings that are required?
Note => Logging in with the exact same file works flawless if I remove :js => true. But somehow it breaks on this step.
When performing js tests the app being tested runs in a different thread than the test, which means they no longer share the same database connection - see https://github.com/jnicklas/capybara#transactions-and-database-setup. There are ways to force the two threads to share the connection, but it ends up being flaky on some edge cases and limiting what database access you can do at specific times in your test, and really isn't something a beginner wants to deal with. The better/easiest solution is to disable transactional testing and use truncation or deletion to manage the database state. The easiest way to do that is to use database_cleaner and setup a config that will swap to the needed strategy for each test - https://github.com/DatabaseCleaner/database_cleaner#rspec-with-capybara-example
Related
I'm starting to write feature specs for a Rails application using Rspec with Capybara and Selenium to drive the browser.
While executing one of the specs I want to change the value of a session variable. Eg: I want to set session[:user_id]=123 so that I can test features in my application without having to go via the login screen every time.
When using Capybara with the default rack_test driver, the rack_session_access gem works for accessing the session. But it doesn't seem to work when using the Selenium driver.
And yes, this question has been asked before, but no satisfactory answer has been given.
Short answer, you don't. Longer answer, that's completely against the point of feature tests which are meant to be end to end.
That being said, if for performance reasons you want to short circuit the login, most authentication libraries provide a test mode that will allow you to do that - devise via the Warden TestHelpers for instance
My frontend is an EmberJS-based app. It's totally async in nature, so testing it with Capybara is pain and misery. On the other hand, Ember provides a fantastic test suite out of the box which makes acceptance testing fun and effective.
Normally, either fixtures or backend mocks are used to acceptance-test Ember apps. But testing against mocks does not satisfy me at all:
It will not reveal possible API inconsistencies between the backend and the frontend, race conditions, etc.
It is impossible to test backend business logic this way. Such tests are not integration tests.
Finally, acceptance tests require persistency, so you have to replicate backend behavior in a mock. It's very tedious and you effectively end up implementing two backends.
So I want to test against the real backend! It's trivial to set up Ember to use a local backend instance for testing. But the problem is that the backend will persist its state between individual tests and even test sessions.
That's why I'm thinking of implementing a special public API in Rails:
The API is only available when Rails is run with a specific flag or an env var.
Rails runs in a non-testing mode, serving normal API calls as it would in production.
Before each test, the frontend calls the special API, telling Rails which database setup is needed for this specific test.
When a call to the special API is received, Rails cleans the database and populates it with the requested data. For example, to test item deletion from the cart, the database should have three items in the cart.
Rails finishes the API request, and the frontend starts the test.
Frontend runs test steps, using the normal backend API as it would in production: log in, create posts, comment on them. It will also try doing some forbidden things, e. g. edit posts while not logged in, exceed text length constraints, etc and verify whether the backend rejects forbidden actions.
When the frontend runs next test, it will call the special API again. Rails will discard the state produced by the previous test and set up a new one, for this specific test.
I'm a frontend dev with a sketchy knowledge of Rails. Factory Girl and Database Cleaner seem to be the right tools for the job, but there is absolutely no information how to use them outside Rails' normal test environment. I guess I need a controller or a Rails engine or something.
So the question is: how do I make an API in Rails that can be used by the frontend to tell Rails to set up a certain database state with a fixture factory, while Rails are running in a non-test mode i. e. serving REST API and not running through RSpec/Capybara/Cucumber?
Bonus feature: fixture factory properties should be defined on the frontend so that test code is stored in one place. Thus, the backend should be able to accept fixture factory properties via the special API. Defaults can still be defined in the backend's codebase.
I believe this could become an acceptance/integration testing best practice. If I manage to implement it, I promise to publish a gem.
May be something like this
config/routes.rb
namespace 'test_api' do
resource 'db_transaction', only: [:create, :destroy]
end if Rails.env.test?
controllers/test_api/db_transactions_controller.rb
require 'database_cleaner'
def create
DatabaseCleaner.start
end
def destroy
DatabaseCleaner.clean
end
Currently I've got a couple of files in my view that I'm now beginning to design visually (through CSS) by vising the local web app in my browser. To get to these views, you have to go through an authentication step in my application.
Now when testing the authentication step in a controller, I use a fixture containing some test login credentials. This allows me test other parts of the application after this step. However if I wanted to test using the server, I would have to use real credetials from the database. Am I supposed to put fake data in the 'development' database so I can do this, and instead use real data in the 'production' database?
What you're trying to achieve is called integration testing (or end-to-end testing). Rails provides integration testing out of the box.
Personal preferences : I use Cucumber with the Capybara DSL, and seed data corresponding to my features/scenarios using Cucumber's hooks.
EDIT : at first read, I didn't understand that by "testing" you meant "manual testing". In this case yes, you'd better seed your development database with fake data corresponding to your features/test cases.
I am new to rails testing. Two days of running down leads with Google has turned up no solutions for what ought to be a frequent need.
If I write request (integration) specs to use a Selenium or other browser-based driver, is it possible to redirect the test's i/o to a staging deployment on a cloud server (in my case Heroku)?
If so, how? If not, what prevents this from working?
So far I have been using rspec/capybara, but would switch to anything of similar power if necessary.
You can use Capybara with Selenium driver, and set Capybara.app_host to specify the IP of you staging app server. While doing so you can turn off Capybara local rack with Capybara.run_server = false
Remote testing will allow you only to perform human kind of action and test the returned generated HTML/JS/Json etc .. but no access to controller, view, or any other app internal objects.
On thing you could do (I never tried, but I don't see why it wouldn't work) is to set-up your database.yml test configuration to remotely access you staging database, allowing you to control the database during your tests. It's not really secure so you may want to do that over a SSH tunnel , or a similar solution.
I'm building a system which allows the user to modify the database.yml contents via an admin frontend interface.
That changes to database.yml obviously don't have any affect until the application is restarted. Rather than forcing the user (who may not have SSH access to the physical box) to restar the application manually, I'd like a way to force ActiveRecord to reload the config post startup.
Rather than requiring them to restart the server, is there a way to force ActiveRecord to re-initialize after initial startup?
Rationale
There are two use cases for this - a) initial setup wizard b) moving from sqlite evaluation database to production supported database.
Initial Setup Wizard
After installing our application and starting it for the first time the user will be presented with a setup wizard, which amongst other things, allows the user to choose between the built in evaluation database using sqlite or to specify a production supported database. They need to specify the database properties. Rather than asking users to edit yml files on the server we wish the present a frontend to do so during initial setup.
Moving from sqlite evaluation database to production supported database
If the user opted to go with the built in evaluation database, but alter wants to migrate to a production database they need to update the database settings to reflect this change. Same reasons as above, a front end rather than requiring the user to edit config files is desired, especially since we can validate connectivity, permissions etc from the application rather than the user finding out it didn't work when they try to start the application and they get an activerecord exception.
Restart your Rails stack on the next request just as you would if you had access to the server.
system("touch #{File.join(Rails.root,'tmp','restart.txt')")
Building on #wless1's answer in order to get ERB-like ENV vars (e.g. <%= ENV['DB_HOST'] %>) working try this:
YAML::load(ERB.new(File.read(File.join(Rails.root, "config/database.yml"))).result)
ActiveRecord::Base.establish_connection config[Rails.env]
Theoretically, you could achieve this with the following:
config = YAML::load File.read(File.join(Rails.root, "config/database.yml"))
ActiveRecord::Base.establish_connection config[Rails.env]
You'd have to execute the reconnection code in every rails process you're running for it to be effective. There's a bunch of dangerous things to worry about here though - race conditions when changing the database config, syntax problems in the new database.yml, etc.