ユニットテストのガイドラインを作成しました | メルカリエンジニアリング
この記事は Merpay Tech Openness Month 2022 の15日目の記事です。 はじめに こんにちは。Credit Design Teamでバックエンドエンジニアをしている@tanaka0325です。主にメルペイスマート払いの開発をしています。 この記事では、先日私のチームで作成したユニットテストのガイドラインについて紹介します。 課題 現在私が担当している「メルペイスマート払い」のマイクロサービスは、もともと「メルカリ月イチ払い」として提供されていたコードを流用し、新規要件となる機能を追加して作られたマイクロサービスです。 マイクロサービス化するにあたり、「メルカリ月イチ払い」にあったデータはマイクロサービスリリース後に随時マイグレーションをする方針になったので、既存のデータをマイグレーションしつつ、定額払いなどの新規機能を追加してきました。メルペイスマート払いのマイ
名前に関するガイドライン
フレームワークの開発で一貫性のある一連の命名規則に従うことは、フレームワークの使いやすさに大きく貢献することになります。 広範囲のプロジェクトで多くの開発者にフレームワークを使用してもらうことができます。 フォームの一貫性以外に、フレームワーク要素の名前は簡単に理解できて、各要素の機能を伝えるものにしなければなりません。 この章の目標は、開発者がすぐに理解できる名前が付けられるよう、一貫性のある一連の命名規則を提供することです。 コード開発の一般的ガイドラインとしてこれらの命名規則を採用することで、コード全体で名前付けの一貫性が向上することになります。 ただし、それは一般公開される API にのみ適用することが求められます (public または protected の型とメンバー、明示的に実装されるインターフェイス)。 このセクションの内容 大文字の使用規則 一般的な名前付け規則 アセン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
