Open2

unit test

ゆーとゆーと

unit testありきでの関数の実装時の考慮点メモ

  • 単一責任原則

    • テストやデバッグ、再利用がしやすい。
    • 粒度が適切でないと冗長になったりコード量が増える。

  • 戻り値をboolにするかvoidとするか

  • try~catchを適切に使えてるか

    • 乱用した方が安全そうに見えるが、なんでもかんでもtryで囲むと可読性悪いし不要な場合も。
    • 非同期処理やDB接続部などにtry~catchを使用
    • 内部処理部分では基本的には不要。外部要因による失敗は発生しにくいものとして。

      • try-catchは以下のようなケースで使用すると良いです。
        基本的には、プログラムが進行する上で不確定性がある、または失敗する可能性がある場面でtry-catchを使用します。しかし、try-catchは使いすぎるとコードが読みにくくなるので、必要な箇所でのみ使用することが推奨されます。

        • 外部リソースへのアクセス: ネットワークリクエスト、ファイル読み書きなど
        • 不確定要素: ユーザー入力、ランダムな値に依存する処理
        • サードパーティライブラリ: 信頼性が不明瞭な場合
        • 依存APIの変更: API仕様が変わる可能性がある場合
        • 非同期処理: async-awaitパターンでエラーを適切にハンドリング
        • リソースの解放: 必ずクローズや解放が必要なリソース

  • context依存

    • どうしてもな場合を除いて、引数にcontextは使用したくない。テストがしづらい。

  • 戻り値の変数を使用するかどうか

    • 直接関数を条件式として使用するとコード量は減るが、可読性が下がる場合も。一箇所でしか使用しないならありかもしれない。関数名が適切で一目見て判断できる内容であるなら。
    • resultのような変数で値を保持してからの方がデバッグはしやすい。変数名が適切なら一目で何の変数かがわかるので。コード量はやや増えるし助長になりがち。

    • BuildContextを引数として渡すのは避けたい、という意見が一部にあります。理由は主に以下の通りです：
      コードの可読性と保守性:
      BuildContextを頻繁に渡すことは、コードの可読性と保守性を低下させる可能性があります。特に大規模なプロジェクトや複数の開発者が関与する場合、コードの流れが複雑になり、デバッグが困難になることがあります。
      過剰な依存関係:
      BuildContextを引数として渡すことで、依存関係が増加し、関数やウィジェットがコンテキストに過剰に依存することになります。これにより、再利用やテストが困難になる可能性があります。
      誤用の可能性:
      BuildContextの誤用は、アプリケーションのバグや不具合を引き起こす可能性があります。特にBuildContextのスコープを理解していない場合、意図しない動作やエラーが発生する可能性があります。
      設計の原則違反:
      BuildContextを引数として渡すことは、設計の原則やパターンに従わないことがあります。例えば、依存関係注入やサービスロケータパターンを使用して、必要な依存関係を提供することが推奨されています。
      これらの理由から、一部の開発者はBuildContextを直接引数として渡すのを避け、代わりに他の方法を探求することがあります。しかし、BuildContextを引数として渡すことが必ずしも悪いわけではなく、適切に使用される場合には有用です。また、Flutterの文脈においては、BuildContextを引数として渡すことは十分に一般的であり、避ける必要はない場合もあります。

  • 外部依存性

    • Mockを使用してのテストができるか。インスタンスを引数に渡すとか。
    • できるだけ純粋なDartだけの関数とできるのが理想ではあるが