Adding Users and Roles
Learn how to add users and roles in the test and write the integration test.
Now that we have Devise installed, let’s see how we can use testing to expose security issues.
The most basic security issue is user login. Since our application involves projects that would presumably be limited to a specific, private set of users, it makes sense that we would need to be logged in to access the application. This is testable logic—a logged-in user can access a page, whereas any random person who happens across the page can not access it.
Simulating user login
The following is an integration test for the project index page:
rsync -avr --progress /usercode/* /usr/local/educative/gatherer --exclude course-content --exclude execute_.sh --exclude execute.sh --exclude __ed_script.sh --exclude __ed_stderr.txt --exclude __ed_stdout.txt cd /usr/local/educative/gatherer bundle exec rspec
This test uses Capybara, and we’ve seen most of the component parts before. However, this test is potentially one of the solutions to simulating a user login in an automated test. In the helper method log_in_as on line 5, we simulate a user login by actually going through the steps of a user login. The method uses Capybara and the standard Devise login route and login form to simulate heading to the login page. Devise calls this the new_user_session_path, fills in the user’s email and password, and clicks a button, for which the default Devise caption is “Log in.” This method will be boilerplate across projects, depending on the name of the model that controls login and how much we customize the login page.
Simulating login performance
Directly simulating a login has the benefits of exercising the real login page ...