決済系システムにおけるテストの利便性と重要性

はじめまして。ピクスタエンジニアのたきです。私は昨年の８月にピクスタに入社しました。入社して半年、Ruby on Railsについて学びながら、定額制で多通貨決済ができるようにしたり、タイ語サイトの開発などを行ってきました。 f:id:yuyasat:20160427173531p:plain 図1 PIXTAのタイ語サイトのトップページ

背景

ピクスタには、ほしい分だけ、1点1点購入できる単品購入と、一ヶ月や一年といった単位で1日一定数までダウンロードできる定額制プランがあります。これまで、単品購入では、ピクスタが請求書を作成していましたが、定額制では、外部の決済代行サービスを利用していました。そのサービスは複雑な請求書発行を代行してくれる非常に便利なサービスですが、支払い期限が少し短かったり、手数料がかかってしまうといったデメリットも存在し、社内からは定額制でもピクスタが請求書を発行したいという要望がありました。

しかし、単品購入と定額制では、それぞれ異なるマイクロサービスで動いています。したがって、各マイクロサービス間を連携するAPIの作成や定額制の情報を請求書の処理に追加する必要があるなど、容易ではなく、私が今までピクスタで行った開発の中でも仕様把握からリリースまで三ヶ月以上かかるという長いプロジェクトになりました。

開発の流れ

苦労した点としては、ピクスタにおける請求書の知識がゼロだったので、まずはその仕様を把握することでした。

請求書が作成され、残高の消し込みが行われるまでの大雑把なフローとしては以下のようになります。

請求書支払いを希望するユーザーが法人ユーザーへの変更申請をする
法人ユーザーが請求書支払いができるよう申請する
請求書支払いの審査が通ると請求書支払いができるようになる
請求書支払いで単品購入や定額制ライセンスが購入されると、"発生"として残高に反映される
毎月締め日になると対象となる単品購入や定額制ライセンスのあるユーザーには請求書が作成され、ユーザーは、請求書を閲覧することができる
入金があると、管理画面から消し込みを行い、残高を減少させる

請求書には20日締めと末締めがあり、毎月1日と21日の深夜に請求書作成バッチがまわります。これに定額制の請求書も取り込むようにしなければいけません。また、銀行に振込みが行われると振込み情報が記載されたCSVを元に自動で消し込みができる仕組みがあり、こちらのシステムの改修も行わなければなりません。請求書が発行される前から、請求書が発行され、支払いが行われて確認するまでの一連の流れを正しく把握し、実装しなければなりませんでした。

幸いなことに、単品購入の時にシステムをつくった星(id:　watasihasitujidesu)がいたので、星に処理概要を教えてもらいながら、実装を進めました。当初、請求書統合を実現するためにいくつかのデータの持たせ方を考えていたのですが、既存の処理を踏襲するかたちで、実装することにした結果、プロダクションコードの大きな修正はほとんどなく、

-some_method(sales)
+some_method(sales, subscriptions)

のような形で定額制の分だけ引数に加えて処理をするといったような変更が多くなりました。

テストコードの重要性

しかし、このような修正でも既存の仕様は変更されないということは担保されなければいけません。そこで助かったのが、テストです。ピクスタのテストはRSpecで書かれており、テストケースは２万を超えますが、請求書の作成、消し込みのテストもちゃんと存在します。このテストがあることで、既存の仕様が変更されないということが担保できます。また、テストコードを読むことで処理の理解も早くなります。

プロダクションコードとにらめっこしてアルゴリズムを把握しなくても、テストに書かれているパターンとその結果を把握できれば、定額制の請求書が加わった時にどうあるべきかというのも自ずと出てきます。まずは定額制の請求書分を加えたテストを書き、今の処理では当然ながらテストはパスしないことを確認。プロダクションコードに定額制の請求書の処理を加えたのち、テストがパスすることを確認します。当然その他のテストも落ちていないこと（＝処理が変わってしまっていないこと）も確認して実装完了です。

ピクスタには実際にユーザーが使う機能、ピクスタ内部で使う機能を含め多彩な機能があります。エンジニアもすべてを把握できているわけではないので、サポートの方や管理部の方にも教わりながら、実装しテストを書いていきました。リリース１週間前になって、この機能が実装されてない！などといったちょっとしたドタバタもありましたが、３月２９日に無事リリースすることができました。

まとめ

請求書統合は仕様把握からリリースまで約三ヶ月かかるプロジェクトでしたが、Ruby on Rails暦半年のひよっこでも、なんとかリリースまでこぎつけることができました。また、私は今回のプロジェクトでは、テストにとても助けられましたが、テストを書くことの利点として

プロダクションコードだけでなくテストコードを読むことで仕様を把握することができる
仕様の変更、追加などでプロダクションコードを修正、追加した時にテストがあることで修正が意図したものかを把握できるので、今後そのシステムが自分の手から離れた場合でもシステム修正が容易になる
バッチなどで大量のデータが書き換わってしまうような処理の場合、プロダクションコードを修正してデータを確認して、もう一度テストしたい場合はデータを元に戻してという作業が必要になるが、そのあたりの作業をコマンド一つでやってくれるので楽で早い。

といったことが挙げられると思いました。今後も、テスト駆動開発で堅牢なシステムを作っていきたいと思います。

ピクスタでは、要件定義から実装、テストまで一貫して携わりたいエンジニアを募集しています。ぜひご応募してください！ recruit.pixta.co.jp