本棚登録 : 
感想 : 
- Amazon.co.jp ・電子書籍
感想・レビュー・書評
-
単体テストそのものというよりは、単体テストや結合テストから見てのプロダクションコードと合わせてどのようにしていくのか、という本に感じた。
単体テストのテクニックとかの本ではないないです。
自動テストやコードの記述はこうすると良いのかな？という手応えと、アーキテクチャの知識不足での理解不足など、理解できるとわかりやすいコードが書けそうだが理解しきれなかったところがある。
掴めそうなことみたいなことは非常に価値がある感じはしている。アーキテクチャ周りの知識をつけて再度読みたい。
0
詳細をみるコメント0件をすべて表示 -
ありそうでなかった単体テストにフォーカスした素晴らしい書籍。言語は何であれ、これを読んでソフトウェア開発に臨むことはMUSTだと思う。
0
-
題名の通り、単体テスト(UT)の使い方・考え方についての内容がよくまとまっており、勉強になった。
本内容を意識して、UTのテクニックやTDD(テスト駆動開発)に関する関連書籍を読んで更に理解を深めたい。
【前提】
・UTがどのように活かしていくかに焦点を当てた一冊、UTのテクニック集とは異なる。
・UTに取り組み始めた初級者、TDDを取り入れた中級者向けかと思う。
・TDDには古典派(デトロイト学派)とロンドン学派がいるが、著者は古典派である。
【ポイント】
・UTはプロジェクトを持続可能とするためのもの
・UTのしやすさ=コードの質の高さではない。しにくさ=質の低さのみが検出できる
・テストコードも含め、コードは負債。最小限にすべき
・網羅率の結果にとらわれず、UTが開発サイクルに含まれ、ドメインモデルがテスト対象となっていること
・良いUTは、退行への保護、リファクタリングへの耐性、迅速なフィードバック、保守のしやすさを持つ
・ドメインモデルへのUTが最も費用対効果が高い。コントローラはUTではなく統合テストでテストされるべき
・過度に複雑なコードをコントローラとビジネスロジックに分離し、テストを行いやすくすることが良い
・UTでは異常ケースを可能な限り扱う。統合テストでは1件の最長な正常パス(ハッピーパス)と、UTで扱えなかった異常ケースを扱う
・UTのためにと、プライベートメソッドを公開してはならない。また、プロダクションコードへの記述(汚染)もしてはならない
0
-
単体テストのテクニカルな書き方はわかるけど、実際に単体テストをプロジェクトで運用していく中で課題を感じている人に向けた本。
とても良い本。
0
-
悪くはないのだが、ちょっと癖が強く、ある程度の経験があって良し悪しの区別がつく人、言語による特性を理解できている人にしか進めにくい。
0
-
単体テストの考え方や実装方法についてフォーカスした本。
単体テストと統合テストの違いや、モックの使いどころがイマイチ理解できていなかったので非常に参考になった。
サンプルコードがC#なのも個人的によかった。
わかりにくい箇所もあるが、テストコードを実装するなら読んでおいて損はない。
0
-
これは結構気に入った。
ちょうどチーム内で、何が単体テストか、何が統合テストか、いつモックを使うべきか、どうテストを書くべきか、と行った話で盛り上がっていたのでとてもタイムリーだった。
面白かったのは、考え方の分かれ目として、なにを「ユニット」とみなしているのかという話。
ここですれ違うと、そこから共連れで、なにが統合テストなのかがずれてくる。
どちらが圧倒的に正解というわけではないと思っているけど、文脈に合わせてユニットの定義をしてテストを進めないといけないと思った。
それこそ、金融や自動車などの一定の領域で、規則上、コードカバレッジ xx%という指標をおいている場合、この書籍内におけるロンドン学派的な発想に基づいた考え方だよなあ、なんてことにも思いを馳せた。
テストを書くことは、コードを書くことと同じように、結局のところ、メンテナンスが大変（工数等含めたコストが必要）だよね、という話で、あればあるほど良いもの、ではないという点がチームなどで共通認識を持ちやすい本。
普段自分がテストを書くときに意識的にやっていたけれどその説明をうまくできないこと、が書籍内で書き表されていて、納得感を引き出しやすくなった点にも、この書籍には感謝している。
0
