FirebaseとSendGridで作るメールマガサービスの検証

FirebaseとSendGridで作るメールマガサービスの検証

前回は、バグの話を紹介しました。 ソフトウエアの開発にバグはつきものですが、バグが起きる原因について簡単に紹介しました。

バグの分類は大きく分けて２種類で

＊　必要な機能が設計通りに動かないバグ

＊　想定外の条件が引き起こすバグ

です。設計通りに動作するかどうかの検証は設計者でも比較的簡単に検証できます。しかし、想定外の条件が引き起こすバグは、設計者が想定していないケースのため、設計者自身では検証が難しい部分という話を紹介しました。想定外のケースのテストをするためには、設計者以外の第三者にテストしてもらうというのが会社など組織で開発する場合の検証方針です。

フリーランスの場合は、設計から検証まで自分で行わなければならないことが多く、いかに想定外のケースを取り除けるかが重要になります。

効率的な検証のコツ

実際に、一人で全ての検証を完全に行うのはほぼ不可能に近いというのがある程度以上の規模のソフトウエアでは現時点での実情です。

しかし、効率的に検証を行う方法や、少しでも想定外を減らす方法はいくつかあります。この記事ではまず、効率的に検証を行う方法を解説します。

検証の範囲を絞る！

最初に考えることは、検証の範囲を絞ることです。

今回紹介している、FirebaseとSendGridを利用してメルマガ（ニュースレーター）の配信を行うサービスを例に考えて行きます。

実装の所でも既に紹介していますが、このサービスを作るには大きく３つの部分が必要になります。

一つは「バックエンド」です。これは、フロントエンドからのリクエストに応じて、SendGridととのやり取りを行う部分です。

もう一つはフロントエンドですが、この部分は２つに分けて考えると検証がやりやすくなります。一つは、ユーザーから見える部分「ユーザーインターフェース（UI）」です。もう一つが、ユーザインターフェースとバックエンドの間に入って、フロントエンドのデータ処理やバックエンドとのやり取りをやる部分になります。

＊　バックエンド（SendGridととのやり取り）

＊　フロントエンドのデータ処理（データ処理とバックエンドのインターフェース）

＊　ユーザーインターフェース

この３つです。サービス、アプリという観点ではこの３つが揃わないと機能しないわけですが、いきなりこの３つをまとめてテストすると、検証は難しくなる場合が殆どです。

まずは、別々にテストを行うことを考えます。

フロントエンドを、ユーザーインターフェースの部分と、データ処理やバックエンドの処理を一緒に実装してしまうこともできますが、ユーザーインターフェースとデータ処理部分は境界をはっきりさせて別々に実装した方がテストもやりやすくなりますし、将来の保守も簡単になります。

メッセージの送付先の登録の処理を考える

一つの例としてメッセージの送付先の登録、つまりメルマガを受け取る登録をする処理を考えます。

SendGridのレガシーマーケティングキャンペーン（Legacy Marketing Campaign）で送付先（recipient/contact）をSendGridに登録する処理です。

登録に必要な情報は基本的に３種類です

＊　E-Mailアドレス（必須）

＊　苗字（無くても可能）

＊　名前（無くても可能）

これらを入力してもらって、入力した情報をバックエンドに送るという処理です。

バックエンドではフロントエンドから受け取った情報を、SendGridに転送するような処理を行います。SendGridからの応答を見て処理が成功したかどうかを確認して結果をフロントエンドに応答して送るという処理の流れになります。

これだけならば、フロントエンドでデータを送って、その応答をチェックする事とSendGridのサーバー登録したE-Mailが追加されているかを確認するだけで一応検証はできます。

しかし、不具合があった場合には何処が問題なのかを切り分けるのは少し面倒です。

そこでテストを３つの部分に分けて、それぞれの部分が正常に動作するかを確認する方が問題があった場合の対策も簡単にできるので結果的に効率的にテストできることになります。

ユーザーインターフェースの確認

ユーザーインターフェースの確認は、以下の機能を確認します。

＊　入力情報（E-Mail、苗字、名前）

＊　送信処理

＊　受信側での確認

送信前に送信内容をチェックする場合は、チェックでエラーになるケースと、チェックでエラーにならないケースのテストを行います。

ユーザーインターフェースのテストの場合、実際にユーザーインターフェースを操作してテストする必要があります。受信側は仮の受け取り用のプログラムをテスト用に書いて、送った情報が受信されるかを確認します。

データ処理の確認

データ処理は、ユーザーインターフェースから受け取ったデータをバックエンドに送信できるかどうかの確認と、バックエンドからの応答に対するしょりの確認をします。

基本的にユーザーインターフェースで入力データのチェックを行っている場合は、予期しないデータは基本的には送られてこないはずですが、万が一予期しないデータが来ても良いように、冗長になりますが、データをチェックする処理を入れておいた方が、想定外を最小限にする事ができます。

＊　確認は送られてきたデータが想定通りかを確認

＊　バックエンドで受け取るデータも想定通りかを確認

テストのためには、ユーザーインターフェースの代わりに決まったデータパターン（想定外も含めたデータの組み合わせを含めた入力データの送信）を送る部分と、バックエンドにデータを受け取る部分、さらに、実際の処理とは違って、SendGridにデータは送らずに、SendGridの応答パターンによるフロントエンドへの返送のパターン全てを返すことができるテスト用のバックエンドモジュールを使ってテストします。

この応答を受けて、どのようにな処理を行うかを確認します。

バックエンドの確認

フロントエンドからデータを受け取ってSendGridとやり取りをする部分を確認します。

これも、フロントエンドで送るデータをチェックする場合は想定外のデータは送られてこないはずですが、一応バックエンドでもチェックするようにして、想定外のデータを受け取った場合の処理を確認します。この場合、SendGridのWebサイトのＵＩを利用して、実際に正しくSendGridのデータに反映されたかをチェックします。

想定外と言っても、送られてくるデータは、「E-Mail」、「苗字」、「名前」の３種類だけなので全ての可能性を考えても組み合わせはそれほど多くはありません。

正常なケースは

E-Mail 苗字 名前

有り 　無し 無し

有り 　無し 有り

有り 　有り 無し

有り 　有り 有り

の４種類だけです。

エラーになるケースは

＊　E-Mailがない場合

＊　苗字、名前が文字列ではない場合（数字など）

＊　E-Mailの書式がエラーの場合（例えば「＠」がない場合など）

幾つか組み合わせがあります。 苗字、名前が文字列以外の場合は、数字の場合、論理型（boolean）の場合、配列の場合、undefinedの場合、nullの場合が想定されるケースと考えられます。 （私が考える限りこれでよいかと思っています！抜けていたらお知らせください！）

あとは、SendGrid側の反応です、正常終了の場合は余り問題ではないですが、エラーになる場合の応答のパターンがいくつあるかを仕様や実験から調べてテストする必要があります。

この場合もテスト用のフロントエンドのモジュールが必要で、データの送信と応答データの確認の機能が必要です。

####　個別にテストした後に統合する

個別に詳細のテストをしている場合、想定外のデータは統合テストでは発生するケースは少なくなるので検証は個別のテストよりは組み合わせが少なくなります。基本的に「データ処理」と「バックエンド」は中間にあたるので、ＵＩの部分だけでテストをすれば不具合が発生しない限りは、十分問うことになります。

実際の機能は盛沢山

単にメルマガ（ニュースレター）をSendGridを通じて配信するには単にメッセージを送る以外にもたくさんの機能が必要です。

データの分類だけでも

＊　メッセージの配布先

＊　メッセージの配布先のリスト（グループ）

＊　登録送信者

＊　マーケティングメッセージ（キャンペーン）

は最低限必要です。その他の分類には、「セグメント」、「送信停止リスト」、「カスタムフィールド」なども機能の拡張時には必要になります。

それぞれに対して、新規作成、削除、一覧の取得、場合によってはデータの更新の処理が必要になります。

このような場合、いきなり、全てのモジュールを統合してテストをしても、テストの効率は悪くデバッグも大変です。できるだけ機能を細かく分けて必要に応じてさらにテストの範囲を細分化したうえで個別の機能をテストしながら統合するのが効率的なテスト方法です。

まとめ

FirebaseとSendGridを利用して、メルマガ（ニュースレター）のサービスを実装することは実はそれほど難しくありません。一番大変なのは、実装した機能が設計道理に動作するかなど、作ったものを検証する方が、実装より時間がかかる場合がほとんどです。

多くの場合、実装にばかり目が行きがちですが、実はきちんとした実装で品質の高いものを提供するにはテストの方が重要です。発注元との信頼の構築には制作物の品質はとても大きなカギを握っています。作るだけではなく、テストにも手を向けてより品質の高いプログラムを作ることで将来のビジネスチャンスは大きく変わります。

実際にサービスやアプリを作る際にはテストも十分に考慮した設計が大切です。