2017-04-24 11 views
1

ユニットテストを実行するときにのみメソッドが起動されるように、Javaソースコードに挿入できるユニットテストアノテーションまたは機能フラグはありますか?例についてはユニットテストを使用してソースクラスから特定のメソッドを実行

public class A {   
    @Annotation 
    public void fooA() { } 

    public void fooB() { } 
} 

私のユニットテストクラス:このシナリオでは

public class TestA { 
    ... 
} 

、私は私のユニットテストクラスの種皮を実行したとき、私はfooA()とfoob型を(実行したいです)

しかし、classAを含む製品ソースコードを実行したい場合は、関数fooB()のみが実行され、fooA()では実行されません。

+1

それには理由がありません。これが実行されている環境を気にしないでください。テストに特別な環境が必要な場合は、それを自分で設定してください。 – amit

+0

これは "テスト用のデザイン"ですか? 'fooA()'のみが公開されているので、テストハーネスの一部として呼び出すことができますか?基本的にはプライベートメソッドでなければなりませんが、テストするために公開する必要があります。 – markspace

+0

プロダクション版のソフトウェアに含まれていないものをテストするのに無駄な努力をしているのはなぜですか? – Michael

答えて

3

一般的には:そこに行かないでください。

生産コードには1つの責任があります。 1つの責任:生産業務を行うこと。あなたは複雑なテスト関連の側面を考慮に入れません。

場合によっては、(依存性注入のために)より多くの引数を取るコンストラクタを持つことが必要な場合や役立つ場合があります。次に、そのパッケージを保護して、非公式の "/ **単体テストのみ* /"コメントをそこに入れてください。

私の言うことは、そのような注釈がないことです。また、それを持っていることは理にかなっていません。外部インターフェイスを明確なjavadocで記述すると、の明白なになるようにクラスを作成し、ユーザーはfooB()を使用/呼び出しする必要があります。

重要なことは、コード内にテスト専用の成果物がいくつかあるため、実稼働環境で問題が発生することです。そしてそのリスクを避ける最善の方法:そのようなアーティファクトを作成しないでください。

+0

あなたはそうです。ようこそ; – Michael

+0

申し訳ありませんが、ここでの冗談は理解できませんでした:p –

+0

あなたの答えは理にかなっています。私の考えは無限ループに巻き込まれました。ロジックプロードコードをリファクタリングすることは、道のりです! :P –

0

テストパッケージをテスト対象ユニット(UUT)と同じに宣言することができます。

package com.example.fubar.arglebargle; 
public class A { 
    // package-private, TEST ONLY! 
    void fooA() { } 

    public void fooB() { } 
} 

ユニットテストクラス:

package com.example.fubar.arglebargle; 
public class TestA { 
    // etc... 
} 

私のIDEにはJUnitテストでこれを自動的に行います。私のすべてのテストは、私のUUTと同じパッケージで宣言されています(ただし、ソースツリーはまったく違っていますが、同じサブディレクトリにテストとプロダクションソースを入れないでください)。

これは、使用できない内部構造にアクセスする場合に便利です。それはまた、標準的な習慣と思われるので、私はそれをすることに対して何もないと思う。

これで誰もがfooA()を呼び出すことはなくなりますが、潜在的な問題はクラスと同じパッケージ内のクラスに制限されます。それは心配するコードの数がはるかに少なく、しばしば同じパッケージ内の他のクラスのコメントを慎重に読むためにコードを修正する人に頼ることができます。

いくつかのテストフレームワークはプライベートメソッド(おそらくセキュリティマネージャを無効にすることでアクセスできます)にアクセスできると思いますが、私は手を知らないです。重要であれば、テストフレームワークを研究します。

0

なぜテストでのみ使用されるコードは、実稼働環境で使用できるはずですか?

1)アプリケーションがそれを使用しないため、アプリケーションコードを検証しません。

2)それを使用するクラスのクライアントでは、エラーが発生しやすくなります。

3)コードの保守性と読みやすさが向上します。
たとえば、開発者は、アプリケーションコードに呼び出し元がない場合、このメソッドが存在する理由を不思議に思うかもしれません。 これをデッドコードと見なして、メソッドを削除し、それを使用する単体テストも削除できます。

問題を解決するために、非実稼働環境で必要なこの方法は、非実稼働環境でのアプリケーションのパッケージ化に含める必要がありますが、運用環境のパッケージからは除外する必要があります。
MavenとGradleのツールは、この要件を非常にうまく処理します。

実際には、メソッドが本番環境で必要なクラスの一部になっているため、このメソッドを使用することはできません。したがって、最初のステップは、特定のクラスで目的をテストするためのメソッドを抽出することです。
このようにして、フィルタリングすることが可能です。

関連する問題