■ Java 実装(プログラミング+単体テスト)

  ・プログラミング
    ・業務内容を理解したうえでプログラミングする
      ・仕様書が正しいとは限らない
    ・疑問があれば、仕様作成者に「絶対に!」問い合わせる ⇒ 嫌われても問合せる
    ・プロジェクトや社内でコーディング規約があれば必ず従う
      ・その範囲内で、分かりやすいプログラミングを工夫する
    ・クラス構成が設計書で明示されていない場合は、クラス構成も考える
      ・クラス図まで書かれていない仕様書も多い
    ・プロジェクトで指定されているライブラリを必ず確認しておく
    ・高度なプログラミングよりも、分かりやすいプログラミングを心がける
      ・プログラミングによって処理スピードが問題になることはほとんどない
      ・メモリ使用量も問題になることは少ない
      ・他の人が読んだら分からない、しばらくすれば、自分が読んでも分からない
    ・コメント
      ・コメントは一行ごとに記入する必要はない
      ・コメントは業務上の意味を記入する
      ・コメントを丁寧に記述していっても、さほど工数アップにはならない
  ・レビュー
    ・自分から視点を決めて、積極的に問題点を指摘してもらう
    ・レビューの問題点
      ・プログラミングが終了してから実施するので、あまり意味がない
      ・単に形式的なルール違反を指摘するレビューが多い
    ・レビュー以前に自分で積極的に問題点を潰す覚悟が必要

  ・テスト仕様書
    ・テスト仕様書の形式はいろいろあるが、プロジェクトで決まったものを使用
    ・ロジックのテストはすべてのケースを行う
      ・単体テストでは、ホワイトボックステスト
        ・結合テストでは、内部ロジックはテストが難しい
    ・境界値テストやエラーデータテスト、nullデータテスト、全桁テストは必須
    ・エラーデータ ⇒ 型が違う、長さが違う、範囲が違うなどなど
    ・テスト仕様書サンプル参照

  ・同値分析(同値分割)
    ・入力値をいくつかの範囲に分割し、それぞれの範囲から、代表値を選んでテストする
    ・範囲の分割方法は、一つの範囲が結果が同じようになるようにする
  ・境界値分析(限界値分析)
    ・結果が異なる入力値の境目の値をテストする

  ・テスト実施
    ・単体テストではプログラマとテスターは同じが普通
      ・間違った仕様理解の場合は、間違ったデータでテストすることもある
        ⇒ 結合テストになるまで分からない
        ⇒ テスト仕様書のレビューで見つける

    ・テスト準備に意外と時間がかかるので注意
      ・テスト仕様書、テストデータ、ドライバやスタブなど
      ・スケジュールを立てるときに考慮する

    ・DBのテストは、いろいろと大変
      ・データの設定が大変
      ・一度実施するとテーブルの状態が変わる
      ・実施後、他の人が使うのであれば、元に戻す必要がある
      ・大量のSQLが必要になったりする
      ・場合によっては他の単体テストの結果を貰う

    ・最初のうちは基本的なところが動かいことが多い
    ・正常処理だけではなく、エラー処理も重要
    ・テストデータのバグも意外と多い
    ・単体テストはプログラミングと同じくらいの時間がかかる

  ・ドライバとスタブ
     ・テスト対象のプログラムを起動するプログラムがない
       ・テスト対象のプログラムを起動するプログラムのダミー(ドライバ)を作成する

     ・テスト対象のプログラムが呼び出すプログラムがない
       ・テスト対象のプログラムが呼び出すプログラムのダミー(スタブ)を作成する

  file:単体テスト仕様書.xls

□ JUnitなどによるテスト

  ・現在のプロジェクトでは、テストツールを用いたテストの自動化が行われている

  ・Java用のテストツールでは、以下のようなものがある
    ・JUnit - ケント・ベックなどが開発したJava用テストツール
    ・dbUnit - データベース関連のテストを行うツール
        JUnitなどと一緒に使う
    ・Mockito - テスト用のスタブツール
        まだ実装されていない機能を呼び出すテストや実クラスを呼び出すとテストが難しいものに対して、スタブを作ってテストする環境
    ・TestNG - JUnitと同じくJava用のテストツール
        テスト用のデータをテストプログラムではなく、XMLファイルに記述する

  ・テストの形態(例)
    ・メモリ上のテスト
      ・クラス単体あるいは少数のクラスが対象

    ・データベースの読込みテスト
      ・SQLで検索し、対象データが正しく読み込まているか
      ・テスト前に設定ファイに従ってデータベースにデータを設定
      ・データを検索した後に、正しく読み込まれているかチェック

    ・プログラムテスト
      ・データベースに設定したテストデータを元にテストを走らせ、結果をデータベースで検証する
      ・テスト前に設定ファイに従ってデータベースにデータを設定
      ・テスト後に、設定ファイルに定義されたデータとテーブルの内容が合致しているか?

  ・利点と欠点
    ・テストデータ作成やテストケースの準備に多くの時間がかかる
      ・プログラムの仕様が変更された場合も対応が必要
    ・いったんテストケースを作成すれば、ほぼ自動でテストを行えるので、手間がかからない
      ・Jenkinsなどを使えば、毎日自動でテストできたりする
    ・必要な時に、手間をかけずにテストできるので、非常に安心感がある


-----------------------------------------------------
・目次 Java システム開発
  http://blogs.yahoo.co.jp/artery2020/40586660.html
・目次 - Java入門
  http://blogs.yahoo.co.jp/artery2020/39975776.html
・目次 - ビジネスパーソンの常識と非常識
  http://blogs.yahoo.co.jp/artery2020/39728331.html
・目次 - 論理・発想・思考についての考察と鍛え方
  http://blogs.yahoo.co.jp/artery2020/39657784.html
-----------------------------------------------------