質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Ruby on Rails

Ruby on Railsは、オープンソースのWebアプリケーションフレームワークです。「同じことを繰り返さない」というRailsの基本理念のもと、他のフレームワークより少ないコードで簡単に開発できるよう設計されています。

Q&A

解決済

1回答

2474閲覧

なぜRuby on Railsのテストで失敗するコードを書かなければいけないのか知りたい

mbase

総合スコア17

Ruby on Rails

Ruby on Railsは、オープンソースのWebアプリケーションフレームワークです。「同じことを繰り返さない」というRailsの基本理念のもと、他のフレームワークより少ないコードで簡単に開発できるよう設計されています。

0グッド

4クリップ

投稿2018/04/14 07:31

編集2018/04/14 07:32

Ruby on Rails チュートリアルを進めています。

Ruby on Rails チュートリアルはテストについて非常に多く割いていますが、テストにどんなメリットがあるのか、いまだに腹落ちできていません。

「失敗するテスト」を書いて、そのあとテストに通過するコードを書くことの意味や重要性が理解できていないのだと思います。

ここで、Ruby on Rails チュートリアルの以下のコードを具体例として挙げたいと思います。

これはチュートリアルの「6.2.3 長さを検証する」の部分です。

まず、test/models/user_test.rb に以下を記述します。

require 'test_helper' class UserTest < ActiveSupport::TestCase def setup @user = User.new(name: "Example User", email: "user@example.com") end . . . test "name should not be too long" do @user.name = "a" * 51 assert_not @user.valid? end test "email should not be too long" do @user.email = "a" * 244 + "@example.com" assert_not @user.valid? end end

上記をテストするとREDとなります。

$ rails test

テストをパスするために、以下のコードを app/models/user.rb に追記します。

class User < ApplicationRecord validates :name, presence: true, length: { maximum: 50 } validates :email, presence: true, length: { maximum: 255 } end

再びテストすると、GREENとなります。

$ rails test

ここまでのテストコードを踏まえて回答をいただきたいのは、以下の2点です。

  1. なぜ失敗するコードを最初に書かなければいけないのでしょうか?
  2. なぜ、user_test.rbのコードは失敗になるのでしょうか?

(おそらく、 assert_not @user.valid? の意味が理解できていません)

まだまだ初心者の域を出ていないので、なるべく噛み砕いてわかりやすく文章にしていただけると助かります。

どうか皆様にお力添えいただけますと幸いです。よろしくお願いします。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

defghi1977

2018/04/14 07:33

意図したとおりに正しく「失敗している」ことを確認することも立派なテストなのですよ(テスト機構の”テスト”といったように)
guest

回答1

0

ベストアンサー

  1. なぜ失敗するコードを最初に書かなければいけないのでしょうか?

初心者の場合、テストの意義を真の意味で理解するのは無理です。
馬鹿にしているわけではないので怒らないのでほしいのですが、
テスト駆動開発というのは、
何らかの仕様があって、それを実装できるのは当たり前の状態の人を対象としてます。
RailsやRuby、Webアプリケーションの開発経験が十分にない状態では、コードの品質について考える事はなかなかないでしょう。
テストはコードの品質を高める(リファクタリング)、仕様を動くコードとして表現するドキュメントとしての役割もあります。

それから、別に失敗するテストを書いているわけではない点にも注意してください。
結果として失敗するだけです。ここが重要です。

まず何かを実装するという場合、仕様が先にあります。
ある入力に対して、出力がどうなるのが正しいのか?という事を定義するのが仕様です。
それをそのままテストとして書きますが、この段階では、その仕様は実装されていませんよね。
実装の前にテストを書くので、メソッドがなかったり、新しい仕様に対して現在のコードが対応していないので、テストが失敗するというわけです。

わざわざ失敗するテストを書くという考え方ではなくて、
まずこういう仕様を今から作るぞと自分の頭を整理するためにテストを書きます。
そして、正しく実装できたら、このテストデータに対して、こういう結果になるはずという事を記述するのがテストです。

初心者のうちは、いきなり実装を進めて行って、あれ?うまく行かないぞ?となって、作り直しをたくさんします。
中級者くらいになると、いきなり手を動かさずにじっくり考えて整理してから実装すると手戻りが少ないという事を経験として学びます。
その手段の1つとして、テストを先に書くという方法があるわけです。

正しくテストを記述できれば、すべてのテストが合格するように実装を進めればいいだけなので、試行錯誤するにしても手戻りが少なくて済みます。
これも経験則でそう分かるようになるのですが、プログラミング自体が初心者だったりすると、これは頭では理解しても、腑に落ちないでしょう。


  1. なぜ、user_test.rbのコードは失敗になるのでしょうか?

さきほど回答した内容に即していくと、

(1) 仕様を先に決める(頭の中だけでもいいし、紙に書いたりしてもいい)
(2) 仕様をテストとして記述する
(3) 仕様を満たすために実装する

まず、Userモデルですが、バリデーションがない状態とします。

ruby

1class User < ApplicationRecord 2end

この状態の時に、

(1)仕様を決める

・nameの長さは50文字以内
・emailの長さは255文字内

という仕様を実装者=あなたが考えたというシチュエーションをRailsチュートリアルではやっているものと思われます。
というか、そうしないとテストの内容と整合性がないわけですから。

(2)仕様をテストとして記述する

ちょっとRailsチュートリアルのテスト説明がおかしいというかふさわしくないので、日本語で書かせてもらいます。

それから、チュートリアルのコードをそのまま先頭から順番に写していますか?
一般的にプログラムというのは、そういう風に書きませんので、注意が必要です。
私ならば、まずこのように大枠だけ書きます。

ちなみに、assert_notは引数の結果がfalseの時にテストが成功とする命令です。
ここではバリデーションが失敗する@user.valid?の結果がfalseとなる事を期待するテストを書くつもりというわけです。

ruby

1class UserTest < ActiveSupport::TestCase 2 ... 3 4 test "nameの長さは50文字以内である事" do 5 # 50文字を超えたらエラーになる 6 end 7 8 test "emailの長さは255文字以内である事" do 9 # 255文字を超えたらエラーになる 10 end 11 12end 13

これで仕様を定義できました。
次にテストとして成立するように追記します。
さきほどの「~文字を超えたらエラーになる」はToDOメモというかそういう風にテストを書くよという意味のメモなので、テストを実際に書くときには消します。

ruby

1class UserTest < ActiveSupport::TestCase 2 ... 3 4 test "nameの長さは50文字以内である事" do 5 # エラーを起こすために、わざと51文字を設定する 6 @user.name = "a" * 51 7 8 # もし、正しくバリデーションが設定されていたら、 9 # バリデーションがfalseになるはず 10 # assert_notは引数の結果がfalseに時にテストが成功する 11 assert_not @user.valid? 12 end 13 14 test "emailの長さは255文字以内である事" do 15 # エラーを起こすために、わざと255文字を超える文字列を設定 16 # "a" * 256だけでもいいでしょう 17 @user.email = "a" * 244 + "@example.com" 18 19 assert_not @user.valid? 20 end 21 22end 23

この状態でテストを実行すると、当然失敗するはずなんですね。
Userにバリデーションを書いていないから、@user.valid? がtrueを返すため、
assert_not true となり、テスト失敗。

まずは、これを確認する事で、今のコードの状態が正しいと認識できます。
これでテストが一部でも成功してしまうと、自分の認識と現状のコードの状態がずれているという事になり、どこかにミスがあるという事が発見できるわけです。

(3) 仕様を満たすために実装する

テストを書く事によって、ゴールまでの道筋が見えました。
あとは、テストが通るように実装するだけです。
この例では、バリデーションを追加するだけなので、説明不要ですね。

投稿2018/04/14 08:17

mingos

総合スコア4025

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

mbase

2018/04/14 09:26 編集

回答ありがとうございます。すごくわかりやすくて勉強になりました。何度も読み返したくなる保存版になりそうです。 おっしゃる通り、まだ腑に落ちないところもありますが、assert_not @user.valid?が意味するところがわかったので、大きく前進できた気がします。 お手数ですが、もし可能でしたら以下の2点についてもご回答をいただけますと幸いです。 1. 的外れだったら恐縮ですが、「テストは自分が実装したいコード(内容)と現状のコードを比較して、どの部分が乖離しているかを調べるためのもの」「どの部分を修正する(手を加える)べきか調べるもの」という認識で合っておりますでしょうか? 2. そもそもの文法の理解がまちがっていたら申し訳ありませんが、@user.valid? はそれぞれ 「@user.name.valid?」「@user.email.valid?」と書くことはできない(しない)のでしょうか?
mingos

2018/04/14 09:31

1. について だいたいそんな感じですね。ほかにも解釈があるんですが、いろいろやっていくうちに分かって来ます。 他にも、コード量が増えてくると、一部の修正がほかの部分に影響を与えて仕様が変わってしまう=バグが生まれる場合があります。 この時にその影響部分のテストがしっかり書いてあると、テストが通らないという事になり、バグの発見につながる場合もあります。 なんというか、テストは自分が安心するためにあります。 2.について @user.nameや@user.emailの戻り値というか、データ型はStringオブジェクトですよね。 Stringオブジェクトにvalid?というメソッドはないからです。 あくまでも、ApplicationRecordを継承したオブジェクト(User)にだけ、valid?があるのです。
mbase

2018/04/14 09:36

ありがとうございます。あらためて御礼申し上げます。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問