Railsテスト《四》実戦ユニットテストunit test
前のブログではrailsテストに関する知識を紹介しました.ファイルの場所、テストのタイプ、テストの一般的なコマンド、および使用可能なリソース、fixturesを使用してシミュレーションデータを生成する方法をテストします.
今日は実際にユニットテストを書いてみましょう.主にfixturesとunit testです.fixturesはデータをシミュレートするために使用され、unit testは私たちの今日の主役-ユニットテストです.
今日のコードはblogプロジェクトを背景に、このプロジェクトのためにいくつかのユニットテストを書きます.
このプロジェクトのコードはhttps://github.com/woaigithub/blog取得され、プロジェクトはすでに配備されています.http://42.121.5.68:10000/、導入した本番環境に直接自分のブログを書くこともできます.
masterはメインブランチ,developは開発ブランチであり,開発ブランチのコードは最新である.
プロジェクトはruby on railsを用いて開発し、開発及びテスト環境はsqlite 3をデータストレージとし、生産環境はmysqlをデータストレージとして使用する.
ユニットテスト
railsのユニットテストは主にmodelに対して、modelは私たちのビジネスエンティティです.ユニットテストは主にmodelのvalidatesとmodelのビジネスルールをテストし、テストはビジネスルールの実行を経て、私たちのmodelの変化は、modelの属性値であり、ルールの説明に合っているかどうか、予想される値になっているかどうかです.
==広告開始
このブログはコラボレーションのブログプラットフォームとして位置づけられています.分類、tagなど、皆さん一人一人がブログを書いたり、ブログの管理をしたりすることができます.
ブログの主なターゲットユーザーは開発者であり、他のタイプの業者がこのプラットフォームでブログを発表することを歓迎しています.
右上の登録で、このブログプラットフォームのadminになり、ブログを書き、ブログを管理することができます.もちろん、ブログを見るには登録する必要はなく、直接閲覧することができます.
footerセクションにはadminリンクがあり、リンクを介してバックグラウンドに入ることができます.もちろん、バックグラウンドに入るにはログインが必要です.
ブログのプラットフォームはまだ开発中で、もしみんなが何か良い考えがあるならば、あるいは开発に参加したいならば、すべてhttps://github.com/woaigithub/blog伝言を書く.
==広告終了
私たちの今回のプロジェクトはブログで、基本的な機能があります.ブログリストを閲覧し、分類してブログを閲覧し、単一のブログを閲覧する. 博文メッセージを見て、博文メッセージを送ります. ユーザーを登録し、プラットフォームにログインします. 管理ブログ、管理ブログ、管理分類、管理tag、管理コメント.
表の構造は次のとおりです.
### users id nickname email password_digest salt created_at updated_at
### tags id title created_at updated_at
### categorys id title created_at updated_at
### comments id commenter commenter_email commenter_url content post_id created_at updated_at
### posts id title slug category_id summary content created_at updated_at user_id
### posts_tags post_id tag_id
私たちのmodelにはvalidatesルールがいくつか書かれています.長さ、タイプ、必須です.今日のユニットテストの主な目標はこれらのvalidatesです.
まずuserのmodelを見てみましょう.
modelでは4つのmass-assignment:email,nickname,password,password_を宣言した.confirmation.
それぞれvalidates、長さ、フォーマット、パスワードconfirmationがあります.
test/unit/user_を開くtest.rbファイル、このファイルはrails g model userまたはrails g scaffold userを使用した後に作成され、中のテスト時計回りにuserというmodelのユニットをテストします.
モデルがコマンドで生成されず、自分で書いたコードである場合、このテストファイルも手動で作成する必要があります.
空白のuser_を先に作成できますtest.rbファイルは、いくつかの基本的な内容が含まれており、テストは含まれていません.
中のいくつかのコマンドは約束を守る必要があります.railsの3つの特性の1つはconvention over configurationです(約束は構成より優れています).約束にはいくつかのメリットがあります.一つは、みんなのコミュニケーションを減らすことです.そして、約束を知っている人はコードを読むことができ、ファイルやコードの内容をすぐに理解することができます.二つ目は、約定された名称に対して統一的なコード処理を行うことである. DRY,do not repeat yourself. RESTFul. convention over configuration. 最初の行のrequireはtest/test_をロードします.helperファイルは、テスト環境のいくつかの構成を定義します.
テストクラスはモデルの名前+Testをクラス名とし,クラスはActiveSupport::TestCaseを継承する必要がある.
まずnicknameに対するvalidatesのテストを書きます.nicknameのvalidatesには、必須と長さ範囲1-30の2つの内容が含まれています.
考え方はuserオブジェクトを作成し、userが有効かどうかを見て、userを通じてvalid?userが有効かどうか、すなわちuserに対するvalidatesが通過するかどうかを判断する.
他の属性のvalidatesがnicknameのvalidatesのテストに干渉しないことを保証するために、他の属性の値が属性に対応するvalidatesに合致することを保証する必要があります.
まず合法的なnicknameのテストを追加します.つまり、私たちのuserオブジェクトのnicknameはvalidatesのルールに合っています.
テスト...do...endは1つのテスト方法で、SRP(職責単一の原則)に基づいて、私たちのテストも職責単一で、1つのテストを維持して1つのことだけをして、1つの内容だけに対してテストを行います.
このテストには2行のコードがあり、最初の行はmass-assignmentでuserオブジェクトを作成し、各プロパティに合法的な値を割り当てます.2行目は、userオブジェクトが有効かどうかを判断する断言関数です.
私たちはrake testコマンドでこのテストを走ります.次の出力結果が表示されます.
ruby-itest test/unit/user_を使用することもできます.test.rbはこのテストを走りに来た.
1行目はテストに使用するコマンドで、2行目からテストの結果です.
6行目は1つです.代表は2つのテストを実行しました.代表は2つのテストがあります.(Fがテストに失敗した場合、Eが放出異常を表します).
8行目は、実行時間の統計、総時間、1秒当たりのテスト数、1秒当たりの断言数です.
10行目は、いくつかの統計、テスト個数、断言個数、失敗個数、エラー個数、スキップ個数です.
上のテスト結果は、0.8秒を費やしてテストに合格したと断言するテストがあることを示しています.
失敗したテスト、すなわち不正なnicknameを追加して、何が起こるか見てみましょう.
テストメソッドは、上記のフォーマット、def定義メソッドと書くこともできますが、約束通りtest_はじめに.assert関数にはオプションのstringパラメータが含まれており、stringの情報はテストに失敗した後に表示されます.
実行結果は次のとおりです.
6行目は1つですとF、成功、失敗.
次に、失敗したテスト情報、テスト方法、assertで指定したテストに失敗した後に表示すべき情報を表示します.
どうして失敗したの?
テストでnickname=>「nickname」*5を使ったので
文字列*numは、文字列がnum回繰り返されることを表し、nicknameのvalidatesで定義する長さの範囲は1である.30、最大長さは30ですが、「nickname」を5回繰り返した後、私たちの定義を明らかに超えました.しかし、断言はやはりユーザーオブジェクトが有効で、これは明らかに間違っているので、テストに失敗し、合格しませんでした.
しかし、これは私たちの目的ではありません.私たちの目的はnicknameがvalidatesに合わないオブジェクトを生成し、nicknameのvalidatesが機能しているかどうかを見て、userを判断することです.invalid?trueに等しいかどうか.
2番目のテストを直してください.
テストコマンドを続行し、テスト結果を確認します.
今回は2つのテストが合格したことを示した.
私たちのnicknameに対するvalidatesが正しい役割を果たしたことを示しています.
比較的完全なユニットテストには、テストのカバー率を向上させるために、さまざまな可能性のある状況が含まれるべきである.たとえば、境界値のチェック.
nicknameのテストをいくつか追加し、有効な状況をいくつかチェックし、無効な状況をチェックします.nicknameの空の値、長さ=30、長さ=31、長さは31を超えています.
また、Userにも参加することができます.authenticateメソッドのテスト.
ユニットテストについて、今日はここまで紹介します.皆さん、何か考えがありますか.伝言を歓迎します.
今日は実際にユニットテストを書いてみましょう.主にfixturesとunit testです.fixturesはデータをシミュレートするために使用され、unit testは私たちの今日の主役-ユニットテストです.
今日のコードはblogプロジェクトを背景に、このプロジェクトのためにいくつかのユニットテストを書きます.
このプロジェクトのコードはhttps://github.com/woaigithub/blog取得され、プロジェクトはすでに配備されています.http://42.121.5.68:10000/、導入した本番環境に直接自分のブログを書くこともできます.
masterはメインブランチ,developは開発ブランチであり,開発ブランチのコードは最新である.
プロジェクトはruby on railsを用いて開発し、開発及びテスト環境はsqlite 3をデータストレージとし、生産環境はmysqlをデータストレージとして使用する.
ユニットテスト
railsのユニットテストは主にmodelに対して、modelは私たちのビジネスエンティティです.ユニットテストは主にmodelのvalidatesとmodelのビジネスルールをテストし、テストはビジネスルールの実行を経て、私たちのmodelの変化は、modelの属性値であり、ルールの説明に合っているかどうか、予想される値になっているかどうかです.
==広告開始
このブログはコラボレーションのブログプラットフォームとして位置づけられています.分類、tagなど、皆さん一人一人がブログを書いたり、ブログの管理をしたりすることができます.
ブログの主なターゲットユーザーは開発者であり、他のタイプの業者がこのプラットフォームでブログを発表することを歓迎しています.
右上の登録で、このブログプラットフォームのadminになり、ブログを書き、ブログを管理することができます.もちろん、ブログを見るには登録する必要はなく、直接閲覧することができます.
footerセクションにはadminリンクがあり、リンクを介してバックグラウンドに入ることができます.もちろん、バックグラウンドに入るにはログインが必要です.
ブログのプラットフォームはまだ开発中で、もしみんなが何か良い考えがあるならば、あるいは开発に参加したいならば、すべてhttps://github.com/woaigithub/blog伝言を書く.
==広告終了
私たちの今回のプロジェクトはブログで、基本的な機能があります.
表の構造は次のとおりです.
### users
### tags
### categorys
### comments
### posts
### posts_tags
私たちのmodelにはvalidatesルールがいくつか書かれています.長さ、タイプ、必須です.今日のユニットテストの主な目標はこれらのvalidatesです.
まずuserのmodelを見てみましょう.
- class User < ActiveRecord::Base
- attr_accessible :email, :nickname, :password, :password_confirmation
- attr_accessor :password, :password_confirmation
-
- validates :password, :confirmation => true
- validates :password_confirmation, :presence => true
-
- validates :email, :presence => true, :uniqueness => true, :format => { :with => /^\w+@\w+\.\w+$/ },
- :length => { :maximum => 40 }
- validates :nickname, :presence => true, :length => { :in =>1..30 }
-
- has_many :posts
modelでは4つのmass-assignment:email,nickname,password,password_を宣言した.confirmation.
それぞれvalidates、長さ、フォーマット、パスワードconfirmationがあります.
test/unit/user_を開くtest.rbファイル、このファイルはrails g model userまたはrails g scaffold userを使用した後に作成され、中のテスト時計回りにuserというmodelのユニットをテストします.
モデルがコマンドで生成されず、自分で書いたコードである場合、このテストファイルも手動で作成する必要があります.
空白のuser_を先に作成できますtest.rbファイルは、いくつかの基本的な内容が含まれており、テストは含まれていません.
- require 'test_helper'
-
- class UserTest < ActiveSupport::TestCase
-
- end
中のいくつかのコマンドは約束を守る必要があります.railsの3つの特性の1つはconvention over configurationです(約束は構成より優れています).約束にはいくつかのメリットがあります.一つは、みんなのコミュニケーションを減らすことです.そして、約束を知っている人はコードを読むことができ、ファイルやコードの内容をすぐに理解することができます.二つ目は、約定された名称に対して統一的なコード処理を行うことである.
rails :
テストクラスはモデルの名前+Testをクラス名とし,クラスはActiveSupport::TestCaseを継承する必要がある.
まずnicknameに対するvalidatesのテストを書きます.nicknameのvalidatesには、必須と長さ範囲1-30の2つの内容が含まれています.
考え方はuserオブジェクトを作成し、userが有効かどうかを見て、userを通じてvalid?userが有効かどうか、すなわちuserに対するvalidatesが通過するかどうかを判断する.
他の属性のvalidatesがnicknameのvalidatesのテストに干渉しないことを保証するために、他の属性の値が属性に対応するvalidatesに合致することを保証する必要があります.
まず合法的なnicknameのテストを追加します.つまり、私たちのuserオブジェクトのnicknameはvalidatesのルールに合っています.
- require 'test_helper'
-
- class UserTest < ActiveSupport::TestCase
-
- test "user's nickname should be valid" do
- user = User.new(:nickname => "nickname", :email => "[email protected]", :password => "123", :password_confirmation => "123")
- assert user.valid?
- end
-
-
- end
テスト...do...endは1つのテスト方法で、SRP(職責単一の原則)に基づいて、私たちのテストも職責単一で、1つのテストを維持して1つのことだけをして、1つの内容だけに対してテストを行います.
このテストには2行のコードがあり、最初の行はmass-assignmentでuserオブジェクトを作成し、各プロパティに合法的な値を割り当てます.2行目は、userオブジェクトが有効かどうかを判断する断言関数です.
私たちはrake testコマンドでこのテストを走ります.次の出力結果が表示されます.
- ➜ blog git:(develop) rake test TEST=test/unit/user_test.rb
- Run options:
-
- # Running tests:
-
- .
-
- Finished tests in 0.803616s, 1.2444 tests/s, 1.2444 assertions/s.
-
- 1 tests, 1 assertions, 0 failures, 0 errors, 0 skips
ruby-itest test/unit/user_を使用することもできます.test.rbはこのテストを走りに来た.
1行目はテストに使用するコマンドで、2行目からテストの結果です.
6行目は1つです.代表は2つのテストを実行しました.代表は2つのテストがあります.(Fがテストに失敗した場合、Eが放出異常を表します).
8行目は、実行時間の統計、総時間、1秒当たりのテスト数、1秒当たりの断言数です.
10行目は、いくつかの統計、テスト個数、断言個数、失敗個数、エラー個数、スキップ個数です.
上のテスト結果は、0.8秒を費やしてテストに合格したと断言するテストがあることを示しています.
失敗したテスト、すなわち不正なnicknameを追加して、何が起こるか見てみましょう.
- def test_user_nickname_should_be_invalid
- user = User.new(:nickname => "nickname"*5, :email => "[email protected]", :password => "123", :password_confirmation => "123")
- assert user.valid?, "nickname is invalid"
- end
テストメソッドは、上記のフォーマット、def定義メソッドと書くこともできますが、約束通りtest_はじめに.assert関数にはオプションのstringパラメータが含まれており、stringの情報はテストに失敗した後に表示されます.
実行結果は次のとおりです.
- ➜ blog git:(develop) ✗ ruby -Itest test/unit/user_test.rb
- Run options:
-
- # Running tests:
-
- .F
-
- Finished tests in 0.264424s, 7.5636 tests/s, 7.5636 assertions/s.
-
- 1) Failure:
- test_user_email_should_be_invalid(UserTest) [test/unit/user_test.rb:12]:
- email is invalid
-
- 2 tests, 2 assertions, 1 failures, 0 errors, 0 skips
6行目は1つですとF、成功、失敗.
次に、失敗したテスト情報、テスト方法、assertで指定したテストに失敗した後に表示すべき情報を表示します.
どうして失敗したの?
テストでnickname=>「nickname」*5を使ったので
文字列*numは、文字列がnum回繰り返されることを表し、nicknameのvalidatesで定義する長さの範囲は1である.30、最大長さは30ですが、「nickname」を5回繰り返した後、私たちの定義を明らかに超えました.しかし、断言はやはりユーザーオブジェクトが有効で、これは明らかに間違っているので、テストに失敗し、合格しませんでした.
しかし、これは私たちの目的ではありません.私たちの目的はnicknameがvalidatesに合わないオブジェクトを生成し、nicknameのvalidatesが機能しているかどうかを見て、userを判断することです.invalid?trueに等しいかどうか.
2番目のテストを直してください.
- def test_user_with_invalid_nickname
- user = User.new(:nickname => "nickname"*5, :email => "[email protected]", :password => "123", :password_confirmation => "123")
- assert user.invalid?, "nickname is invalid"
- end
テストコマンドを続行し、テスト結果を確認します.
- ➜ blog git:(develop) ✗ ruby -Itest test/unit/user_test.rb
- Run options:
-
- # Running tests:
-
- ..
-
- Finished tests in 0.458872s, 4.3585 tests/s, 4.3585 assertions/s.
-
- 2 tests, 2 assertions, 0 failures, 0 errors, 0 skips
今回は2つのテストが合格したことを示した.
私たちのnicknameに対するvalidatesが正しい役割を果たしたことを示しています.
比較的完全なユニットテストには、テストのカバー率を向上させるために、さまざまな可能性のある状況が含まれるべきである.たとえば、境界値のチェック.
nicknameのテストをいくつか追加し、有効な状況をいくつかチェックし、無効な状況をチェックします.nicknameの空の値、長さ=30、長さ=31、長さは31を超えています.
- require 'test_helper'
-
- class UserTest < ActiveSupport::TestCase
-
- test "user have valid nickname" do
- user = User.new(:nickname => "nickname", :email => "[email protected]", :password => "123", :password_confirmation => "123")
- assert user.valid?, "user should have valid nickname"
- end
-
- def test_user_nickname_length_equal_min_1
- user = User.new(:nickname => "n", :email => "[email protected]", :password => "123", :password_confirmation => "123")
- assert user.valid?, "use should have valid nickname"
- end
-
- def test_user_nickname_length_equal_max_30
- user = User.new(:nickname => "m"*30, :email => "[email protected]", :password => "123", :password_confirmation => "123")
- assert user.valid?, "use should have valid nickname"
- end
-
- def test_user_without_nickname
- user = User.new(:email => "[email protected]", :password => "123", :password_confirmation => "123")
- assert user.invalid?
- end
-
- def test_user_nickname_length_equal_31
- user = User.new(:nickname => "d"*31, :email => "[email protected]", :password => "123", :password_confirmation => "123")
- assert user.invalid?
- end
-
- def test_user_nickname_length_more_than_31
- user = User.new(:nickname => "nickname"*5, :email => "[email protected]", :password => "123", :password_confirmation => "123")
- assert user.invalid?
- end
-
- end
また、Userにも参加することができます.authenticateメソッドのテスト.
- def test_should_authenticate_with_matching_email_and_password
- user = User.create(:nickname=>"asdf",:email=>"[email protected]",:password=>"123",:password_confirmation=>"123")
-
- assert User.authenticate({:email=>"[email protected]",:password=>"123"})
- end
-
-
- def test_should_not_authenticate_with_incorrect_password
- user = User.create(:nickname =>"ddd",:email=>"[email protected]",:password=>"123",:password_confirmation=>"123")
- assert_nil User.authenticate({:email=>"[email protected]",:password=>"234"})
- end
-
ユニットテストについて、今日はここまで紹介します.皆さん、何か考えがありますか.伝言を歓迎します.