What is the best practice to test non-functional requirements in a rails 3 application like authentication or authorization which are implemented as before filter in the controllers. Should the functional tests are used where may be the existence of the certain before filters are checked or is it an issue for the integration tests where you try login with wrong credentials.
I have read a lot of other posts but didn’t find a proper solution.
Thank you for all answers.
Inside of functional tests for a given controller I will usually include the tests such as "make sure the user is redirected to the login page if not logged in", or "make sure the index page is rendered if the user IS logged in".
Ultimately I think it is a style decision, but I consider what is protected via login and what is not, to be part of the functional spec of the application. Hope this helps!
Related
I am beginning to write functional tests with Geb and Spock. I wrote a few simple ones for the login of my application but now, I would like to encapsulate the login process so I can test pages that require authentication.
How would you go about it?
Thanks in advance.
Also, I could not find a google group to post this question, where do people having Geb/Spock questions go to?
I found a great blog post that answered my question:
Encapsulating page state and actions
The author goes beyond my initial use case and also demonstrate how one would encapsulate and reuse test code around a pagination module for example.
I am using rails 3.2 and devise 1.5.3.
I added an admin attribute in my model as described in option 2 on the devise wiki How To: Add an Admin Role
I added this in a post controller for force logins:
before_filter :authenticate_user!
I wrote some logic to hide the edit/new links in my views based on whether you're an admin or not.
I feel like there's more I should be doing.. Should I add anything else to new/edit/delete actions to make them more secure? If so, where?
your answer may be working but it is pretty difficult to ensure security in the whole app if you are using some logic to hide the edit/new links in my views and I'm pretty sure no amount of security testing would give you the feeling that maybe you are forgetting about something
for example I someone could log in,,,, (not having admin profile) and go to (in the URL),:
/users/edit/3 and start damaging your valuable information....
situation is: Devise only provides authentication,,, but authorization has to be enforced in some other way or else I could be able to do the above things...
for that I would highly recommend CanCan (from rbates ofcourse) which is the one I have tested personally and is PRETTY easy to configure just by reading the docs and examples in github..... hope it helps!
Your authentication and authorization mechanism is in charge of taking care of security for you, and you should make sure it's regularly updated with security updates.
That sinking feeling that you have about missing something can only reliably be covered by tests. So, write some tests that verify that the way you've setup your Devise installation is, in fact, correct, and they non-admin users do not have access to anything they shouldn't have access to. Then be very careful to make sure you update your security restrictions as you add new things.
You don't need to write tests to make sure Devise works - but you do need to write tests to make sure that your use of it is what you think it is (i.e. if non-admins shouldn't be able to get to the admin page, write a test that logs in as a non-admin, try to access that page, and verify in the test that the user is redirected and, if you have an 'access denied' message, that's it's firing). That way, if you inadvertently break security access later, you at least stand a chance that it'll be caught by a test in your test suite.
Run your test suite before every deploy, making sure that all tests (especially security tests) are running and passing. Then be vigilant thereafter, and that's about all you can do.
So, I am starting to build a new application, my first big one in rails since moving from .net.
I really want to BDD the entire application so I have cucumber all set up and ready to go.
I have written more then a couple of test for the simple stuff (deleting, adding, updating) and so on but now I am stuck trying to figure out how to test this scenario.
I have these models
User, Account, Plan
each account has a plan, the plans are billable each month (on the same day the account was created).
I want to test selecting a plan, creating an account, check the billing process (even mock, without PayPal at this point).
I would appreciate help with this, just to emphasize, I am not looking for complete code, just an explanation of how (in concept) would you go about and test this.
Also, plan is upgradable and downgrade-able so I want to test this as well.
Thanks in advance for your help
I like to practice outside-in development, where we begin by writing acceptance tests, then drop into unit tests to handle domain logic. Let's take creating an account as an example.
Start by writing a Cucumber story for the desired feature. For example:
Feature: Create an account
In order to use the application
As a user
I want to create an account
Scenario: Create an account from home page
Given I am on the home page
When I follow "Sign up"
And I fill in "Username" with "bob"
And I fill in "Password" with "test123"
And I press "Create"
Then I should see "You have successfully signed up! You may now sign in."
When we run our Cucumber features using the cucumber features command, the first step in the scenario will fail because the home page does not yet exist. To create it, we may consider it a separate feature. Therefore, we might write another Cucumber feature like:
Scenario: Visitor visits the home page
When I go to the home page
Then I should see "Welcome to the Website of Awesomeness"
Running this feature, we will discover that there is no root route defined in the Rails app. Once we fix that issue, we'll need a controller, view, and the text in the view. So far, we have only written Cucumber tests.
Once all of these features are passing, we realize a username should be required. We can write a Cucumber step to test this case:
Scenario: Username must be filled out
Given I am on the home page
When I follow "Sign up"
And I fill in "Password" with "test123"
And I press "Create"
Then I should see "Username cannot be blank."
To implement this, we must add a validation to our model that will validate the inclusion of a username. Now we will drop to unit testing because we are modifying domain logic. As a general rule, when you modify a model, you should drop into RSpec or Test::Unit and test that modification directly. For example, using RSpec we would add a spec to ensure usernames must be present (and unique, etc). Once this test passes, our scenario should also begin to pass.
This was long-winded, but it should help you start practicing BDD in a very real way. For more information, see the RSpec book (which includes a wealth of information about outside-in practices using Cucumber and RSpec): http://www.pragprog.com/titles/achbd/the-rspec-book
Are there strong reasons for using Rspec for controllers and views too?
My views are heavily dependent on Javascript, and as far as I know, Rspec doesn't handle javascript/ajax on views. Also im using Cucumber + Selenium for that.
And should I use it for controllers?
Isn't it enough to just use Cucumber + Selenium for the application behavior? Cause if a cucumber test passes, then it passes, why should I bother with Rspec view and controller tests?
Could someone enlighten me on this topic?
I use a combination of Cucumber + Shoulda, but what I'm about to tell you still applies to the setup you have.
When testing a controller I use Shoulda in a functional test to hit all of my "negative auth" situations. For example:
A logged in user trying to access an admin page.
A logged out user trying to access protected content.
User A trying to delete User B's post.
I use Shoulda for this, because what I'm generally looking for is that I was kicked to the login page, and that whatever model was trying to be accessed maliciously wasn't actually changed. I could use Cucumber for this, but I find it easier and less cumbersome to do with a handful of Shoulda macros and some functional tests. Shoulda contexts are a great fit here.
Then for the "good auth" situations, I use Cucumber. Things like:
A user accessing his own preferences page.
An admin pulling up reports.
These types of tests require that I check some actual page content, and not just check for "access denied" over and over again. I find the descriptiveness of Cucumber to be a great match here.
If you build a full enough set of tests, you can just use selenium, but if you want to test the behaviour of your javascript seperate from the rest of the app, you might consider using a javascript test framework, like QUnit.
I know how to run functional/integration tests in Rails, this question is about best practices. Let's say authorization is performed using four distinct user roles:
basic
editor
admin
super
This means that for each action there are up to five different behaviors possible (4 roles + unauthenticated/anonymous). One approach I've taken is to test every role on every action, for example:
test_edit_by_anonymous_user
test_edit_by_basic_user
test_edit_by_editor_user
test_edit_by_admin_user
test_edit_by_super_user
But this obviously leads to a lot of tests (every controller action on the site really needs to be tested five times). The opposite approach would be to test the authorization mechanism in isolation and then authenticate as super before testing every action (on setup), and only test one version of each page.
I've tried several approaches with varying degrees of specificity but haven't been completely satisfied with anything. I feel more comfortable when I'm testing more cases, but the amount of test code and difficulty of abstraction has been a turn-off. Does anyone have an approach to this problem that they're satisfied with?
It really depends on how you have setup your code for checking the authorization and how you test for it in actions. I can tell you what we do as an example. We have roles like you do, and some pages that require login, some that require a role, and some that have different output based on role. We test each type a little differently.
First, we test authorization and login separately.
Also, we created filters for actions that require the user has logged in, and then others for requiring a certain role. For example check_admin, check_account_owner, etc. We can then test that those filters work on their own.
We then add checks in the controller tests that the correct filters are being called. We use shoulda and wrote some easy extensions so we can add checks like:
should_filter_before_with :check_admin, :new
That way we are testing what needs to be tested and no more.
Now, for more complex actions that do different logic depending on role, we do test those actions for each role that contains special logic. We don't write tests for roles on that action that will be filtered, or are supersets of other roles. For example if the action adds more fields to a form if you are an admin, we test non-admins and admin. We don't test admin and super admin since our code for role checking understands that super-admins are admins.
Also, for templates that contain logic to only display certain items for certain roles, we try and move that code into helpers, or if common like an admin toolbar, into partials. Then we can test those on their own and not on every action that includes them.
To sum up, test only what you need to for a given action. Just like you wouldn't test Rails internals in your Unit tests, if you write common code for your role checks and test that, you don't need to test it again on every action.
In some situations you may be required to test ALL possible roles and authorization levels against different actions - like, when working for a bank, for instance :) In this case it makes sense to take a more dynamic approach to testing. Instead of defining each test case, you would generate all the combinations.
A few years ago Ryan Davis did a presentation about the "functional test matrix" which is part of ZenTest. Dr. Nic did a writeup, and at the end of the post you'll find updated links in the comments. This solution was designed for exactly the problem you describe. You could also roll your own solution, by running tests inside nested loops, for example - the idea is basically the same.
Consider an application which is having 2 roles admin and read only
Perform below tests:
login with read only mode perform some action and logout. Now from same system and same browser login with admin role and see the behaviour of the system. And vice versa.
login with admin role and copy the cookie value and log out. Now login with normal role and edit the cookie value by using cookimanager+ or editthiscookie tool. And if application is working as expected then it is an issue.
Repeat above test case 2 from same machine same browser, same machine different browser, from different machine
if it is thick client application then perform reverse engineering and analyse the code. Try to change the logic of authorization management (someone needs to have coding experience for this) recompile the code and repeat test 2-3.
using proxy interruption tool like burp suite analyze get/post request for both the roles.
Now based on type of role available for your application decide test cases.