1

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:

  1. Rspec testing environment wouldn't access development model's data.
  2. 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?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Alvaro Lourenço
  • 1,321
  • 1
  • 10
  • 21

2 Answers2

0

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.

Community
  • 1
  • 1
おすぎます
  • 38
  • 4
0

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.

zetetic
  • 47,184
  • 10
  • 111
  • 119