Actually i am newbie to rails testing
I want to know what are all the step covered in the rails testing.?
Could anyone help me knowing the steps involve in Professional Testing
Check out the rails guide Gavin linked you. Can also check out this book: http://pragprog.com/book/achbd/the-rspec-book. It covers how to use rspec, and covers testing various parts of the application.
I also rather enjoyed Rails 3 in action, which teaches the basics and various topics of rails, while doing inside-out testing throughout the entire book. Rails 4 in action is a work in progress edition as well.
As for my answer:
Generally testing first before you write code makes the process better & easier. Writing tests after the fact isn't as nice, even though it does give you the coverage. When it's part of your regular workflow to add features, it's quite nice. If you have a new feature that you want to add, such as user sign up that sends a confirmation email. You can write the integration test first. It describes the user as going through the sign up form, filling it properly, and then checking if an email was sent.
From there you can test internals of the user model, making sure methods you build for this to work function as expected. Then when you have your tests green, add another scenario to the integration tests where the login was invalid.
Related
I'm a fairly experienced dev but I'm a total web and rails newbie. I'm trying to implement a kind of market place rails application. I've developed the app to where I'm far along in the customer interaction flow and now I'm realizing I need to automate stuff cause dev/test via browser consumes so much time.
Say I have customer interaction flow that goes from page A, then to page B, C, D...G. And now I'm developing the 'H' page. I know I could use the automated test facilities (e.g. Minitest) to automate the whole thing. But being as how I still have my rails training wheels on sometimes I like to see database state progress from one state to the next for myself rather than just trust that the test automation really is doing what I'm expecting.
My question is, is there a way to have Minitest automate/simulate the user interaction flow from A -> G and then let me take over in a manual way from there such that I could click my newly-developed browser button while using my db browser to watch db state progress appropriately?
If not - which is what I'm guessing - I'd happily settle for a way to examine the database contents after an integration test. My integration tests work just fine. It's just that after they complete I'd like to be able to pop open my db browser and poke around, verifying various values to ensure to my satisfaction things in the db are as they should be.
Another possible solution that would work for me is if there was something within my integration tests that could access db values so I could verify things programmatically. I have in mind something like how assigns give you access to instance variables within your integration tests that you can then do 'asserts' calls on.
And, of course, please let me know if I'm way off track and there's a "best practice" for this type of thing that I've missed.
I'm using Rails 4.2.0 and Ruby 2.2.2p95
While Minitest doesn't have a way to do the first option you mentioned, you might checkout Watir as a means of (partially) automating tests so you leave off at a certain point with the browser still open and continue manually while watching what's going on in the DB.
However, since the second option you mentioned is possible with Minitest (and will save you even more time by being fully automated) I'd highly recommend it. See the Ruby on Rails Tutorial 3rd Edition by Michael Hartl for some examples (you might find the whole thing helpful, but here's a section that shows a test much like what you are looking for: Section 7.4.4.)
I am still new to rails, but I went through Michael Hartl's book (super hepful, btw).
However, I started using Devise (also super helpful) and I had a question about testing with rspec. In Hartl's book, there are all these tests for user validations like uniqueness of email or just whether or not a user is created with valid attributes.
Are simple tests like this needed if I am using Devise?
Part of the reason I am asking is I can't figure out how to write the tests even though I know they are working. In general do you need to test gems to see if their internal functionality is working? Or can I just assume that will work and only test that a user can be created and logged in and be done with it?
I do test how I CanCan in that I test if I was redirected or not, but that seems more like testing that the rules I created are right. Testing the inner functions of Devise seems excessive?
I would consider testing the inner functions of devise to be excessive. However, if you make changes to devise, either the views, controllers, or validations, it would be appropriate then to test your changes.
I also always have request/acceptance tests that test the sign in/up part of my app.
You also asked:
In general do you need to test gems to see if their internal functionality is working?
No, this is generally not done. Things I like to look for: on the gem's github or webpage, do they link to TravisCI --- you can see if their current test suite works. In general, test at your level, not one beneath. For example, don't test that Rails works, just use Rails.
In the past couple of days I've been making slow progress adding tests to an existing rails app I've been working on for a little bit.
I'm just trying to figure out how much and what kind of tests (unit, functional, integration) will be enough to save me time debugging and fixing deploys that break existing functionality.
I'm the only one working on this application. It's basically an inventory management database for a small company (~20 employees). I didn't add testing from the beginning because I didn't really see the point but I've have a couple of deploys screw up existing functionality in the last little bit, so I thought it might be a good thing to add.
Do I need to test my models and controllers individually AND perform integration testing? There seem to be developers who believe that you should just integration test and backtrack to figure out what's wrong if you get an error from there.
So far I'm using RSpec + Factory Girl + Shoulda. That made it pretty easy to set up tests for the models.
I'm starting on the controllers now and am more than a little bit lost. I know how to test an individual controller but I don't know if I should just be testing application flow using integration tests as that would test the controllers at the same time.
I use integration tests to test the successful paths and general failure paths, but for the edge cases or more in-depth scenarios then I write model/view/controller tests.
I usually write the tests before writing the functionality in the application but if you want to add tests afterwards then I recommend using something like SimpleCov to see which areas of your application need more testing and slowly build up the test coverage for your application.
Writing tests after the app is already written is going to be tedious. At a minimum you should be testing for integration cases (which will test most controller functions and views), and also model tests separately so that your model calls work as you think they should.
For integration testing I find Capybara easy to use.
As a rule of thumb, most of your tests need to be unit, some functional, few integration.
Rails adheres to this wholeheartedly and you should do the same.
At the minimum you have to have:
A unit test for each of your models, add a test case for each of your validations in each of them, and finally a last one to make the sure the model is saved. If you have stuff like dependant: :destroy, touch: true on related models (has_many, belongs_to), add test cases for them as well.
A functional test for each of your controllers. Test cases for each action. Some actions can have multiple responses (like in case of 422 errors) so add another case to test the error response. If you have a authorization filter, test them as well.
Then you can have an integration test for a typical new user flow. Like
Sign Up -> Create Post -> View it -> logout. Another one is to make sure that unauthorized users cannot access your resources.
And from now, do not commit ANY code without the above mentioned tests.
The best time to plant a tree was 10 years ago, second best time is now, so start testing!
I want to start diving into BDD. I have never used TDD before and am
not sure if I should start by learning RSpec and then jump to Cucumber
or just go straight to using Cucumber.
I have been reading on the internet about both and it seems to me that
Cucumber could be a 'replacement' for RSpec. Am I right or should be
one used for certain things and the other one for others?
Cucumber and RSpec are both used for BDD but have different uses.
Think of Cucumber as describing what happens from the user's perspective, through interaction with the web browser. So you can have steps like:
Given I'm not logged in
When I login
Then I should be on the user dashboard page
Pretty broad, but there's a lot going on under the hood there. Cucumber is good for making sure all these sort of high-level features and functionality are covered (e.g., that when your user logs in, they're taken to the right page). But it's not a good tool for testing lower-level code. That's where RSpec comes in.
Take the login example above. Your user may be logging in with an email address or username. You probably want to ensure the email address is valid or that the username is a certain length...or that the thing they're using to login with is unique. You'd do this in your User model with a validation.
It's a trivial example, but this is the kind of thing you'd test using RSpec (in your spec/models/user_spec.rb file). This is not something you'd test using Cucumber.
So bottom line is:
Cucumber for higher-level tests describing broad functionality as viewed from the user's perspective
RSpec for lower-level tests describing details for how your classes, methods, models, controller, etc should actually work.
This post actually does a really good job of explaining when to transition from one tool to another:
http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/
I also recommend "The RSpec Book" and "Rails Test Prescriptions" for good resources on both tools and testing in general.
P.S. - Not to confuse things, but you can actually use RSpec for the high-level stuff too. But some of that decision is a matter of which tool you prefer or maybe whether or not you're working with a non-technical client who would benefit more from Cucumber's user-friendly syntax for describing scenarios.
Yes, cucumber and rspec are both used for BDD.
I personally prefer Cucumber, but some people find it offputting, and
prefer
their tests to be less english, more code. Both are great tools, though.
Kenton did a great job with this answer. Here is how the authors of RSpec and Cucumber see it:
We use Cucumber to describe the behavior of applications and use RSpec to describe the behavior of objects.
Although we use Cucumber to focus on high-level behavior and use RSpec
to focus on more granular behavior, each can be used for either
purpose.
I am looking for TDD resources that are specific to Rails.
I've seen the Rails Guide: The Basics of Creating a Rails Plugin which really spurred my interest in the topic.
I have the Agile Development with Rails book and I see there's some testing-related information there. However, it seems like the author takes you through the steps of building the app, then adds testing afterward. This isn't really Test Driven Development.
Ideally, I'd like a book on this, but a collection of other tutorials or articles would be great if such a book doesn't exist.
Things I'd like to learn:
Primary goal: Best Practices
Unit testing
How to utilize Fixtures
Possibly using existing development data in place of fixtures
What's the community standard here?
Writing tests for plugins
Testing with session data
User is logged in
User can access URL /foo/bar
Testing changes in data
Author updates post
Product status changes to back order
User buys product (behavior?)
User is logged in
User has valid address and valid credit card
Order record is made
Credit Card transaction history updated
Send email to user
Testing success of sending email
Testing AJAX
Possibly testing general jQuery functionality (Interface elements, etc)
RSpec
What place does RSpec have in a Rails app
The future of testing
Where is testing going? What things are on their way out?
What patterns will be used in Rails 3?
Thanks for any help!
The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends. Focuses on BDD rather than TDD, but that's the whole point of RSpec and Cucumber. Not entirely specific to Rails, but has several chapters dedicated to it. Well written and up to date (though still in beta).
Many of the points you mention are discussed in different episodes of Railscasts by Ryan Bates, including:
http://railscasts.com/episodes/275-how-i-test
http://railscasts.com/episodes/158-factories-not-fixtures-revised
http://railscasts.com/episodes?utf8=%E2%9C%93&search=cucumber
This is an older question, but I will add that Michael Hartl's Learn Rails by Example walks the user through TDD and covers most of the bullet points mentioned in the original question.
I'll also add that Everyday Rails Testing with RSpec is a great purchase, especially since the author makes free updates available to customers after they already bought the book, and he plans on updating again in light of Rails 4's release.