AWS SQSのvisibility timeoutとdelay queueのdelayの違いについて
今週の復習です。
consumerがキューからメッセージを受信するリクエストを送った後、
- 通信の問題で結局受け取れなかった
- consumer側で処理中にエラーになって結局最後まで処理できなかった
などの事態に備えるため、SQSのキューにあるメッセージはconsumerが受け取った時点では消えない。
consumerはメッセージを受信して処理した後、キューに対してメッセージ削除のリクエストを送る必要がある。
また、
- SQSのキューにある1つのメッセージを複数のconsumerが受信してもおかしくない
ので、
- SQSのキューの仕組みとして: キュー上のあるメッセージに受信リクエストが来た後、指定の秒数の間は他のconsumerにそのキューを見せない
visiblity timeout
を設定する*1 - 実装側として: 複数のconsumerが同じメッセージを処理しても問題ない実装にしておく
ということを考える必要がある。 visiblity timeout
はデフォルトだと 30秒の設定となっている*2。
visiblity timeout
を利用している場合、SQSのキューに溜まっているメッセージの数は
ApproximateNumberOfMessagesNotVisible
(あるconsumerがそのメッセージを処理しているかも)ApproximateNumberOfMessagesVisible
(どのconsumerもまだそのメッセージを処理していないかも *3 )
の合計となる。
上記がSQSのふつうのキューを使った場合で、キューを使った非同期で動くシステムの中には、キューにメッセージを送った直後はそのメッセージを消費して欲しくない、という場合がある*4。その場合は、delay queueを利用する。
SQS delay queueを利用した場合、
- standard queueでキューから取り出そうとしたメッセージに対して
visiblity timeout
の設定を利用した場合: あるconsumerが受信リクエストを送った後、指定の秒数他のconsumerからメッセージが取得できなくなる
のに対し
- delay queue に追加されたメッセージの場合: producer からメッセージをキューに追加された後、delayで指定した秒数consumerからメッセージが取得できなくなる
の違いがある。また、
visiblity timeout
の設定はキューに詰めるメッセージに個別に指定- delay queueのdelayの設定はキューに対して指定(=>キューに入るメッセージ全体に適用)
される。
delay queueにおいて、全体に適用されるdelayの設定は固定ではなく、メッセージによってはdelayの値を変えたい、といった場合は message timer の delay seconds の指定で上書きが可能*5。
delay queueのユースケースがわからないので、もやりとしていますが、現場からは以上です。
*1:というより、デフォルトで30秒に設定されている
*2:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html
*3:これはconsumerがメッセージを処理するのに必要な時間に応じたvisibility_timeoutを設定している想定で、この辺が適切でなかった場合はその限りではない
*4:このケースについて自分では調べててよくわからなかったんですが、sidekiqなどジョブ管理システムのキューにSQSを利用していて、デフォルトではリトライの時にちょっと時間をおいて欲しいとか、短時間のうちにキャンセルのリクエストがくる可能性があるジョブのリクエストを待つとか...? でも、キャンセルのメッセージがリクエストのメッセージと同じconsumerで処理されなければ意味がなくない...?
*5:https://www.slideshare.net/AmazonWebServicesJapan/aws-31275003 の27ページ目
ECSのタスク、サービス、クラスタ、コンテナインスタンスの意味についてまとめました
ECSのタスク、サービス、クラスタ... といった言葉の意味がいまいちよくわからなかったので、それぞれの言葉が指すインスタンスを作成するときに何を設定するかに基づいてまとめたメモです。
もとの説明をいい感じに引用して... とかの時間がなかったのでひとまずポスト。
クラスタ
- ネットワークとか、リソース管理の仕方(EC2使う or Fargate*1, EC2の調達の仕方)とか*2
- リソースの管理の仕方 => クラスタに属する EC2 の設定も管理している*3。特定のインスタンスタイプのEC2を決まった台数、特定のネットワーク内に調達することに関心がある*4
ECSのコンテナインスタンス
- ECSのコンテナインスタンス = Amazon ECS コンテナエージェントが入ったEC2インスタンス*5
- クラスタのところで設定した項目はほぼコンテナインスタンスに適用される。クラスタはそこに所属するコンテナインスタンスの設定を管理してる
- 登録解除 != 停止. 登録解除しただけだと前のコンテナ起動した時のローカルファイルが残ってるので注意
- ECSのコンテナインスタンスを確保 => ECSのコンテナインスタンス中のコンテナエージェントがタスク実行のリクエストを受け付ける
タスク定義
- クラスタが所定の台数Dockerの動くEC2のインスタンスを確保してくれているはずなので、そこにdocker-composeで投げるdocker-compose設定ファイル的なもの*6*7
- docker-composeの内容を書く = その内容は
docker-compose 投げた
先のEC2インスタンスがどういう性能を持っていないといけないか知っている
ECSタスクのスケジューリング *11
- 長期実行するステートレスサービスおよびアプリケーション用(要するにrailsのフロントとか)を常に指定した台数起動したい => サービススケジューラを使う
- サービススケジューラがタスクの実行台数を管理する単位がサービス
- service taskはサービスで管理されてるタスク
タスク = docker-composeで動く一連のコンテナの単位
の数をスケーリング != EC2インスタンスの数(こっちに対して課金)をスケーリング
- その場で実行する => 単発で実行されるバッチジョブとか RunTask
*1:この起動タイプはタスクを作成するときにも設定できる
*2:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ECS_clusters.html#cluster_concepts
*3:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create_cluster.html
*4:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/scale_cluster.html 2015 年 11月24日以降に作成したクラスターなら、 AWS CloudFormation スタックに関連付けた Auto Scaling グループを作成すると管理画面から何台起動させるか、といったことが変更できる
*5:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ECS_agent.html AMIで指定する単位だからほぼEC2だろう
*6:クラスタが何台分、と決めている枠の中でタスクを割り振る。クラスタの中にコンテナインスタスタンスが5台起動していて、タスクが3つなら、そのタスクで定義されたプロセスは3つしか動かないし、逆にクラスタの中にコンテナインスタンスが3台でタスクが5つなら複数のタスクが動くコンテナインスタンスが出てくる?
*7:同じタスク定義の中で定義されているコンテナは必ず同じインスタンスで動く http://www.slideshare.net/AmazonWebServicesJapan/aws-blackbelt-2015-ecs の36ページ
*8:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html#constraints (インスタンスタイプの指定はdockerで元になるOSが入ったimageを指定イメージに近い)
*9:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html#task_size
*10:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs_services.html
*11:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs_services.html
APNsのプッシュ通知で利用するプロバイダ証明書関連の各種ファイル形式について調べてみたメモ
前の記事では、APNsとプロバイダの間の接続信頼の話をしました。この記事では、接続信頼の確認に使う証明書関係のファイルの話をします。
複数の鍵や証明書をまとめて扱うための個人情報交換( .p12
)
まず、Push通知の証明書関連で調べているとよく出てくる .p12
という拡張子のファイルですが、これは日本語では 個人情報交換 と呼ばれています。
個人情報交換は、その内部に複数の鍵や証明書をまとめて格納することが可能で、パスワードでそれらのファイルを保護します。
たとえば、よくある1つのiOSアプリ用に使うプッシュ通知用の証明書だと、キーチェーンから書き出した .p12
ファイルの中にPEM形式の鍵と証明書が含まれています。なので、こちらの記事のように、 .p12
のファイルから .pem
のファイルを書き出したりします。
証明書のデータ構造のエンコーディング( PEM
, DER
)と公開鍵基盤用の規格 X.509
PEM
形式の鍵、証明書は鍵、証明書のデータの部分がBase64でエンコーディングされています*1。
これに対し、鍵、証明書のデータの部分がバイナリエンコーディングされているのが DER
形式の鍵・証明書で、 PEM
, DER
形式のファイルに含まれる証明書・鍵のデータは ASN.1(アセンワン)
という言語で定義されています*2。
もう少しかっちり書くと、 X.509
という公開鍵証明書と証明書失効リストを含む公開鍵基盤(PKI)について定義される規格があり、その中で PKI
用証明書のエンコーディングには ASN.1 DER
エンコーディングが使用されるように定義されています*3。また、 X.509
に基づいて作成・運用される証明書が X.509 証明書
と呼ばれているみたいです*4。
APNS - プロバイダ間の接続信頼を確認する際は、この X.509
証明書のデータを利用します。その際、エンコーディングされた文字列ではなく ASN.1
で定義された型のオブジェクトまでデコードする必要があります。
証明書署名要求( CSR
)を使ってAppleからの署名によりApple公認のプロバイダであることを証明する
順番はやや異なりますが、ここまで
X.509
という公開鍵基盤(PKI
)について定義する規格があるX.509
の公開鍵証明書はASN.1
という言語で*5型が定義されている個人情報交換
(.p12
のファイル) で、証明書のデータをエンコーディングしたPEM
と鍵のデータをエンコーディングしたPEM
などを合わせて格納する
という話をしました。では、鍵と証明書*6の .pem
ファイルが中に入った .p12
ファイルでありさえすれば、どんなものでも APNsとの間の接続信頼の確認に使えるのでしょうか。
もちろん、そうではありません。
APNsとの間の接続信頼を確認するためには、Appleと契約を結んだ組織に属していることを証明する必要があります。そして、そのために接続信頼の確認に利用する証明書にはAppleの署名が必要です。
公開鍵証明書に特定の組織(公開鍵基盤の言葉でいうと、認証局)の秘密鍵で電子署名をしてもらう。そのために認証局へ提出するファイル*7を 証明書署名要求(CSR: certificate signing request) といいます。
CSRを用いたApple側の署名入り証明書作成手順について備考
最後に、公開鍵基盤(PKI)の証明書署名要求(CSR)を用いた証明書の作成手順をAPNsの具体事例にあわせておさらいしておきましょう。
まず、IPAの資料によると証明書の発行プロセスは大別して
- 加入者(証明書が発行される側。APNs - プロバイダ間でいうとプロバイダ、アプリ開発者のほう)が鍵ペアを生成する方式
- 登録局が一括して鍵ペアを生成する方式
の2通りあります。
この記事などの手順にあるように、APNsから証明書発行してもらうプロセスはプロバイダ側がキーペアを含めたCSRを作成するところから始まるので1の方ですね。
まず、1. の手順に「加入者が鍵ペアを生成する」について。APNsの証明書を作成する場合は、「キーチェーンアクセス > 認証局に証明書を要求...」から .certSigningRequest
ファイルを作成します。
作成した .certSigningRequest
ファイルをApple開発者アカウントの管理画面からAPNsのシステムへアップロードすることが、KPIでいう加入者の認証局に対する証明書の発行申請にあたり、アップロード後にダウンロードした .cer
ファイルが Apple側の署名がなされた証明書となっています。
ところで、「加入者が鍵ペアを生成する」の文言と 「「キーチェーンアクセス > 認証局に証明書を要求...」から .certSigningRequest ファイルを作成」 の内容があってないですね。
実は「キーチェーンアクセス > 認証局に証明書を要求...」をクリックしたときの画面をみてみると
のようになっており、 .certSigningRequest
ファイルを作成する前に秘密鍵と公開鍵のキーペアを生成しているようです。
この秘密鍵はキーペアを生成したMac(システム)に配置され、キーチェーンからのみアクセスできるようで、他のMacに移行したりプッシュ系のmBaasを利用する場合などはAppleから発行された証明書( .cer
ファイル)に秘密鍵を含めて .p12
ファイルに書き出す必要があります*8。
参考
- https://developer.apple.com/jp/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html
- https://www.ipa.go.jp/security/pki/034.html#_Toc3020776
- https://qiita.com/kunichiko/items/12cbccaadcbf41c72735
- http://www.geocities.co.jp/SiliconValley-SanJose/3377/
- https://www.sambaiz.net/article/135/
- https://dev.classmethod.jp/smartphone/iphone/apple-certificates-summary-and-etc/
*1:余談ですが、Base64でエンコードすると最後に=ってつくことありますが、それはデータがエンコード文字列の長さで表せる量に対して中途半端に短かった時の穴埋めなんだそうな https://ja.wikipedia.org/wiki/Base64
*2:DERの仲間にBER, CERがあり、DERはBERのサブセット http://www.geocities.co.jp/SiliconValley-SanJose/3377/
*3:https://www.ipa.go.jp/security/rfc/RFC2459JA.html
*4:みたいですってなんやねんって話ですが、PEMとかファイル形式で説明されていることが多くてちょっとだけ自信がない
*5:X.509証明書以外にもASN.1で定義されているものはあります http://www.geocities.co.jp/SiliconValley-SanJose/3377/
*7:データさえ渡せればいいので、ファイルとして送る必要は特にないが、Appleの開発者管理画面の画面がファイルとしてアップロードする形だったのでファイル表記
*8:https://dev.classmethod.jp/smartphone/iphone/apple-certificates-summary-and-etc/
APNsを利用する際に必要な2種類の接続信頼について
APNsを利用する際に必要な2種類の接続信頼
APNsを利用する際には証明書やトークンが必要ですが、それは認証のためです。
ドキュメント*1には、暗号化されたデータが正しく復号できるか、途中で改ざんされていないかみたいな確認にあたる暗号化検証とあわせて 接続信頼 と呼ばれています。
この接続信頼には
- プロバイダ - APNs間の接続信頼
- APNSにリクエストを送ってきた人がプロバイダー(=プッシュ送りたい人、アプリ作った人)であることを証明する
- これが確認できないと、プロバイダとAPNsの間でやりとりはできない
- APNs - デバイス間の接続信頼
- APNsから通知を受信するデバイスが、認証を受けたもののみであることを証明するためのもの
の2種類があります。
プロバイダーAPNs間の接続信頼
まず、プロバイダーAPNs間の接続信頼の話をします。
プロバイダーAPNs間の接続信頼には「トークンベースのプロバイダ接続信頼」「証明書ベースのプロバイダ接続信頼」があり、それぞれ接続信頼を確認するために必要な手順やプロバイダのサーバに配置するファイルが異なります。
トークンベースのプロバイダ接続信頼
- WWDC2016で公表された方式。
- こちらの記事の手順で管理画面で Apple Push Notification Authentication Key(Sandbox & Production) を発行し、その際にダウンロードする
.p8
ファイルをサーバーに配置Apple Push Notification Authentication Key
の 有効期限は無期限 です(こちらの操作により無効にすることも可能)
- こちらの記事 に書いてあるような手順で
.p8
ファイルから秘密鍵を取り出し、時刻を利用して認証に使うトークンを生成します - バンドルIDが記載されているすべてのアプリケーションにおいて同じ
Apple Push Notification Authentication Key
を使うことが可能です - 余談として、ドキュメントの セキュリティアーキテクチャ > プロバイダ-APNs間の接続信頼 > トークンベースのプロバイダ接続信頼に
鍵ペアを生成し、公開鍵をAppleに渡してください。秘密鍵はプロバイダ側で保持し
と書いてあるものの、公開鍵をどうこうした覚えはなくて若干戸惑っていたり。。- これは推測ですが、秘密鍵がそのときDLする
.p8
ファイルに入っているので、多分公開鍵はApple Push Notification Authentication Key
を発行した時にAPNs側に保管されているのでしょう。。
- これは推測ですが、秘密鍵がそのときDLする
トークンベースの接続信頼を利用する場合に送るリクエストの例
HEADERS - END_STREAM + END_HEADERS :method = POST :scheme = https :path = /3/device/00fc13adff785122b4ad28809a3420982341241421348097878e577c991de8f0 host = api.development.push.apple.com authorization = bearer eyAia2lkIjogIjhZTDNHM1JSWDciIH0.eyAiaXNzIjogIkM4Nk5WOUpYM0QiLCAiaWF0I jogIjE0NTkxNDM1ODA2NTAiIH0.MEYCIQDzqyahmH1rz1s-LFNkylXEa2lZ_aOCX4daxxTZkVEGzwIhALvkClnx5m5eAT6 Lxw7LZtEQcH6JENhJTMArwLf3sXwi apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b apns-expiration = 0 apns-priority = 10 apns-topic = <MyAppTopic> DATA + END_STREAM { "aps" : { "alert" : "Hello" } }
- ヘッダーに接続信頼用の
authorization
キーがあります。 Apple Push Notification Authentication Key
は開発者アカウントと紐付いているすべてのアプリと紐付いているので、どのアプリ宛かを指定するためのapns-topic
の指定があります。- デバイストークンの指定は、
:path
で行われています。
証明書ベースのプロバイダ接続信頼
- 証明書ベースのプロバイダ接続は、プロバイダ証明書(具体的には .p12 ファイルや .pem の中に含まれているデータ)で指定されている特定の1つのアプリケーションのためのものです
- 接続信頼の確認に利用する証明書は事前に作成します
- 証明書ベースの信頼を利用する場合、APNsが証明書失効リストを作成、管理しています*4
- 証明書ベースでプロバイダ接続信頼を行う場合、証明書を使うのはTLS接続確立までで、個々のリモート通知リクエストの時は通知先のデバイストークンだけヘッダにつければよいです
- トークンベースの接続信頼で使う
Apple Push Notification Authentication Key
と違い、証明書ベースの接続信頼で使うSSL証明書(.p12ファイル)は1年の有効期限があります
証明書ベースの接続信頼を利用する場合に送るリクエストの例
HEADERS - END_STREAM + END_HEADERS :method = POST :scheme = https :path = /3/device/00fc13adff785122b4ad28809a3420982341241421348097878e577c991de8f0 host = api.development.push.apple.com apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b apns-expiration = 0 apns-priority = 10 DATA + END_STREAM { "aps" : { "alert" : "Hello" } }
- トークンベースの場合と違い、
authorization
キーはありません。 - 基本的に、証明書ベースの場合、証明書の中にどのアプリ用の証明書か含まれているため、証明書の中に記載されたトピックへのリクエストとして処理できるため、
apns-topic
の指定がありません- 複数のtopic用の証明書の場合は
apns-topic
の指定が必要です。
- 複数のtopic用の証明書の場合は
- デバイストークンの指定は、
:path
で行われています。
APNs-デバイス間の接続信頼
次にAPNs - デバイス間の接続信頼の話をします。
大枠を言うと
- iOSなどのデバイスの利用開始設定(アクティベーション時)に接続信頼に利用される暗号化証明書と秘密鍵がOSから提供される
- OSから提供された暗号化証明書と秘密鍵はキーチェーンに格納され、アプリケーションとは関係なしにAPNsとデバイスとの間の接続信頼に利用される
- (= デバイスとAPNsとの接続信頼のために、開発者がなにかする必要はない)
となります。
そうすると自分(プロバイダ)として関心があることは、このAPNs - デバイスが接続された上で、デバイスへのリモート通知リクエストに必要なトークンを取得することですが、この部分については開発者側で実装や設定が必要です。
iOSおよびtvOSでのデバイストークンの取得などを参考にアプリケーションがリモート通知リクエストを送るためにAPNsへリクエストを送り、結果を受け取る実装をし、また、Enable push notificationsを参考にアプリケーションがプッシュ通知を利用する設定が必要です。
参考
- Apple Push Notification サービス
- リモート通知サポートの設定
- Enable push notifications
- Golangで「プロバイダー認証トークン」を生成して、APNsにプッシュを送ろう
- Apple Push Notification Authentication Keyを発行しよう
*1:https://developer.apple.com/jp/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1
*2:かといって接続のたびに再発行してほしいわけではない
*3:アプリのリモート通知以外にもVoIP通知などの用途があり、その場合アプリのbundle IDに .voip がついた値をtopicに指定する https://developer.apple.com/jp/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html#//apple_ref/doc/uid/TP40008194-CH11-SW1
*4:これは、開発している時にはPush屋さんが失効時の挙動テストする時にAPNsのサンドボックスでの失効が遅い...(なんかSANDBOXの場合、半日くらい待ってる気がする) というくらいしか縁がないのではないか...
EMRのHiveのドキュメントを読むのが不自由だったので読み方からメモ
仕事で若干AWS EMR上のHiveにさわったので少しだけメモ。
ドキュメントの読み方とか頭いっぱいになってるとすっこ抜けて死んでいますが、EMRの他のサービスについても似たような感じに気をつければいいはずだ。。
マネージドサービスとはいえ、設定できる項目については基本の元々のソフトウェアの設定ファイルの名前とかが割と使えるようになっているかもしれないとか。。
EMR上に入っているHadoopその他のバージョンについて
RDSにはMySQLやPostgresをはじめとしたRDBSが、Elastic CacheにはRedisなどキーバリューストアがあらかじめインストールされているように、EMRには基本的にHadoopやApache Sparkがインストールされています。
このEMRにインストールされているバージョンはソフトウェアのバージョンはEMRのリリースバージョンごとに管理されていて、EMRのリリースバージョンに対するHadoopやApache Sparkのバージョンは https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-components.html から確認できます。
Hiveの設定ファイルとAWS EMRのconfigのキーの対応
Hiveを叩くためにHiveServerやHiveServer2を使って~みたいな話が出てきた時に、Hive の設定ファイルとして hive-site.xml
の内容が紹介されることがありますが、EMR上でHiveを利用する場合、 hive-site
という Classification
を利用して指定します。
// https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-external.html [ { "Classification": "hive-site", "Properties": { "javax.jdo.option.ConnectionURL": "jdbc:mysql:\/\/hostname:3306\/hive?createDatabaseIfNotExist=true", "javax.jdo.option.ConnectionDriverName": "org.mariadb.jdbc.Driver", "javax.jdo.option.ConnectionUserName": "username", "javax.jdo.option.ConnectionPassword": "password" } } ]
Hive JDBC Driverの利用について
Clouderaのとか、Apacheのとかあると思いますが、Amazonが用意してるJDBC Driverを使います。 ドキュメントはDLしたzipの中に入っています。。
Appleの証明書関連を調べるときに公式ドキュメントの「証明書」ページを読んでおくととても捗る
Appleの証明書関連を検索するとき、かなり検索しにくく感じるときがありますが、
のページに目を通しておくと公式ドキュメントのググラビリティが非常に上がります。というか、先に読んでおくもののはずなんですが、ググり方がわからなかったので、メモ。
また、上記ページの各種証明書がApple Developer AccountのどのフォームからDLされるものか、について追加でまとめます。
Apple Worldwide Developer Relations Certification中間証明書
ここのフォームからDLするだけだと拡張子が .cer
なだけでどの種類の証明書かわかりにくいんですが、このファイルをDLした.cerを開いたとき、キーチェーンに追加されるのが
となっています。
Apple Push Notification Service証明書
俗称・Push通知用の証明書、 .p12
に書き出すやつ
Identifiers > App IDs > 特定のApp ID
をクリックして下の方のEditボタンを押して出て来る
のフォームで作成・再作成・DLするもの。
iOS配布用証明書(App Store)/ iOS配布用証明書(社内用アプリケーション)
英語版のページと
Certificates - Support - Apple Developer
Provisioning Profile の作成フォームを見比べて
Provisioning Profile のこと。
みなさまにおかれましては、独自の証明書を使った認証の 利用者が不慣れな*1仕組みを実装、ならびにそのドキュメントを作成するときは拡張子(とサンプルファイル名)も書いていただけると非常に話がスムーズなので何卒よろしくお願いします。
現場からは以上です。
*1:調べてたら一般的な仕組みとわかってきた(また今度まとめよう...)ので訂正
RSpecでクラスの挙動や定数をテスト用のダミーにする、見慣れなかったマッチャ、普段は実行しないテストのスキップ、などの話
参加しているプロジェクトのRSpecを見ていたら見慣れないことがいろいろあったので、復習しておきます。
RSpecでクラスの挙動をダミー用のものにする
target_obj = double("target_obj") # initializeの文字のほうに深い意味はないらしい target_obj.stub(:string) { "Stub test" } # 以上は上と同じ target_obj = double("target_obj", :string => "Stub test") allow(target_obj)to receive(:post) # ダミーオブジェクトである target_obj に postメソッドを生やす # テストしたいメソッドの中で使われているクラスを初期化したらテスト用に用意したダミー実装が使われるようにする allow(Real::Target).to receive(:new).and_return(target_obj) # def testing_method # Real::Target.new.copy.string # end expect(testing_method).to eq "Stub test" # 所定のspecでだけ定数を置き換えたい stub_const("TARGET::CONST", 100)
参考
http://web-k.github.io/blog/2012/10/02/rspec-mock/ https://qiita.com/jnchito/items/640f17e124ab263a54dd
http://codenote.net/ruby/rspec/1800.html https://relishapp.com/rspec/rspec-mocks/docs/mutating-constants
match_array マッチャ便利かも
ActiveRecordから要素を取り出してくるけど、テスト用にベタがきする値と順序が一致していないので汚いコードを書いて... という記憶があったのでよさそう。
参考
https://qiita.com/jnchito/items/a4a51852c2c678b57868
RSpecで普段は実行しないテストをスキップする
describe Hoge do it "heavy test", type: :model, very_heavy_tests: true do # スキップ用のオプションはRails5で追加された type オプションの後に書きます hoge.should eq(fuga) end end describe Hoge do it "normal test", type: :model do # 書いてない場合は very_heavy_tests: false 扱いでこのテストは普段から実行される hoge.should eq(fuga) end end
RSpec.configure do |c| c.filter_run_excluding :very_heavy_tests => true end
参考
https://qiita.com/semind/items/cffd5c9e7ef9a108c871
現場からは以上です。