Railsテスト『一』fixtures概要

概要
各railsアプリケーションには、次の3つの環境があります.

生産環境

開発環境

試験環境

私たちのテストはテスト環境を走り、テストがデータベースに関連している場合は、テストデータベースで操作します.これにより、生産環境や開発環境のデータに影響を与えることはありません.
 
我々が先に

  
  
  
  

   
   
   
   
rails new projects 
  
  
  
  

コマンドを使用してrailsアプリケーションを作成します.デフォルトではprojectsディレクトリが作成され、デフォルトのディレクトリとファイルが含まれます.フォルダtestが1つあり、テスト関連ファイルがすべて入っています.
 

  
  
  
  

   
   
   
   
$ ls -F test/ 
   
   
   
   
  
   
   
   
   
 
   
   
   
   
fixtures/       functional/     integration/   performance/  test_helper.rb  unit/ 
  
  
  
  

 
fixturesフォルダ
fixturesフォルダのファイルはすべてymlを接尾辞とし、ファイルのフォーマットはyamlです.
この中の書類は何に使いますか?データの作成、テスト用のデータの作成に使用します.各ファイルは1枚のデータベーステーブルに対応して、ファイルの名前はデータベーステーブルの名前で、中には多くのデータを作成することができて、各データはテーブルの1行のデータに対応します.
ファイルには通常、各フィールドの値が書き込まれます.テーブルのプライマリ・キーidが自己増加フィールドであっても指定できます.指定しないと、システムは自動的に割り当てられます.
usersテーブル構造

  
  
  
  

   
   
   
   
create_table :users do |t| 
   
   
   
   
  t.string name 
   
   
   
   
  t.datetime birthday 
   
   
   
   
  t.string profession 
   
   
   
   
 
   
   
   
   
  t.timestamps 
   
   
   
   
end 
  
  
  
  

 
users.yml

  
  
  
  

   
   
   
   
david: 
   
   
   
   
id: 1
   
   
   
   
  name: David Heinemeier Hansson 
   
   
   
   
  birthday: 1979-10-15 
   
   
   
   
  profession: Systems development 
   
   
   
   
 
  
  
  
  

 
user.rb

  
  
  
  

   
   
   
   
class User < ActiveRecord::Base 
   
   
   
   
  attr_accessible :name, :birthday, :profession 
   
   
   
   
end 
  
  
  
  

これらのデータは、ユニットテストおよび機能テストで使用でき、いくつかのシミュレーションデータに相当します.
 
これらのymlファイルはどのように使用しますか?
ユニットunitテストと機能functionalテストを行うと、fixturesフォルダのymlファイルが自動的にロードされ、次の3つのステップが実行されます.

テストデータベースに既に存在するデータを削除します.

fixturesのデータをテストデータベーステーブルにロードします.

は、fixturesのデータをいくつかの変数に配置し、後続のテストで変数から直接これらのデータにアクセスすることができます.

ymlファイルを書くときに注意しなければならないことがいくつかあります.
まず、ymlファイルのシミュレーションデータの属性はデータテーブルのフィールドに対応し、ymlファイルの属性個数はデータテーブルのフィールド個数より少なくてもよいが、データテーブルのフィールド個数より多くてはならないか、データベースが存在しないフィールドをシミュレートすることはできない.
どうして?
ymlファイルでシミュレーションされたプロパティに基づいてinsert文のfieldが生成され、データがテストデータベースに挿入されるためです.データベースにないフィールドが見つかった場合、insertにはデータベーステーブルにないフィールドが含まれているため、挿入に失敗します.しかし、いくつか少ないのは関係ありませんが、データベースに制約がある場合は、問題がある可能性があります.たとえば、空でないフィールドでは、シミュレーションがない場合は、エラーが表示されます.
次に、私たちはこのような状況に遭遇することがあります.エンティティが必要であり、プロパティが必要ですが、データベースには対応するストレージがありません.
たとえば、一般的なユーザーエンティティには、passwordとpasswordの2つのプロパティがあります.confirmationは,登録時にパスワードの検証を行うために用いられるが,最終的にテーブルに格納されるパスワードはhash以降の値であり,ユーザがインタフェースに出入りする値ではない.
 

  
  
  
  

   
   
   
   
class User < ActiveRecord::Base 
   
   
   
   
  attr_accessible :email, :name, :password, :password_confirmation 
   
   
   
   
 
   
   
   
   
  validates :password, :confirmation => true 
   
   
   
   
  validates :password, :presence => true 
   
   
   
   
end 
  
  
  
  

パスワードに対するvalidatesが有効かどうかをテストしたい場合は、passwordとpassword_firmationの2つのフィールドは、データベースにこの2つのフィールドがないため、ymlファイルでシミュレーションできません.シミュレーションファイルにこの2つのフィールドが含まれている場合は、前述したように、シミュレーションデータがテストデータベースに先に挿入され、存在しないフィールドが挿入に失敗し、テストに失敗します.
このようなエンティティは、データベースに存在しないフィールドをテストするときに、このようなエンティティをシミュレートする必要がある場合は、ymlファイルでシミュレートすることはできません.コードでシミュレートするしかありません.その後、他のテストを行います.

  
  
  
  

   
   
   
   
user = User.new(:password => "123", :password_confirmation => "123") 
  
  
  
  

 
fixturesのデータにアクセスします.
 

  
  
  
  

   
   
   
   
users(:divid) 
  
  
  
  

users(:divid)でusersにアクセスできます.ymlでシミュレートされたdividのデータ.users(:divid).nameは、シミュレーションのnameプロパティ値にアクセスできます.
 
まとめ

fixturesは、シミュレーションデータを作成するために使用されます.

これらのデータはテストデータベースに挿入されるため、データベースが存在しない属性をシミュレートすることはできません.

シミュレーションデータは、ユニットテストunit testおよび機能テストfunctional testで使用でき、テーブル名(:シミュレーションエンティティ名)でシミュレーションエンティティにアクセスできます.users(:devid)はuserであり、users(:devid)である.nameはnameプロパティの値にアクセスできます.

 
参考文献
1.http://guides.rubyonrails.org/testing.html