woshidan's blog

そんなことよりコードにダイブ。

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のコンテナインスタンス

タスク定義

  • クラスタが所定の台数Dockerの動くEC2のインスタンスを確保してくれているはずなので、そこにdocker-composeで投げるdocker-compose設定ファイル的なもの*6
  • docker-composeの内容を書く = その内容は docker-compose 投げた 先のEC2インスタンスがどういう性能を持っていないといけないか知っている
    • タスク配置の制約事項*7 => データベースのコンテナは複数availavility zoneに配置されるようにしてくれませんか? このタスクはちょっとした雑用だけなので安いEC2インスタンスタイプ使ってくれませんか?
    • タスクサイズ*8 => 画像変換処理のタスクはCPU食うのでたくさんCPU持ってるEC2インスタンスで実行するようにしてくれませんか?
    • サービスを利用してタスクの実行スケジュールを管理することで、並行していくつ稼働するのか、といった管理も可能*9

ECSタスクのスケジューリング *10

  • 長期実行するステートレスサービスおよびアプリケーション用(要するに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:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html#constraints (インスタンスタイプの指定はdockerで元になるOSが入ったimageを指定イメージに近い)

*8:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html#task_size

*9:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs_services.html

*10: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の資料によると証明書の発行プロセスは大別して

  1. 加入者(証明書が発行される側。APNs - プロバイダ間でいうとプロバイダ、アプリ開発者のほう)が鍵ペアを生成する方式
  2. 登録局が一括して鍵ペアを生成する方式

の2通りあります。

この記事などの手順にあるように、APNsから証明書発行してもらうプロセスはプロバイダ側がキーペアを含めたCSRを作成するところから始まるので1の方ですね。

まず、1. の手順に「加入者が鍵ペアを生成する」について。APNsの証明書を作成する場合は、「キーチェーンアクセス > 認証局に証明書を要求...」から .certSigningRequest ファイルを作成します。

作成した .certSigningRequest ファイルをApple開発者アカウントの管理画面からAPNsのシステムへアップロードすることが、KPIでいう加入者の認証局に対する証明書の発行申請にあたり、アップロード後にダウンロードした .cer ファイルが Apple側の署名がなされた証明書となっています。

ところで、「加入者が鍵ペアを生成する」の文言と 「「キーチェーンアクセス > 認証局に証明書を要求...」から .certSigningRequest ファイルを作成」 の内容があってないですね。

実は「キーチェーンアクセス > 認証局に証明書を要求...」をクリックしたときの画面をみてみると

f:id:woshidan:20180620203346p:plain

のようになっており、 .certSigningRequest ファイルを作成する前に秘密鍵と公開鍵のキーペアを生成しているようです。

この秘密鍵はキーペアを生成したMac(システム)に配置され、キーチェーンからのみアクセスできるようで、他のMacに移行したりプッシュ系のmBaasを利用する場合などはAppleから発行された証明書( .cer ファイル)に秘密鍵を含めて .p12 ファイルに書き出す必要があります*8

参考

*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/

*6:APNsの場合、RSAのキーペアを利用する

*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 ファイルから秘密鍵を取り出し、時刻を利用して認証に使うトークンを生成します
    • 生成したトークンをリモート通知リクエストのたびにリクエストのHTTPヘッダに添えることで接続信頼の確認をします
    • このトークンの有効期限は1時間で有効期限が切れるたびに再発行する必要があります*2
  • バンドルIDが記載されているすべてのアプリケーションにおいて同じ Apple Push Notification Authentication Key を使うことが可能です
    • その代わり、リクエストごとに必ず apns-topic ヘッダでどのアプリケーションに対するリモート通知リクエストか示す必要があります
    • APNsとのやりとり関連でどのアプリケーションへのどの種類のリクエストか示すためにアプリのbundle IDなどが利用されるのですが、そのリクエスト先を指定するための項目を トピック といいます*3
  • 余談として、ドキュメントの セキュリティアーキテクチャ > プロバイダ-APNs間の接続信頼 > トークンベースのプロバイダ接続信頼鍵ペアを生成し、公開鍵をAppleに渡してください。秘密鍵はプロバイダ側で保持し と書いてあるものの、公開鍵をどうこうした覚えはなくて若干戸惑っていたり。。
    • これは推測ですが、秘密鍵がそのときDLする .p8 ファイルに入っているので、多分公開鍵は Apple Push Notification Authentication Key を発行した時にAPNs側に保管されているのでしょう。。

トークンベースの接続信頼を利用する場合に送るリクエストの例

https://developer.apple.com/jp/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html#//apple_ref/doc/uid/TP40008194-CH11-SW1 より

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年の有効期限があります

証明書ベースの接続信頼を利用する場合に送るリクエストの例

https://developer.apple.com/jp/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html#//apple_ref/doc/uid/TP40008194-CH11-SW1 より

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 の指定が必要です。
  • バイストークンの指定は、 :path で行われています。

APNs-デバイス間の接続信頼

次にAPNs - デバイス間の接続信頼の話をします。

大枠を言うと

  • iOSなどのデバイスの利用開始設定(アクティベーション時)に接続信頼に利用される暗号化証明書と秘密鍵がOSから提供される
  • OSから提供された暗号化証明書と秘密鍵はキーチェーンに格納され、アプリケーションとは関係なしにAPNsとデバイスとの間の接続信頼に利用される
    • (= デバイスとAPNsとの接続信頼のために、開発者がなにかする必要はない)

となります。

そうすると自分(プロバイダ)として関心があることは、このAPNs - デバイスが接続された上で、デバイスへのリモート通知リクエストに必要なトークンを取得することですが、この部分については開発者側で実装や設定が必要です。

iOSおよびtvOSでのデバイストークンの取得などを参考にアプリケーションがリモート通知リクエストを送るためにAPNsへリクエストを送り、結果を受け取る実装をし、また、Enable push notificationsを参考にアプリケーションがプッシュ通知を利用する設定が必要です。

参考

*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には基本的にHadoopApache Sparkがインストールされています。

このEMRにインストールされているバージョンはソフトウェアのバージョンはEMRのリリースバージョンごとに管理されていて、EMRのリリースバージョンに対するHadoopApache 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

のページに目を通しておくと公式ドキュメントのググラビリティが非常に上がります。というか、先に読んでおくもののはずなんですが、ググり方がわからなかったので、メモ。

また、上記ページの各種証明書がApple Developer AccountのどのフォームからDLされるものか、について追加でまとめます。

Apple Worldwide Developer Relations Certification中間証明書

f:id:woshidan:20180525214850p:plain

ここのフォームからDLするだけだと拡張子が .cer なだけでどの種類の証明書かわかりにくいんですが、このファイルをDLした.cerを開いたとき、キーチェーンに追加されるのが

f:id:woshidan:20180525215129p:plain

となっています。

Apple Push Notification Service証明書

俗称・Push通知用の証明書、 .p12 に書き出すやつ

f:id:woshidan:20180525215457p:plain

Identifiers > App IDs > 特定のApp ID をクリックして下の方のEditボタンを押して出て来る

f:id:woshidan:20180525215612p:plain

のフォームで作成・再作成・DLするもの。

iOS配布用証明書(App Store)/ iOS配布用証明書(社内用アプリケーション)

英語版のページと

Certificates - Support - Apple Developer

Provisioning Profile の作成フォームを見比べて

f:id:woshidan:20180525220027p:plain

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

現場からは以上です。