Mirror House Lab: 8月 2015

2015年8月9日日曜日

テストデータを管理する方針

『継続的デリバリー』の、テストデータの管理についての記述を整理してみた。該当する章節は、

12.5 テストデータを管理する
12.6 データの管理とデプロイメントパイプライン

それから12.5から参照されている、

8.5.1 受入れテストにおける状態

の3箇所。特に断りの無い限り、『継続的デリバリー』のいう受入れテストのデータ管理を念頭に置いている。

テストデータの管理で問題となるのは、1) パフォーマンス、2) テストの分離の2つ。xUTPだとそれぞれSlow TestsとSeparation of Concernsに対応しているように思う。

どちらの問題でも、真っ先に原因として挙がるのがデータベース。ユニットテストならデータベースアクセス移譲先 (デザインパターンDAO相当) をテストダブルで置き換えられる。これはパフォーマンスにも分離にも効く。DBの状態も含めてテストしたい場合、インメモリDB (H2, SQLite, JavaDBなど) を使うこともできる。

データベースに限らず、テストとデータのつながりを管理するアプローチには、次の3つがある。

テストの分離：各テスト用のデータは、そのテストからしか見えないようにする。
順応型テスト：テストがデータ環境を調べ、実際のデータに合わせて振る舞うようにする。
テストの順序づけ：テストの実行順序を予め決めておいて、一つ前のテストの出力を次のテストの入力とする。

スケールするのは1だけだと言っている。3は分かりやすい無理ゲー。こんな強く依存していたらスケールさせられない。2は一見良さげに見えるけれど、分離しきれていないと、別のテストで実際のデータが思いもよらない状態になっていることがある。xUTPでもTest SmellsとしてConditional Test Logicが挙がっている。

「テストの分離」のためには、まずテスト終了時にテスト前の状態に戻すとある。そうしないと、次のテストに今のテストのデータが見えてしまう。ただこれにはオプションもある。『システムテスト自動化標準ガイド』や『実践テスト駆動開発』では、テスト対象が登録したデータはテスト終了時に消さずに、テスト開始時に消すことを勧めている。もう一つの方法は、データを機能分割すること。これができるかどうかは、テスト対象の特性に強く依存する。

データを分割し、巨大で複雑なデータ構造への依存を減らすには、まずデータを整理しないといけない。著者はこんな風に言っている。

何よりもまず、プロダクションデータのダンプを取得して受入れテスト用にテストデータベースに投入したいという誘惑に負けないこと。

統制のとれた最小限のデータセットを保守しよう。

整理の取っかかりとなるのが、次の3種類のデータの区別。

テスト固有のデータ: 一意でなければならない。テストの分離の手段になる。
テストが参照するデータ: テストには関係するがふるまいには影響しないデータ。そこら中で使われるマスタデータ類を指していると思う。
アプリケーションが参照するデータ: アプリケーションを立ち上げるのに必要なデータ。

一言で言うと、正しく動くと分かっている（契約による設計の言葉を使うと、事前条件を満たしている）開始位置を特定し、テスト開始時にその状態を復元する。言ってしまえばこれだけなんだけれど、そのためにはテスト対象とテストデータをよく理解する必要がある。それも一部のテストだけじゃない。うまくテストを分離するには、全体を俯瞰する必要がある。

なお、その開始位置を復元するのには、アプリケーションのAPIを利用するよう勧めている。理由は3つ。

システムを矛盾した状態に持ち込ませない。
データベースやAPIのリファクタリングの影響を避けられる。
APIのテストにもなる。

できないときは、事前条件をアサートする防御的なテストコードにしたり、アサートを相対的（例えば、レコードが3件あることではなくて、3件増えたことにする）にしたりする。

References

2015年8月2日日曜日

JUnitのRunner (Enclosed, Theories, Categories) を併用したときの動き

JUnit4の次のRunnerの関係を整理してみた。なお、JUnitのバージョンは4.12。

Enclosed
Theories
Categories

論理的にテストクラスを分類しつつ、並列化するための分類もしたくなることがあるので、JUnitの仕組みでどこまでできるか知っておきたくて。

では、早速。

EnclosedとTheoriesは併用できる。外部クラスEnclosingTheoryをJUnit実行すれば、内部クラスEnclosedTheoryがJUnit実行される。これでTheoriesを使いたいけれど、テストクラスを分けたくない場合は大丈夫。

@RunWith(Enclosed.class)
public class EnclosingTheory {
    @RunWith(Theories.class)
    public static class EnclosedTheory {
        @Theory
        public void testTheory(Fixture f) throws Exception {
            // test method.
        }
    }
}

EnclosedとCategoriesは併用できない。外部クラスEnclosingTheoryにカテゴリOuterを付けて、Categoriesを使ったテストスイートを実行しても、テストが見つからない。

@RunWith(Enclosed.class)
@Category(Outer.class)
public class EnclosingTheory {
    @RunWith(Theories.class)
    public static class EnclosedTheory {
        @Theory
        public void testTheory(Fixture f) throws Exception {
            // test method.
        }
    }
}

@RunWith(Categories.class)
@IncludeCategory(Outer.class)
@SuiteClasses(EnclosingTheory.class)
public class CategorizedTestSuite {
    // NoTestsRemainException is thrown.
}

ただ、内部クラスEnclosedTheoryを直接指定すれば、実行させられる。Enclosedの甲斐がないと見るか、互いに独立した分類が使えると見るか、悩ましい。

@RunWith(Enclosed.class)
public class EnclosingTheory {
    @RunWith(Theories.class)
    @Category(Inner.class)
    public static class EnclosedTheory {
        @Theory
        public void testTheory(Fixture f) throws Exception {
            // test method.
        }
    }
}

@RunWith(Categories.class)
@IncludeCategory(Inner.class)
@SuiteClasses(EnclosedTheory.class)
public class CategorizedTestSuite {
    // run testTheory.
}

上記でテストが実行されるので、CategoriesとTheoriesは併用できることが分かる。

調べて見ると、CategoriesとEnclosedはそれぞれSuiteのサブクラスだった。併用できないのもさもありなん。

以下は、調べながら考えたことをつらつらと。

こうして調べて見ると、Categoryアノテーションで並列化のための分類をするのは筋が悪い気がしてきた。MECEに分割したいのだけれど、アノテーションの付け忘れやテストスイートへの追加忘れがありそう。何並列にするかによるけれど、上位のパッケージ構成でざっくり割っちゃった方が安全かなぁ。

CIとの相性も考える必要がある。AntのJUnitタスクから実行するなら、パッケージ構成やファイル命名規約に加えてFileSetで色々できる（開発端末上では使えないけれど）。一方、MavenはCategoryにも対応している。そろそろAntから卒業した方がいい気がしてきた……。

なお、調べるために書いたコードはso-c/junit4.12-categories-configuration-sampleにアップしてある。ここに書いたスニペットよりゴチャゴチャしているけれど、ちゃんと動くのでこれはこれで。

2015年8月1日土曜日

GitHubにPJを作成し、Eclipse (EGit) でCloneし、Mavenプロジェクトにする

EclipseプロジェクトをEGitでGitHubにPushするの手順がいまいち使いにくかったので、EclipseをMarsにしてMavenを使ったやり方を整理してみた。まだ気になるところはあるけれど、一旦こんなところで。

GitHub上にリポジトリを作る

GitHubにログインして、右上の"+"メニューから"New Repository"を選び、リポジトリ作成画面を表示させる。必要な項目を入力して、"Create repository"ボタンを押すと、リポジトリが作られる。

入力内容によってREADME.mdなんかが出来たり出来なかったりするけれど、この投稿はファイルができているケースを想定して続ける。

Eclipseとリポジトリを連携する

httpsプロトコルで連携する。sshでも連携できるけれど、その場合は事前に公開鍵を作成しGitHubに登録しておく必要がある。

Windows > Show View > Git Repositoryを選び、そのビューを表示させる。"Clone a Git Repository"を選び、Location > URIにGitHubリポジトリの"HTTPS Clone URL"を入力する（リポジトリ初期表示時はHTTPSではなくSSHなので、HTTPSリンクを押して切り変える）。Hostなどが自動的に埋められるので、AuthenticationにGitHubのユーザとパスワードを入力し、"Next"ボタンを押す。Local Destinationを選んでFinishを押すと、そこにリポジトリのCloneができる。

リポジトリからEclipseにプロジェクトをimportする

EclipseのGit Repositoryビューで、リポジトリを右クリックして、"Import Projects"を選ぶ。"Import as general project"を選んで、"Next"ボタン、"Finish"ボタンを順に押していくとimportされる。

general projectを選んでいるのは、リポジトリを作成するときにファイルが作られているから。こうしてからこの後にMavenプロジェクトにするのと、完全に空にしておいてこの時に新しいMavenプロジェクトとして作成するのとどちらがベターなんだろう。

ここで.gitignoreにgitignore/Global/Eclipse.gitignoreを追加しておくと後から誤コミットをしなくて済む。.classpathなどなくてもこの後Maven化するので問題ない。

インポートしたプロジェクトをMavenプロジェクトにする

importしたプロジェクトを右クリックして、Configure > Convert to Maven Projectを選ぶ。

J2SEに関するWarining "Build path specifies execution environment J2SE-1.5. There are no JREs installed in the workspace that are strictly compatible with this environment."が出る。pom.xmlに下記を追記して、Maven > Update Projectで解消すいる（参考：Maven Project を作成すると警告が出る - 電卓片手に）。

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>2.3.2</version>
      <configuration>
        <source>1.8</source>
        <target>1.8</target>
      </configuration>
    </plugin>
  </plugins>
</build>

Mavenで依存するライブラリを追加する

右クリックして Maven > Add Dependenciesを選び、からライブラリを検索して追加すると、Maven Dependenciesに追加される。

あとは

好きなようにコードを書けばOK。ただし、Mavenのarchitypeを使っていないので、ソースフォルダなどは手で作らないといけない。GitHubのリポジトリは空にして、新しいプロジェクトを作ってimportすればarchitype使えそうだけれどどちらが楽だろうか。

参考

登録: 投稿 (Atom)