単体テストの考え方/使い方 [単行本]

単体テストの考え方/使い方 [単行本] の 商品概要

• 要旨（「BOOK」データベースより）

  質の高いテストを行い、ソフトウェアに価値をもたらそう！プロジェクトの持続可能な成長を実現するための戦略について。単体テストの原則・実践とそのパターン。優れたテストを実践しソフトウェアの品質改善に役立てよう。

• 目次

  第１部　単体（unit）テストとは
  第1章 なぜ、単体（unit）テストを行うのか？
  1.1 単体テストの現状
  1.2 なぜ、単体テストを行うのか？
  1.3 網羅率（coverage）とテスト・スイートの質との関係
  1.4 何がテスト・スイートの質を良くするのか？
  1.5 本書から学べること
  
  第2章 単体テストとは何か？
  2.1 単体テストの定義
  2.2 古典学派およびロンドン学派が考える単体テスト
  2.3 単体テストにおける古典学派とロンドン学派の違い
  2.4 古典学派およびロンドン学派における統合（integration）テスト
  
  第3章 単体テストの構造的解析
  3.1 単体テストの構造
  3.2 単体テストのフレームワークについて
  3.3 テスト・ケース間で共有するテスト・フィクスチャ（test fixture）
  3.4 単体テストでの名前の付け方
  3.5 パラメータ化テストへのリファクタリング
  3.6 確認（Assert）フェーズの読みやすさの改善
  
  第2部　単体テストとその価値
  第4章 良い単体テストを構成する4本の柱
  4.1 良い単体テストを構成する4本の柱
  4.2 退行（regression）に対する保護とリファクタリングへの耐性との関係
  4.3 迅速なフィードバックと保守のしやすさ
  4.4 理想的なテストの探求
  4.5 ソフトウェア・テストにおけるよく知られた概念
  
  第5章 モックの利用とテストの壊れやすさ
  5.1 モックとスタブの違い
  5.2 観察可能な振る舞い（observable behavior）と実装の詳細（implementation detail）
  5.3 モックの利用とテストの壊れやすさとの関係
  5.4 振り返り: 単体テストの古典学派とロンドン学派の違い
  
  第6章 単体テストの3つの手法
  6.1 単体テストの3つの手法
  6.2 単体テストの3つの手法の比較
  6.3 関数型アーキテクチャについて
  6.4 関数型アーキテクチャおよび出力値ベース・テストへの移行
  6.5 関数型アーキテクチャの欠点
  
  第7章 単体テストの価値を高めるリファクタリング
  7.1 リファクタリングが必要なコードの識別
  7.2 単体テストに価値を持たせるためのリファクタリング
  7.3 プロダクション・コードの種類に基づく効果的な単体テストの作成
  7.4 コントローラにおける条件付きロジックの扱い
  7.5 結論
  
  第3部　統合（integration）テスト
  第8章 なぜ、統合（integration）テストを行うのか？
  8.1 統合（integration）テストとは？
  8.2 どのようなプロセス外依存をモックに置き換えるべきか？
  8.3 どのように統合（integration）テストを行うのか？
  8.4 インターフェイスを使った依存の抽象化
  8.5 統合テストのベスト・プラクティス
  8.6 ログ出力に対するテスト
  8.7 結論
  
  第9章 モックのベスト・プラクティス
  9.1 モックの価値を最大限に引き出す方法
  9.2 モックのベスト・プラクティス
  
  第10章 データベースに対するテスト
  10.1 データベースをテストするのに必要な事前準備
  10.2 データベース・トランザクションの管理
  10.3 テスト・データのライフ・サイクル
  10.4 テスト・コードの再利用
  10.5データベースを使ったテストに関するよくある疑問
  10.6 結論
  
  第4部　単体テストのアンチ・パターン
  第11章 単体テストのアンチ・パターン
  11.1 プライベートなメソッドに対する単体テスト
  11.2 プライベートな状態の公開
  11.3 テストへのドメイン知識の漏洩
  11.4 プロダクション・コードへの汚染
  11.5 具象クラスに対するテスト・ダブル
  11.6 単体テストにおける現在日時の扱い
  11.7 結論

• 出版社からのコメント

  質の高いテストを行い、ソフトウェアに価値をもたらそう！

• 内容紹介

  単体（unit）テストの原則・実践とそのパターン ― プロジェクトの持続可能な成長を実現するための戦略について解説。
  
  優れたテストを実践すれば、ソフトウェアの品質改善とプロジェクトの成長に役立ちます。逆に間違ったテストを行えば、コードを壊し、バグを増やし、時間とコストだけが増えていきます。生産性とソフトウェアの品質を高めるため、優れた"単体テスト"の方法を学ぶことは、多くの開発者とソフトウェア・プロジェクトのために必須といえるでしょう。
  
  本書“単体テストの考え方/使い方”では、単体テストと統合テストの定義を明確にします。そして、どのようなテストに価値があるのかを学び、どのテストをリファクタリング、もしくは削除するのか、ということについて考え、そのことがプロジェクトの成長にどう繋がるのかを見ていきます。
  C#のコード例で解説しますが、どの言語にも適用できる内容です。
  
  Manning Publishing: Unit Testing Principles, Practices, and Patterns の翻訳書。
  
  
  目次
  第1部: 単体（unit）テストとは？
  第1章: なぜ、単体テストを行うのか？
  第2章: 単体テストとは何か？
  第3章: 単体テストの構造的解析
  
  第2部: 単体テストとその価値
  第4章: 良い単体テストを構成する4本の柱
  第5章: モックの利用とテストの壊れやすさ
  第6章: 単体テストの3つの手法
  第7章: 単体テストの価値を高めるリファクタリング
  
  第3部: 統合（integration）テスト
  第8章: なぜ、統合（integration）テストを行うのか？
  第9章: モックのベスト・プラクティス
  第10章: データベースに対するテスト
  
  第4部: 単体テストのアンチ・パターン
  第11章: 単体テストのアンチ・パターン

• 著者紹介（「BOOK著者紹介情報」より）（本データはこの書籍が刊行された当時に掲載されていたものです）

  Khorikov,Vladimir(KHORIKOV,VLADIMIR)
  Ｖｌａｄｉｍｉｒ　Ｋｈｏｒｉｋｏｖ氏はソフトウェア・エンジニア、Ｍｉｃｒｏｓｏｆｔ　ＭＶＰの受賞者でもある。また、ソフトウェア開発についての教育をオンラインで受けられるＰｌｕｒａｌｓｉｇｈｔというサービスで講師もしている。彼は１５年以上に渡ってソフトウェア開発に携わっており、その経歴の中で、開発者のチームに対する単体（ｕｎｉｔ）テストの指導も経験している。ここ何年かは、単体テストに関するいくつかの人気のブログ記事を連載したり、オンライン講座を受け持ったりしてきた。彼のオンライン講座の受講者からよく称賛されるのは、彼が単体テストについての強固で理論的な背景を持っていて、その理論を実際にありそうな例に適用して教えてくれることであり、それは彼の最大の強みでもある
  
  須田 智之(スダ トモユキ)
  １５年近くおもにＳＩ企業の社員としてシステム・エンジニアに携わり、それ以降はフリーランスのシステム・エンジニアに。企業向けのシステム開発のかたわら、個人での開発、および、記事や書籍の執筆や翻訳を行っている

• 著者について

  Vladimir Khorikov (ウラジーミル コリコフ)
  ソフトウェア・エンジニア、Microsoft MVP受賞者、単体テストに関するブログの執筆や講座を受け持ったりしている。
  
  須田智之 (スダ トモユキ)
  フリーランスエンジニア、IT分野の記事や書籍も執筆している。執筆した書籍に『RxJavaリアクティブプログラミング』、翻訳書に『セキュア・バイ・デザイン』がある。

単体テストの考え方/使い方 [単行本] の商品スペック