1

私は Rails 開発を始めてまだ少しですが、かなり早く習得することができました。私がまだ迷っている領域の 1 つは、テストの作成です。

テストの書き方は理解していますが、何をテストすればよいのかがわからず、実際に独自のテストを書き始めるのが難しくなっています。

私は最近、取り組んでいるプロジェクトの API で使用する gem を作成しましたが、これがいくつかのテストを作成するのに最適な時期であると考えました。私はまだ何をテストすべきか迷っています。

何をテストすべきかについて誰かが私にいくつかのアイデアを与えることができるかもしれないいくつかのメソッドで私のクラスの1つを投稿した場合、私は望んでいました.

私が使用している API は JSON オブジェクトを返すため、私のメソッドはすべて、GET 要求を作成し、作成中のアプリケーションに JSON を返すヘルパーにすぎません。HTTParty gem を使用して get リクエストを作成しています。

最初の方法は、特定の広告主に関するいくつかの情報をリストするだけです:

    module MyModule

    class User < MyObject

      # User
      # This will list information about a specific user
      # required parameter(s):
      #     user_id
      # example:
      #   MyModule.connect("Your API Key")
      #   MyModule::User.list(5)
      # returns:
      #   Returns a single result with the following properties:
      # {
      #    "user_name":"blah",
      #    "user_id":253,
      #    "last_login":"2011-03-01"
      # }   
         def list(user)
      MyModule.get("/users/#{user}")
         end
    end
   end

私の最初の推測では、この JSON オブジェクトが正しいプロパティで返されることを確認するためにテストすることになりますが、完全にはわかりません。

メソッドに渡される引数がそこにあることを確認するためにテストする必要がありますか、それとも心配する必要はありませんか?

4

3 に答える 3

1

単体テストでは、オブジェクトの構成ではなく、オブジェクトまたはメソッドの動作をチェックする必要があります。それでも、ここでテストできるのは実際には2つだけです。

  1. GETリクエストが成功する（または成功しない）こと。
  2. 有効なJSONを取得する（または取得しない）こと。
  3. あなたの記録が壊れていないこと。

おそらく少し高いレベルでテストする必要があります。たとえば、このユーザーストーリーをテストします。

Given a record with some reasonable fixture data,
When the record is successfully retrieved
Then your application does something useful with it.
于 2012-07-09T17:46:36.573 に答える
0

テストとしてではなく、クラスの動作の例として考えると役立つと思います。@CodeGnomeの答えはかなり的確です。コードと説明を読むと、明らかに価値のある動作の側面が1つあります。それは、クラスが広告ユーザーに関するログイン情報を見つけることです。（RubyおよびRails固有の構文についての知識が不足していることをお許しください。@ CodeGnomeと同じように実行しますが、より具体的な例を使用します）。

クラスは「広告ユーザーの最後にログインした日付を取得する必要があります」。これは、その動作に一致する説明のように見えます。その後、テストメソッドに名前を付けることができます。

次に、いくつかの特定の例について考えてみましょう。ユーザーに応じて異なるデータを取得することはありますか？ユーザーが以前にログインしたことがない場合はどうなりますか？ユーザーIDが間違っている場合はどうなりますか？MyModuleは常に利用可能ですか、それともモバイル接続が失われた場合は利用できない可能性がありますか？それではどうしますか？あなたのクラスが「接続エラーをエスカレートする必要がある」というのは本当ですか？

このように考えることで、行動のさまざまな側面とさまざまな例を見つけることができます。RSpecのようなものは、それらを簡単に表現するのに役立ちますjust_use_underscored_test_names。

動作のさまざまな側面がない場合は、おそらく時期尚早のリファクタリング/最適化があり、抽象化レイヤーが多すぎます。

クラスがどのように動作し、なぜそれが価値があるのか​​を例を見ていることを覚えておいてください。そうすれば、クラスを文書化して理解しやすくなります。これを使用して、クラスの責任を改善し、保守を維持できるようにします。それは実際にはテストについてではありません。

于 2012-07-09T23:51:02.593 に答える
0

テストに関することは、どれだけ徹底したいかについてはすべてあなた次第です。理想的な世界では、アプリケーションのすべての側面をテストします。おそらくサイド プロジェクトに取り組んでおり、アプリケーションのプログラミングに時間を費やす方がよいので、基本的なフロー テストだけでニーズに合うと思います。

はい、正しい JSON プロパティを確認することから始めましょう。

使用しているテスト スイートについて言及していませんでした。まだ何も考えていない場合は、rspec をお勧めします。

それが役立つことを願って、

レーガン

于 2012-07-09T17:41:26.993 に答える