I'm currently creating rspec test cases for a Rails 2.3 application. The problem I'm confronting is that the application has a dependency on data from an external database like this:
Main_User is an external application.
Node_User is the application I'm testing.
When a new Node_User is created, Node_User calls Main_User which creates a user and returns with some data which Node_User uses to create a the Node_User.
Is there any way I can query the Main_User database to verify that the record created there contains the data that is passed to Node_User? Or is there a better way to test this?
Thank you!
Yes, you can theoretically query the remote database if you have access to the user/pass/hostname for that database. (Search for "Rails multiple databases.")
But I wouldn't necessarily recommend taking that approach. Your tests would be modifying the state of the remote database. This strikes me as unsafe. You'll be creating bogus records--and possibly deleting or corrupting data, if your tests do any mass deletes or exercise broken functionality. In other words, your tests may do bad things to a production database.
Therefore, I would recommend mocking the remote database in some way. One option would be VCR. It's really cool, but it would require you to operate on the remote database at least once, because it has to record the first run. Another option is to use one of the tools underlying VCR, such as FakeWeb.
Of course, this only tests the Node_User side of things. You said you also need to verify that the remote record is correct. To do that, I would recommend writing tests on the Main_User side. Such tests would simulate an incoming RESTful request from Node_User and verify the correct result.
That only works if Main_User is your application. If it's a third-party service, then there may not be a safe way to test it. You may just have to trust its correctness.
Related
I have a thorough ability.rb defined that's working properly. However, when I write a controller spec that sends a request to an endpoint, cancan(can) repeatedly returns a 403.
In my ability.rb in the respective section for handling the endpoint I'm testing, when outputting {Model}.all.to_json it's outputting an empty array.
How can I fix this so that it recognizes the data in my test database, or change my test to bypass this?
The data in the test database is reset on each iteration. If you want to use some specific state (e.g. data), you must re-create that state as part of the test.
Depending on the test framework, use the before or setup hook to create the data you need in the test suite before the test itself is executed.
After going through a deep stare down of my code, I realized that one bit of data I wasn't creating through fixtures was failing validation, thus not being created.
My testing environment was setup properly, but I didn't have a create! call but rather a create, causing it not to be explicit with the validation errors.
I want to create fake usage of my app, as a tutorial.
In order to do so, I need to create fake data (with the same structure and association in real data) to send to my templates, so it renders the same view when my users will have when using the app.
But unfortunately, I didn't find an easy way to do that, except hard coding the examples (fake usage) as a separate view, that looks like the generated view with true data. But this is not useful when you have to change the template, one day or another.
And, mixing true data with fake ones in the database (and then retrieving only fake data when needed) doesn't seem to be a good idea.
Do you have an idea or a gem to suggest?
One option to consider is to use a factory gem (such as factory_girl) or similar (I personally like machinist) and then create some form of script that initializes objects in the test environment.
This may not be the intended or ideal use for a test environment, but you'd be able to utilize your app in a non-production environment with fake data, and allows you to keep data separate from real and/or development data.
The only "gotcha" I can think of is that you'll want to ensure that any automatic testing gem (such as rspec) drops the test database before your tests run. If you don't, you could see errors in your tests due to data already existing in the database.
I've got a ruby on rails application with significant database seeds that tie into the UI elements and are thusly required for integration tests.
I'm using database_cleaner to clean up after my tests, but due to the heavy js use of the application most of my tests can't be run with the transaction strategy which allows me to specify tables to leave out of the rollback.
The result is that I've got to re-seed the database before each test or deal with a dirty database. Does anyone have tips for testing in this kind of situation or know of any tools that may help?
Thanks!
I've dealt with this in the past by using transactions for our tests (we're using something a little homegrown for that at the moment but previously we used database cleaner).
The key is forcing everything to use the same database connection. The path I've been down for this is to set the database pool size in test to 1: everyone has to share the same connection because active record won't let you create more connections.
For this to work you need to be careful about releasing connections no longer in use, by calling ActiveRecord::Base.clear_active_connections!
There are 2 places you need to do this
when your test code is about to call visit, click etc.
after each request (use a Rack middleware for this- you can basically copy ActiveRecord::ConnectionAdapters::ConnectionManagement)
This works for us writing specs against pages that use ajax to fetch intermediate data and so on, but can be a bit tricky to get working initially. I wrote about it more extensively a while back
I've been leaning some of RoR, and when I got to TDD, stuff started to get more complicated. At some point of my App, I thought it would be better to run my tests over the real data.
Real Data vs Sample Data
Searching the web, I found that tests were not meant to run over real data, but over sample data. But yet I couldn't agree with that.
Let's supose my app had an Alias System. So when you access a random url it figures out what that fragment wants and redirects to the proper canonical url. And let's add that an alias dictionary is stored in some models. How would we test agains that dictionary? Hard code spec files for every alias/keyword?
Sticking with real data
The first two things I've realized, yet very unsurely, is:
Rspec testing environment wouldn't access development model's data.
FactoryGirl rules over my testing database, so it's not my option to populate it.
The best solution I could figure out, as the complete newbie I am, is that I could create some classes in spec/support folder and call them inside my factories so as to get that real data. Those classes have a short sample of my real database info, nested, and so my test can go 'real'.
What can pros around suggest to improve it?
I think you may want to look into building a seeds.rb file to populate your databases. This is usually used to initialize the development database so it can be used in your app (and queried in the rails console), but you can use it to seed your test database as described in this answer.
You certainly should not use your development database for testing. You can either seed the test database, or create factories that reflect various scenarios.
FactoryGirl rules over my testing database, so it's not my option to populate it.
You can use more than one factory to represent a business entity, depending on the scenario under test. FactoryGirl makes this easy by allowing you to nest factories. You can define a factory with a basic set of valid attributes and use that in unit tests. For integration (feature) tests, you can use a nested factory that expands on the basic attributes to implement a particular scenario. You can have as many variations of these implementation-specific factories as you need.
I am using Ruby on Rails 3.2.2, cucumber-rails-1.3.0, rspec-rails-2.8.1 and capybara-1.1.2. I have this problem but I started thinking that maybe I'm doing something wrong... mostly about seeding data in the test database for testing purposes. Specifically, my issue is related to how to properly manage data in the test database when I have to test my application.
My doubt is: By seeding data (For Your Information: I use the ROOT_PATH/db/seed.rb file to inject that data) in the test database I'm doing things as they should be done? That is, how should I populate the test database since the data in that database* is required in order to make to properly work my application for testing purposes? Should I populate the test database at all?
In other words, what are best practices to handle database data in test mode (in my case)? And, generally speaking, how the situation should be handled?
***** For example, in order to work my application requires at least data related to an "anonymous" user, to "basic" articles, to "basic" article categories, etc.
You should use one of the following:
Fixtures. See corresponding Rails documentation
Factories. The most popular tool to created/manage factories is FactoryGirl. IMHO that's the best solution.
Make sure data is seeded into test database. See this StackOverflow question.
I had a similar problem, association made it necessary to have a bit of seed data:
Factories will make your tests really slow, they are perfectly OK for single objects, but not for a lot of seed data that has to be created for each test
Fixture Builder - http://github.com/rdy/fixture_builder
I created a bunch of fixtures and just load them from the DB for each test, cut my test time down by 40%. You can also load the seeds file instead.
But be careful, deleting or updating records will create unwanted side effects. Use factories for those specs.
Mock and Stub everything so that your tests rarely touch the DB.
This has become very unpopular, you will eventually get passing specs that don't pick up on your actual errors.