2016-07-01 5 views
1

ディレクトリを作成してファイルを転送するコードがあります。ユニットテストをしたい。しかし、問題は、これらのディレクトリが作成されたユニットテストを実行するときですが、私はそれを望んでいません。これらのディレクトリを作成するコードでは、運用環境を稼動させているときに限ります。私はこれについて調べてみましたが、すべての検索結果はJUnitクラスのTemporaryFolderを示唆しています。しかし、それは私が望むものではありません。私はテストケース内にディレクトリを作成していません。私はそれらを作成するコードをテストしています。だから、TemporaryFolderクラスがどのように私を助けることができるか分かりません。私は以下のようなコードを持っていますユニットディレクトリを作成するテストコード

public class Util { 

    public File getLocation(String location) { 
     File result = new File(location); 

     if (!result.exists()) { 
      result.mkdirs(); 
     } 
     return result; 
    } 
} 

私はどのようにこのようなコードをユニットテストしますか?電話するたびに

util.getLocation("base/location"); 

ディレクトリが作成されていますが、私はそれを望んでいません。本番環境でコードを実行する場合にのみ作成してください。

更新 質問に対するコメントがあります。私は私の質問を更新することに決めました。まず、getLocationのシグネチャは少し誤解を招くことがあります。それは私がテストしている正確なコードではありません。そのような長いコードなので、そのアイデアを伝えようとしました。これは基本的に同じですが、問題はgetLocation()が上記のようにパラメータを取らないということです。 getLocationの内部では、パスに文字列を返す別のメソッドが呼び出されます。つまり、私はディレクトリを作成する際に何が使用されているかを制御できません。また、本番環境と開発環境の両方を実行し、これらのディレクトリが実動コードの実行中に作成されたら、単体テストがすべてのビルドで実行されるため、コードが再構築されてもそれらを削除しないでください。

public File getLocationForReports() { 

    String softwareHome = GeneralUtil.getSoftwareHome(); 
    File path = new Path(softwareHome, "reports").toFile(); 

    if (!path.exists()) { 
     path.mkdirs();  
    } 
    return path; 
} 

私はGeneralUtil.getSoftwareHome()が返すものの制御を持っていない上に、あなたが見ることができるように、私も「TMP /場所」のようなダミーの場所に送信することはできませんし、後で削除して、私もありません私はいくつかのファイルがあるので、プロダクションコードが実行されたときにこれらのディレクトリが作成された場合、これらのディレクトリを削除します。

+3

JUnits Temporary Folderなしでこれを行うのが妥当な唯一のアプローチは、MockitoのようなMock-Frameworkを使用することによってIMHOです。多分これはあなたを助けます:http://stackoverflow.com/questions/18977057/mock-file-filereader-and-bufferedreader-class-using-mockito。しかし、Unit-Testsがフォルダ/ファイルを作成するというあなたの問題は何ですか?テストの実行後にすべてを削除するように定義することができます。また、他の環境で実行できるように、テストに他の/相対パスを使用することもできます。 – Supahupe

+0

テストの最後に削除しますか? – Manu

+0

フォルダを作成して、それが正常に機能しているかどうかを確認し、削除してください... – Supahupe

答えて

3

には何もしないことをお勧めします。は、PowerMockを使用してテストを行います。

プロダクションクラスはPowerMockによって操作されます。それはしばしば本当に奇妙なエラーに繋がります(あなたのコードで本当の問題を見つけずに何時間も掘り下げることができます)。それはカバレッジを行うあなたの能力を殺します。

言い換えれば、私にとって、PowerMockの「必要性」は、あなたの設計が合理的なテストを可能にするように構成されていないことを意味します。そして、醜いPowerMockハンマーに投資する代わりに...あなたはあなたのデザインを再加工するのに時間を費やしました!

あなたの場合:静的メソッドの呼び出しを取り除く。コードに疑似オブジェクトを提供するためにの依存性注入を使用できることを確認してください。意味:EasyMockのようなフレームワークでは、あなたがしたいことを何でもしてくれる疑似オブジェクトを作成することができます。テスト中のコードにそのような "準備された"モックを渡します。あなたのテスト中に何が起こるかを完全に制御することができます。

本質的には、プロダクションコードが1か所で多すぎることが問題であることがわかります。したがって、あなたはそれをテストするのに苦労します。それを切り取って、そのコードにあるそれぞれの "責任"を別々のクラス/メソッドに入れます。それらを個別にテストします。

0

PowerMockを使用してテストを作成することをお勧めします。 これには2通りの方法があります。どちらも、PowerMockが必要になりますし、テストは次のように注釈されるために必要とされます。 @RunWith(PowerMockRunner.class) @PrepareForTest(あなたが .classファイルをテストしたいクラス)

まずあなたがモックしようとすることができますpowermockitoを使ったGeneralUtil.getSoftwareHome()の静的呼び出し。あなたのコードの機能をテストすることができます mockito mock a constructor with parameter

この方法: PowerMockito mock single static method and return object

2番目のオプションは、Pathオブジェクトとそれが返す呼び出しのコンストラクタをモックとしています。

関連する問題