「こんにちは」って書いたつもりだったけど普通に違ってた。
こんちには pic.twitter.com/IcmT2F85Qg
— うたがわきき (@utgwkk) 2024年4月7日
■
カワイイが過ぎるため、脳を焼かれています。
韓国語版のほうを見ると韓国語の字幕が整備されているので、韓国語学習の観点からは両方見るのがよさそう。
Go Conference 2024でgomockの話をします #GoCon
Well done! Your session Dive into gomock has been accepted for Go Conference 2024!
ということなので、よろしくお願いします。「Dive into gomock」というタイトルで、gomockの内部実装に深入りする話をします。
6/8に渋谷で会いましょう。今日の12時から参加登録が始まるので全員来てください。
🔥 GoConference 2024 📆2024/4/5 12:00〜先着順で参加募集を開始します！ #GoCon #golangjphttps://t.co/bsb8FK0MsC
— Go Conference (@goconjp) 2024年4月5日
トークの説明
みなさまは、interfaceに依存するコンポーネントのテストを書いていますか？ また、テストで使うinterfaceの実装はどうやって用意していますか？ interfaceにメソッドが追加されたらどうしますか？ 意図したメソッドが呼び出されていなかったら？ メソッドに渡される引数の比較方法を柔軟にしたくなったら？
interfaceのモックを用いたテストを簡単に記述するためのフレームワークの1つに、gomockがあります。
gomockを使ったモック実装を使ってテストすることで、interfaceのメソッド呼び出しが適切に行われていることを検査し、意図しないメソッド呼び出しがあればテストを失敗させることができます。
また、gomockを使ったモック実装を生成するためのツールとしてmockgenが用意されています。mockgenを使うことで、interfaceの定義が変わってもgo generateコマンドで簡単にモック実装を修正することができます。
本セッションでは、gomockがどのようにinterfaceのメソッド呼び出しを検査しているのか解説します。
主に以下のトピックについて取り上げる予定です。
- mockgenが生成するコードの内容
- 期待するメソッド呼び出しを記述し、記録する
- 期待するメソッド呼び出しがなければテストを失敗させる
- 引数の比較方法をカスタマイズする
このセッションが、Goのinterfaceモックを用いたテストの仕組みへの理解を深める一助となれば幸いです。
選択しなかった技術判断に気を払う
技術選択の場面において、ある技術を選ぶということは選ばれなかった技術があるということである。なぜその選択にしたのか、に目が向きがちだけど、選ばなかった技術についても述べるべきだろう。
今回の企画・要件に対して、この技術はこういう制約が見合わないので採用を見送った、ということを書き残すことで、技術判断の根拠になる。技術選択はその場限りの出来事ではなく積み重ねなのだから、あとから振り返り可能な形になっているべき。逆に、選ばなかった技術がフィットする要件もあるだろう。そういう技術を選ぶ機会を逃さないように注意するべきだろう。
ということを考えたんだけど、だいたいDesign It! に書いてあった。つまり、Design It! を読んだらいいと思います。
ところで、アーキテクチャ俳句ってぜんぜん俳句じゃなくない？？
株式会社はてなに入社しました
株式会社はてなに入社しました
🌸🍜
京都御苑に桜を見にいく。休日の昼だしシーズンだしでまあまあ人が多かった。
これぐらい暖かいと徒歩圏内が広がる。西陣麦酒まで歩いていった。一条戻橋は単に橋なんだけど堀川と組み合わせると魅力が出てくる。
ラーメンを食べて18時ぐらいに帰宅し、眠気に身を任せたのであった……。
ログ
ログ*1、油断すると絶妙に情報量が足りなかったり、欲しいものがdebugレベルでしか出ていなくて本番環境で見れなかったりしがち。ここでこういうログが欲しくなるだろう、という感覚を鍛えるには、実際にログが足りなくて困る経験をするしかないのか、もうちょっと高速道路が整備されているものなのか。
外部APIにリクエストを送る部分はとりあえずリクエスト・レスポンスの内容を (ユーザー個人情報などには気をつけながら) ログ出力しておくと調査に役に立つ、というのはありそう。GoのgRPCクライアントのミドルウェアにはまさにそういうのがあるし、HTTPクライアントにログ出力の仕組みを差し込むのもすぐできる。自分のシステムに閉じていない部分はこういう仕組みが整っていそう。
ほかにはアプリケーションごとに固有の事情に合わせることにもなるだろう。何が重要で、調査をしたくなるか、そしてアプリケーションログではなくもっと永続的なデータとして残したくなるか？ ログとログデータの区別はどこに生じるのか？
公園でフラフラしてるお姉さんになったら「もっとログを吐きなよ、debugレベルじゃなくてinfoレベルでさ。少年？」って言う
— うたがわきき (@utgwkk) 2024年3月26日
*1:ここではWebアプリケーションやサブシステムなどのアプリケーションから出力するログを指す
