ユニットテストのガイドラインを作成しました | メルカリエンジニアリング

この記事は Merpay Tech Openness Month 2022 の15日目の記事です。 はじめに こんにちは。Credit Design Teamでバックエンドエンジニアをしている@tanaka0325です。主にメルペイスマート払いの開発をしています。 この記事では、先日私のチームで作成したユニットテストのガイドラインについて紹介します。 課題 現在私が担当している「メルペイスマート払い」のマイクロサービスは、もともと「メルカリ月イチ払い」として提供されていたコードを流用し、新規要件となる機能を追加して作られたマイクロサービスです。 マイクロサービス化するにあたり、「メルカリ月イチ払い」にあったデータはマイクロサービスリリース後に随時マイグレーションをする方針になったので、既存のデータをマイグレーションしつつ、定額払いなどの新規機能を追加してきました。メルペイスマート払いのマイ

[moromoro]

1ロジックだけ見て重複と不要と思ってるの削除してバグ起こってない？単体は全網羅（異常データ含む）でやって欲しいね。ところで無言ブクマ多くね？

[inabajunmr]

全体で守るべきガイドラインという意味ではこれくらいが丁度いいと思う 逆にこの辺が自由だとしょうもないところでめんどくさくなる（コードに対応するテストどれだかわからん、みたいな）

[xlc]

テストをなんとなく「かっこいいこと」と思ってる人が多いことがわかる無言ブクマ数。英語系エントリと同じ状況。このエントリ自体は別に大したことは語っておらず、ガイドラインというほどのものでもない。

[nomanssky00]

そのわりにメルカリアプリはバグが多い印象だけど。。

[wonderword22]

“1つのテスト関数内で条件分岐による複数条件のテストをしない” メルカリでもこんなテストコード書く人いるんだ。。ガイドラインは可もなく不可もなく。カバレッジについてはどう考えてるんだろうと気になった。

[rikuba]

“Test{*テスト対象*}_{条件}_{*想定結果*}”

[yamadashy]

テスト関数名のルールは決めておいたほうが確かに責務もわかりやすくなって良いかも。カバレッジ取ってればあまり気にしなくても良さそうだけど。

[nakag0711]

マイクロサービスの非公開関数テストしなかったらそれは単体というより結合テストだな…まあ厳密に分ける意味はあまりないかもだが公開関数だけでは荒すぎるだろな。単体はコード見直しの機会を作るという意味もある

[ardarim]

「条件別にテスト関数を分けて、個々のテスト関数内での条件分岐を減らす」理解はしやすいけど網羅度が下がるのでは… / 「一般的にテストは公開関数を通じてのみ行われるのが良いと言われています」そうなの？

[tyakoske]

"技術"はあるけど"倫理"が無いことで有名なメルカリさん

[tettekete37564]

本当にエンジニアサイドは優秀なんだよなぁ。そこは羨ましい

[saiyu99sp]

寝た子は起こすなでテスト書いてるから、結局バグりやすい部分はテストがない状態になりそう。

[aox]

ユニットバスの親戚でしょうか

[tpircs]

作成した、か。公開してくれたのかとちょっと期待してしまった。全部見てみたいなぁ。

[baronhorse]

なんかSIer感

[pascal256]

後で読む