1

Twilio SMS APIを実装しているRailsアプリケーションがあり、デザインをテストドライブする方法に少し迷っています。

まず、twilio APIをカプセル化するSMSメーラーであるモデルを作成しました。これをテストして、SMSクレジットを使い果たしたり、テストテキストメッセージで誰かを攻撃したりせずに機能を確認できるようにしたいと思います。

APIを実装してコードで機能させる方法は知っていますが、実際にコードをテストして、機能することを確認し、将来の破損を防ぐことが必要です。誰かアドバイスをいただけますか？

ありがとう！

4

5 に答える 5

4

You could use my gem Twilio.rb, which is already tested, and then mock it out in your tests, e.g. with mocha

Twilio::SMS.expects(:create).with :to => '+19175551234', :from => '+12125551234', :body => 'this is easy!'

Your unit tests should never hit external services, they should always be mocked. This is follows from a general principle of unit testing that tests should not extend the class boundary of the object being tested and collaborator objects should be mocked/stubbed.

Hope this helps!

https://github.com/stevegraham/twilio-rb

于 2011-02-02T18:02:00.287 に答える
2

テストおよびTwilioアプリケーションのテストに関する私の経験では、追加するリスクを排除するためにテストします。独自のSMSコードをRESTエンドポイントに対してロールするのではなく、 Twilio gemを使用することをお勧めします。これにより、リスクの量が最小限に抑えられます。

APIをビジネスロジッククラスで可能な限り薄くラップし、主にビジネスロジックをテストします。たとえば、私のシステムでは、SMSはリマインダークラスから送信されます。コードは次のようになります。

class SomeWrapperClass
  if (RAILS_ENV == "testing")
    @@sent_smses = []
    cattr_accessor :sent_smses
  end

  def send_a_message(to, from, message, callback_url = nil)
    unless RAILS_ENV == "testing"
      Twilio::SMS.message(to, from, message, callback_url)
    else
      @@sent_smses << {:to => to, :from => from, :message => message, :callback_url => callback_url}
    end
  end
end

これにより、ビジネスロジックに焦点を当てたテストを作成できます。これは、私が台無しにするものです。たとえば、SMSメッセージを送信するメソッドsend_reminder（client）をテストする場合：

test "sends reminder to client" do
  SomeWrapperClass.sent_smses = []
  client = clients(:send_reminder_test_case)
  Reminder.send_reminder(client)
  sent_message = SomeWrapperClass.sent_smses.last
  assert !sent_message.blank?, "Sending a reminder should fire an SMS to client."
  assert sent_message.index(client.name) >= 0, "Sending a reminder should fire an SMS with the client's name in it.
  ...
end

今、私が追加した実際のリスクをテストしています。それは、Reminder.send_reminderを台無しにしているということです。一方、ラッパーはリスクフリーに近い必要があります。

于 2011-02-02T18:10:38.613 に答える
1

明らかに、可能な限り多くのロジックを分離します。これを行うことで、他のすべてを可能な限りテストし、テストが必要な外部APIへの呼び出しのみを残すことができます。

外部APIの操作には注意が必要です。1つのオプションは、うまくいくことがわかっているもの、または期待する応答への応答をモックすることですが、これは明らかに少しもろい場合があります。別のオプションは、VCRのようなものを見ることです。これにより、外部APIへの呼び出しが一度記録され、再度呼び出すたびに再生されます。

于 2011-02-02T16:49:44.343 に答える
1

おそらく twiliolib のコードをテストする必要はありませんが、twiliolib のメソッドをスタブ化したくない場合は、指定された要求に対する応答を定義する FakeWeb gem を使用できます。

スティーブが言及したのと同様に、mocha でリクエストをスタブします。

# In Twilio initializer
TWILIO_ACCOUNT = Twilio::RestAccount.new(TWILIO_CONFIG[:sid], TWILIO_CONFIG[:token])

# In a test helper file somewhere
class ActiveSupport::TestCase
  # Call this whenever you need to test twilio requests
  def stub_twilio_requests
    # Stub the actual request to Twilio
    TWILIO_ACCOUNT.stubs(:request).returns(Net::HTTPSuccess.new(nil, nil, nil).tap { |n| 
      n.stubs(:body).returns("<?xml version=\"1.0\"?>\n<TwilioResponse></TwilioResponse>\n") 
    })
  end
end
于 2011-02-02T19:01:14.460 に答える
1

この男はあなたの問題を解決し始めたようです: https://github.com/arfrank/Fake-Twilio-Api

于 2011-02-02T18:08:13.557 に答える