2012参加記事です。前日(8日目)は、KTZさんの「Rhino.Mocksをちょっとだけ幸せにするお助けクラス」でした。xUnitによるテスティングフレームワークの共通仕様として、「テストクラス内のテストの実行順序は不定」というのがあります。いえこの仕様をテストを書く上で意識することはあまりありません。テストのあるべき姿として、テストメソッドは他のメソッドから独立しているべきですし、JUnitの場合、ほとんどの実行環境上で、ソースコード上の並びと同一順でテストが実行されていたからです。Java7(Oracle実装)からは事情が異なります。{System.out.println(name.getMethodName());}}上記のようなテストケースをJUnit4.10以前で実行した場合*1、java6で実行した場合はインスタンスから値を取得できること引数にnullを渡した時にnullが返ることキーが重複している場合に例外になることという順番となりますが、Java7で実行した場合は引数にnullを渡した時にnullが返ることインスタンスから値を取得できることキーが重複している場合に例外になることという結果となります。Java6以前とJava7で異なった順番で結果を返すためです。この結果に引きずられて、テストの実行順序もかわってくるわけです。前述しているように、テストメソッド相互の独立性を確保していればこの問題にひっかかることはないのですが、static領域の書き換えを行っているなどでテストメソッド同士が暗黙に依存してしまっている場合は、この問題がひっかかります。...という問題をJUnitのメンテナも認識していたようで、JUnit4.11からはテストの実行順序に関する仕様がかわりました。JUnit4.11からは、テストメソッドは、実行環境に関係なく、テストメソッドの名称のハッシュコードの昇順で実行されるのが仕様となりました。アノテーションを付与することにより、これまでと同じ順番で実行されます。アノテーションが用意されています。前述した通り、テストメソッド相互が独立しているような、あるべき姿でテストを書いていれば、この問題にひっかかることは少ないと思います。一定規模のテストケースがある状態で、JVMをバージョンアップする場合や、JUnitをバージョンアップする場合は、要注意のポイントとなるでしょう。