Rails test "one" fixtures introduction

Brief introduction

Each rails application includes three environments:

Production environment

Development environment

Test environment

Our test is run in the test environment, and if the test involves a database, it will operate in the test database. This does not affect the production environment and the data in the development environment.

We first use

Rails new projects

command to create a rails application, the default will be to create a projects directory, which will contain some default directories and files. There is a folder test, which will have all of our test-related files.

$ ls-f test/

FIXTURES/FUNCTIONAL/INTEGRATION/PERFORMANCE/TEST_HELPER.RB unit/

Fixtures Folder

The files in the fixtures folder are yml suffixes, and the files are in the YAML format.

What is this file for? Use to create data and create data for testing. Each file corresponds to a database table, the name of the file is the name of the database table, which can create a lot of data, each data corresponding to the table row of data.

The value of each field is generally written in the file, and can be specified, even if the primary key ID of the table is a self-added field, and if not specified, the system is automatically allocated.

Users table Structure

Create_table:users do |t| 
  T.string name 
  t.datetime birthday 
  t.string profession 
     
  End 

Users.yml

David: 
id:1
  name:david heinemeier Hansson 
  birthday:1979-10-15 
  profession:systems

User.rb

Class User < ActiveRecord::Base 
  Attr_accessible:name,: Birthday,:p rofession 
End

You can use this data in unit tests and functional tests, which is equivalent to some analog data.

How do these yml files work?

The yml file in the Fixtures folder will be loaded automatically when you perform unit test and functional functional testing, and then take the following three steps:

Deletes data that already exists in the test database.

Loads the data in the fixtures into the test database table.

The fixtures data is then placed in a number of variables, which can be accessed directly from the variable at a later test.

There are several points to note when writing yml files.

First, the properties of the emulated data in the Yml file correspond to the fields of the datasheet, and the number of attributes in the Yml file can be less than the number of fields in the datasheet, but not more than the number of fields in the datasheet, or a field that does not exist in some databases.

Why?

Because the field of the INSERT statement is generated based on the properties that are emulated in the Yml file, the data is inserted into the test database. If you find a field that is not in the database, the insert fails, obviously because the insert contains fields that are not in the database table. But it doesn't matter how few you have, but if the database is bound, it may still be problematic. For example: A non-empty field, you do not have a simulation, then the error.

Secondly, sometimes we still encounter such a situation. We need some entities, and we need these entities to have some properties, but these properties do not have corresponding storage in the database.

For example, our common user entities, we will have two attributes password and password_confirmation, used to register when the password verification, but the final deposit form password is hash after the value, not the user in the interface of the value.

Class User < ActiveRecord::Base 
  Attr_accessible:email,: Name,:p assword,:p assword_confirmation 
     
  validates :p Assword,: Confirmation => true
  validates:p assword,:p resence => true
end

If you want to test whether the validates for the password is effective, the fields password and password_firmation cannot be emulated in the Yml file because the two fields are not in the database. If you include these two fields in the mock file, you will get an error, because as I said before, the mock data will be inserted into the test database, and the nonexistent field will cause the insert to fail and the test will fail.

Such entities, when testing the database does not exist in the field, if you need to simulate some such entities, you can not yml the file simulation, only through the code to simulate such an entity. And then do other tests.

user = User.new (:p assword => "123",:p assword_confirmation => "123")

Access the data in the fixtures.

Users (:d ivid)

With the users (:d ivid), you can access the divID data that is emulated in USERS.YML. The impersonated Name property value can be accessed through the users (:d ivid). Name.

Summarize

Fixtures is used to create mock data.

This data is inserted into the test database, so you cannot impersonate a property that does not exist in the database.

The mock data can be used in unit tests, test, and functional test functional, and can be accessed through the table name (: Impersonation entity name). Users (:d evid) is a user, and then users (:d evid). Name can access the value of the Name property.

This article is from the "It architects in the breakout" blog, please be sure to keep this source http://virusswb.blog.51cto.com/115214/1075385

See more highlights of this column: http://www.bianceng.cn/Programming/project/