たった２つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita

はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話： この記事の本旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは？リファクタリング耐性低くない？みたいな話は度外視してます。

[turanukimaru]

・何をテストしたいのか明確にしろ。・テストしたいところだけをメソッドに切り出してそこをテストしろ。・Mock捨てろ。この記事のようにやると9割がたMockが返したダミーデータをチェックするようなゴミテストになるぞ

[tattyu]

仕事ではテストが無いプロジェクトでも自分の担当箇所はある程度こんな感じの手順でやってるけどこれ強要されると途端に面倒くせぇ〜ってなるの不思議やね。

[honma200]

自分が中間メソッドみたいに呼んでるやつか。依存関係は直で呼ぶんじゃなくて、1行だけでも良いから間を挟むみたいな / 本当は実装の最初にMockを作った方がいいんだろうけどね

[cpw]

よくやってる。全部やるならinjectしたほうがいいし、必要なところだけやったら良いと思う。

[masa8aurum]

・主にレガシーコードで単体テストを書く際のハードルになりがちな「依存関係の排除」について

[syu-m-5151]

気を整え、祈り拝み、構えて、突くみたいな話かと思ったらちゃんとした話だった。意識していきたい。

[poad1010]

この記事をおすすめしました

[diveintounlimit]

こういうロンドン学派系のテストはやめとけって単体テストの考え方/使い方に書いてあった。理由は周辺で起きる問題も含めてキャッチアップすべきだから。くせあるけど、基本的にこの本の考え方には賛同している。

[hdampty7]

単体テストが書けたところでねぇ。全パターンの組み合わせは捨てて、実データをもとにしてOKとか、やらんよりはマシを徹底できるかどうかよね。やっても出るし、その時のモチベコントロールも重要。

[mas-higa]

レガシーコードってテスト書いてないコードのことじゃないの? まずハーネス書く必要があると思ったんだけど。

[zentarou]

結局ちゃんと依存注入できてるか確認したくなってE2Eテスト重視になるんだけどね

[hive7134]

テストのためにスコープ広めのファンクションを追加するのは抵抗がある気がしたけど既存のコードを活かしつつやるやら仕方ないのかな？

[kabuquery]

結局モックみたいなの作ってない？