みなさまは、interfaceに依存するコンポーネントのテストを書いていますか？また、テストで使うinterfaceの実装はどうやって用意していますか？ interfaceにメソッドが追加されたらどうしますか？意図したメソッドが呼び出されていなかったら？メソッドに渡される引数の比較方法を柔軟にしたくなったら？

interfaceのモックを用いたテストを簡単に記述するためのフレームワークの1つに、gomockがあります。
gomockを使ったモック実装を使ってテストすることで、interfaceのメソッド呼び出しが適切に行われていることを検査し、意図しないメソッド呼び出しがあればテストを失敗させることができます。
また、gomockを使ったモック実装を生成するためのツールとしてmockgenが用意されています。mockgenを使うことで、interfaceの定義が変わってもgo generateコマンドで簡単にモック実装を修正することができます。

本セッションでは、gomockがどのようにinterfaceのメソッド呼び出しを検査しているのか解説します。
主に以下のトピックについて取り上げる予定です。

mockgenが生成するコードの内容

期待するメソッド呼び出しを記述し、記録する

期待するメソッド呼び出しがなければテストを失敗させる

引数の比較方法をカスタマイズする

このセッションが、Goのinterfaceモックを用いたテストの仕組みへの理解を深める一助となれば幸いです。

2024-04-03

選択しなかった技術判断に気を払う

技術読書

技術選択の場面において、ある技術を選ぶということは選ばれなかった技術があるということである。なぜその選択にしたのか、に目が向きがちだけど、選ばなかった技術についても述べるべきだろう。

今回の企画・要件に対して、この技術はこういう制約が見合わないので採用を見送った、ということを書き残すことで、技術判断の根拠になる。技術選択はその場限りの出来事ではなく積み重ねなのだから、あとから振り返り可能な形になっているべき。逆に、選ばなかった技術がフィットする要件もあるだろう。そういう技術を選ぶ機会を逃さないように注意するべきだろう。

ということを考えたんだけど、だいたいDesign It! に書いてあった。つまり、Design It! を読んだらいいと思います。