2

私はいくつかのテスト駆動開発の実践を試し始めており、コードのこのビットをテストするかどうか、もしそうならどのようにテストするかを決めるのに問題があります。

AbstractServerとを含むクラスがServerSocketFactoryありますServerSocket：


public abstract class AbstractServer extends Thread {

    ...SNIP...
    //ServerSocket and factory. 
    private ServerSocket ss; 
    private ServerSocketFactory ssf;

    public AbstractServer ( int _port ) { 
        this.port = _port;

        try {
            ssf = ServerSocketFactory.getDefault();
            ss = ssf.createServerSocket(port);
        } catch (IOException e) {
            // Couldn't create ServerSocket, die. 
            System.exit(1);
        }
    } 
    ... SNIP ...

とは両方ともでありServerSocket、このクラスの外部に公開されることはありません。ServerSocketFactoryprivate

私の質問：

  1. 実際にとを作成するかどうかを確認するためのテストを作成する必要がServerSocketありServerSocketFactoryますか？それらはprivateクラス内から公開されておらず、公開されていません-どのくらいのテストが多すぎるテストですか？

  2. それらの作成をテストすることが私がすべきことである場合、クラスの外部からプライベートな非公開（ゲッターメソッドなし）オブジェクトの作成をテストするにはどうすればよいですか？私の素朴な（読んで：テストされていない）仮定は、私がテストクラスを作成するということextending AbstractServerです; 次に、テストしているものを作成する必要があります。これは、最初にprotectedそれらを作成する目的を半ば無効にprivateします。

4

4 に答える 4

1
  1. 私はクラス変数を設定するための単体テストを作成しません。これは些細なことであり、私の意見では、テストは必要ありません。ルーチンをテストするための単体テストを作成します。たとえば、add()メソッドが実際に追加し、remove()メソッドが実際に削除することを確認するには（正しいオブジェクト）。これらのクラス変数が何らかの理由で正しくインスタンス化されていない場合、私の機能テストはこれをキャッチします。
  2. 変数/クラスのテストについてprivateは、次の回答を確認することをお勧めします：https ://stackoverflow.com/a/7075965/1201423 。その背後にある基本的な概念は次のとおりです。それがprivateあり、それをテストする必要がある場合、それは本当にあるべきprivateですか？
于 2012-06-27T00:18:11.540 に答える
1

まず第一に、ユニットテスト中にクラスの内部の詳細について考えないでください。ユニットテストの場合、テスト対象のクラスはブラックボックスです。その内部構造についての情報はありません。それが単体テストの考え方です。

さて、自分自身に質問してください：あなたのクラスが公開している機能は何ですか？あなたの例によると、それはサーバーソケットを作成し、それを聞き始めます。ここで、この機能（擬似コード）を指定する手段として単体テストを使用します。

int port = 12345;
AbstractServer server = new AbstractServer(port) { };
new Socket("localhost", port);

それでおしまい。このテストでは、クラスがどのように機能し、何をするかを説明します。クラスがその機能を提供しなくなったとき/場合-テストは失敗し、それについてあなたに示します。それがまさにテストの目的です。

于 2012-06-27T13:37:03.863 に答える
0

この単純なコンストラクターを具体的にテストする必要はありません。呼び出しは2つだけです。どちらも公的にアクセス可能なメソッドに対するものであり、それ自体で機能することを確認するためにテストできます。より複雑なコンストラクターの状況でも、テスト可能なビルダーパターンを使用する必要があります。

どれだけ多すぎるかというと、カプセル化を少し緩めてテストしやすくすることもあるかもしれませんが、状況によって異なります。一般に、パブリックAPIを徹底的にテストする限り、モジュール内のすべてのコードが正しく機能していることを確信できます。パブリックAPIが完全に機能する場合は、プライベートコードで問題が発生することはありません。

これは、カバーするのが難しいいくつかの領域でのtddに関するまともな記事です：ここ

于 2012-06-27T00:17:21.237 に答える
0

まず第一に、抽象クラスをテストすることは良い考えではありません。具体的な実装をテストする必要があります。抽象クラスは（IS-A関係を介して）コードの重複を削除する方法にすぎません。他の多くの方法で重複を削除できます（たとえば、私が好むのはHAS-A関係です）。

あなたのコードとあなたの質問を見ると、あなたにとって良いスターターになるかもしれません：このビデオ： クリーンでテスト可能なコードを書く方法。 それはあなたが取ったアプローチが良い考えではないかもしれない理由をあなたに教えて、そしてあなたにいくつかのサンプル解決策を指摘するでしょう。

一般的に：クラスが提供するシナリオ/機能を指定します。実装の詳細をテストしないでください。

初心者にとっても良い知識源はこれです：テスト駆動開発ブログ。そこにある古い投稿を見てください。

編集：レガシーコードをテストしたい場合は、そのためのパッテンもあります。その場合、原則として、単体テストではなく、受け入れから開始します。

于 2012-07-02T12:20:46.050 に答える