依存機能JUnitテストは、私は（この質問のために簡略化）次のテストを持っている静的フィールド

Question

を共有することはできません。

@FixMethodOrder(MethodSorters.JVM) 
public class ArticleTest { 

    private static Article article; 

    @Test 
    public void testCreateArticle() { 
     articleService.create("My article"); 
     article = articleService.findByTitle("My article"); 
     assertNotNull(article); 
    } 

    @Test 
    public void testUpdateArticle() { 
     article.setTitle("New title"); 
     articleService.save(article); 
     assertNull(articleService.findByTitle("My article")); 
     article = articleService.findByTitle("New title"); 
     assertNotNull(article); 
    } 

} 

testCreateArticleが正常に渡しますが、articleがnullであるため、最初の行でtestUpdateArticle失敗し、これ投げNPE（articleがnullではないと主張した最初の試験でしたが）。

誰もが理解していますか？私はPlay Framework（バイトコードの操作が大好き）でテストを実行するので、これは何とか関連していることに注意してください。

また、依存テストを行うのは悪い練習ですが、IRLはこれではありませんユニットテストが、テストシナリオの一種なので、私はちょうど依存のテストに人々がそれらを好きではない理由を自分で理解しようとする与えたかった;）

しかし、いずれにせよは、静的フィールドテストの間で共有されるようになっています、 私が間違っている？

---

アップデート：私はtestUpdateArticle()の資料を再作成することができることを知っているが、実際のテストは（多分私はMVCEの作成に失敗した...）複雑です。最初のものは何も特別なものは必要なく、2番目のものは作成済みの記事が必要で、3番目のものは作成された更新済みの記事などが必要です。私はテストの間に状態を保つことにより、毎回すべてのDB操作をやり直すことを避けようとしました。

Answer 1

@Before注釈を使用して各テストを行う前に記事オブジェクトを再作成する方がよいでしょう。

このように記事オブジェクトは静的である必要はなく、テストが容易になります。

注：

@FixMethodOrder 
public class RemoveMeTest { 
private static String string; 

@Test 
public void testOne() { 
    string = "foo"; 
} 

@Test 
public void testTwo() { 
    System.out.println("in test two: " + string) ; 
} 
} 

、出力は確かに "foo" というです：私はあなたの行動を再現することはできませんクリーンアップするために@After方法

@After 
public void tearDown() { 
    articleService.delete("My article"); 
} 

Answer 2

の資料を忘れないでください。あなたのテストケースに特別な構成やテストランナーはありますか？

テストケースは、実際には他のテストケースに依存しないようにすべきです。たとえあなたのケースがもっと複​​雑で、他の人が既にそれを言及していたとしても、それも言及したいと思います） テストAは失敗しますが、動作してもBとCも失敗します。あなたの例では、文字列 "my article"を変更したときにテストAが実行されますが、BとCは失敗します。 Cが失敗した場合は、前にAとBを実行して、Cが再び実行されることを確認する必要があります。

最悪です：全く必要のない複雑さが増します。テストコードは、可読性、複雑性、保守性などを参照して、実動コードほど価値があると私は信じています。 30行のコードではなく、10行のコードを理解する方がずっと簡単です。あなたは私の経験を信頼することができます。私はそれが間違っていました...そして現在の自己は（怠惰な）過去の自己について非常に怒っていました：P。それは言った：私は、DBの往復以上のテストケースを理解することを好む、それは長期的にはるかに安いです...