VSS 1.6.1 プラグイン 日本語化情報
インストール後に、プラグインフォルダへコピーした内容から

plugin.properties の内容を以下のように日本語へ変換し、Shift-JISで保存。

messages.properties も同じように。

作成後、JavaのBinフォルダにある native2ascii を利用してコードを変換します。
利用方法.
C:\j2sdk1.4.2_04\bin\native2ascii 元のファイル名 新しいファイル名

元に戻すには
C:\j2sdk1.4.2_04\bin\native2ascii -reverse 元のファイル名 新しいファイル名

message.properties については、 Jarファイルに入れましょ。

コード変換したファイルをプラグインフォルダにコピーします

JUnit으로 테스트 작성하기 

1. 단위 테스트 구조화

■ 테스트에 필요한 모든 조건과 상황을 준비 설정한다.(필요한 객체를 모두 생성하기, 필요한 자원을 모두 할당하기 등)
■ 테스트 대상이 되는 메서드를 호출
■ 테스트 대상이 되는 메서드가 원하는 대로 동작한다는 것을 검증한다.
■ 리팩토링

2. JUnit의 단정 메서드

■ assertEquals
 assertEquals([String message], expected, actual, tolerance)
 
 예) assertEquals("Should be 3 1/3", 3.33, 10.0/3.0, 0.01);
 
■ assertNull
 assertNull([String message], java.lang.Object object)
 
 assertNotNull([String message], java.lang.Object object)
 
 인자로 넘겨받은 객ㄹ체가 null인지(또는 null이 아닌지) 판정하고, 반대인 경우 실패로 처리.

■ assertSame
 assertSame([String message], expected, actual)
 
 assertNotSame([String message], expected, actual)
 
 expected와 actual이 같은 객체를 참조하는지 아닌지를 판정.

■ assertTrue

 assertTrue([String message], boolean condition)
 
 assertFalse([String message], boolean condition)
 
 boolean 조건이 참인지 아닌지 판정

■ fail

 fail([String message])
 
 테스트를 바로 실패처리. 절대 수행되지 않아야 될 부분(예외가 발생되는 부분 다음)을 표시하는데 사용.
 
3. JUnit 프레임워크

import junit.framework.TestCase;

public class LargestTest extends TestCase {
    private Largest largest;
   
    /*
     * 각각의 테스트 메서드들이 실행되기 전에 호출된다.
     */
    protected void setUp() throws Exception {
        largest = new Largest();
    }
   
    /*
     * 각각의 테스트 메서드들이 실행되고 난 다음에 호출된다.
     */
    protected void tearDown() throws Exception {
        super.tearDown();
    }

    /*
     * Test method for 'tdd.junit.ch2.Largest.largest(int[])'
     */
    public void testLargest() {
        assertEquals(9, largest.largest(new int[] {9,8,7}));
        assertEquals(-7, largest.largest(new int[] {-9,-8,-7}));
    }
}

4. JUnit 테스트 조합

여러개의 테스트 케이스를 통합한 것을 테스트 스위트(TestSuite)라고 한다. 테스트 스위트를 작성해 두면 여러개의 테스트 케이스를 한 번에 실행시킬 수 있다.

import junit.framework.Test;
import junit.framework.TestSuite;

public class AllTests {
   public static Test suite() {
       TestSuite suite = new TestSuite("Test for tdd.junit");
     
       //$JUnit-BEGIN$
       suite.addTestSuite(TestJukebox.class);
       suite.addTestSuite(TestMyStack.class);
       //$JUnit-END$
     
       return suite;
   }
}

5. JUnit 사용자 정의 단정 메서드

경우에 따라 사용자 정의 단정 메서드를 만들어야 할 경우 작성.

import junit.framework.*;

/**
 * Project-wide base class for Testing
 */
public class ProjectTest extends TestCase {
    /**
     * Assert that the amount of money is an even
     * number of dollars (no cents)
     *
     * @param message Text message to display if the assertion fails
     * @param amount Money object to test
     */
    public void assertEvenDollars(String message, Money amount) {
        assertEquals(message, amount.asDouble() - (int)amount.asDouble(), 0.0, 0.001);
    }

    /**
     * Assert that the amount of money is an even
     * number of dollars (no cents)
     *
     * @param amount Money object to test
     */

    public void assertEvenDollars(Money amount) {
        assertEvenDollars("", amount);
    }
}

이를 사용하기 위해서는 TestCaset를 바로 상속하지 않고 이 기반 클래스를 상속하여 사용.

6. JUnit과 예외

[테스트 메서드내 예외 선언]

public void testForException() {
    try{
        sortMyList(null);
        fail("Should have thrown an exception"); /* 예외발생시 실패 선언 */
    } catch(RuntimeException e) {
        assertTrue(true); /* 성공처리 선언 - "제어 흐름이 반드시 여기를 지나야 한다"는 문서화 역할  */
    }
}

[테스트 메서드 예외 선언]

public void testData1 throws FileNotFoundException {
    FileInputStream in = new FileInputStream("data.txt");   
출처 : Tong - I제로I님의 CVS/Ant/JUnit통

출처 : Tong - I제로I님의 CVS/Ant/JUnit통

통합 테스팅 프레임워크 JUnit | Eclipse	2004/09/20 17:02
http://blog.naver.com/thdusin/100005976306
<<Eclipse의 통합 테스팅 프레임워크 JUnit>> JUnit은 오픈 소스 테스팅 프레임워크로 플러그인 형식으로 Eclipse에 통합되었다는군요..   1. JUnit JAR 파일을 클래스패스에 추가하기 • 프로젝트 이름에 오른 클릭하고 컨텍스트 메뉴에서 Properties 선택 합니다. • Properties 대화상자 왼쪽 패널에서 Jaava Build Path 선택하고 오른쪽 Libraries 탭 선택하고 Add Bariables 버튼 클릭합니다. • New Variable Classpath Entry대화상자에 Configure Variables..버튼 클릭하면 New Variable Entry 대화상자가 열리면  변수 이름과 클래스패스에 Eclipse plugins 디렉토리에 org.junit_3.8.1\junit.jar를 입력합니다.      2.  디버깅에 필요한 JUnit 소스 JAR의 변수 추가 • New Variable Classpath Entry대화상자에 Configure Variables..버튼 클릭하면 New Variable Entry 대화상자가 열리면  변수 이름과 클래스패스에 Eclipse plugins 디렉토리에 org.eclipse.jdt.source_3.0.0\src\org.junit_3.8.1\junitsrc.zip를 입력합니다.       3. 추가된 JUnit을 프로젝트의 클래스패스에 추가하고, 디버깅을 위한 JUnit 소스 JAR와 연결하기 • 프로젝트의 New Variable Classpath Entry 대화상자에서 JUNIT 클래스패스 변수를 클릭하고 OK!!       • Properties 대화장사의 Libraries 탭에 추가된 JUnit 항목의 Source attachment를 더블클릭하고 JUnit 소스 JAR의 클래스 패스 변수를 입력하고 OK 클릭하세요       • JUnit 라이브러리가 Package Explorer에 표시됩니다.     4. JUnit 위저드 • 테스트하고자 하는 프로그램에 있는 모든 클래스에 테스트 클래스를 하나씩 만드는 가장 쉬운 방법은 JUnit 위저드를 사용하는 것이라는군요 • 테스트 케이스를 만들고 싶은 파일에 오른클릭하고, 컨텍스트메뉴에서 New > Other 선택하세요 • New 대화상자에서 Java>JUnit>TestCase 선택하고 Next 클릭하세요     •  New JUnit Test Case 대화상에는 폴더, 패키지, 테스트 케이스, 테스트 클래스, 상위 클래스등을 설정 (아래는 기본값을 바꾸지 않고 그대로 수용하고 setup(), teardown()의 메소드 스텁을 만드는 옵션만 클릭했습니다.)   • 테스트 케이스에서 사용하려는 목적으로 만든 데이터와 객체를 JUnit에서는 fixture라고 합니다. setUp() 메소드와 teardown() 메소드는 필요할 때마다 픽스처를 설정하고 제거하려는 목적으로 만든 것입니다. 이 두 메소드는 테스트 케이스 클래스에 있는 각 테스트 메소드의 실행 전후에 실행됩니다 • 테스트하려는 코드와 유닛 테스트를 같은 패키지에 집어넣으면 유닛 테스트가 패키지 접근 권한이 있는 메소드에 접근할 수 있는 장점이 생긴답니다.     • 다음 대화상자에서는 테스트 케이스 클래스와 상위 클래스 Object의 각 메소드를 테스트하는 메소드 스텁을 만드는 옵션이 표시됩니다. (테스트 하려는 메소드를 체크합니다.)     • 테스트 케이스 클래스 (이름의 끝에 Test가 붙은)가 생성되었습니다.     • JUnit의 주된 테스트 도구는 하나의 표현식이나 표현식 쌍을 테스트하는데 쓰는 오버로딩된 단정(assertion) 메소드이다. -         assertEqual(x, Y) : x와 y가 같으면 테스트 통과 -         assertFalse(b) : b가 false이면 테스트 통과 -         assertTrue(b) : b가 true이면 테스트 통과 -         assertNull(o) : 객체 o가 null이면 테스트 통과 -         assertNotNull(o) : 객체 o가 null이 아니면 테스트를 통과 -         assertSame(ox, oy) : ox와 oy가 같은 객체를 참조하고 있으면 테스트를 통과 -         assertNotSame(ox, oy) : ox와 oy가 같은 객체를 참조하고 있지 않으면 통과 5. JUnit Test • 테스트 케이스 클래스에 테스트 케이스를 만듭니다. • 테스트 케이스 클래스가 에디터 패널이나 Package Explorer 뷰에서 선택하고 메뉴에서 Run>Run As>JUnit Test를 선택합니다. • 왼쪽 탭 뷰에 JUnit뷰가 추가 되었으며 모든 유닛 테스트에 성공적으로 통과하면 막대는 녹색으로 나타나고 테스트에 실패하면 붉은색으로 나타나며, Failure 탭은 실패한 테스트의 목록을 보여줍니다.

출처 : Tong - babossun님의 JUnit통

Visual Studio .NET と Visual SourceSafe を使用したチーム開発

Visual SourceSafe を使用した作業

.NET による分散アプリケーションの構築

Microsoft Corporation

January 2002
日本語版最終更新日 2002 年 12 月 11 日

概要 : この章では、ソリューションやプロジェクトを Visual SourceSafe に追加する方法、VSS からソリューションを取得する方法、および毎日ファイルをチェックインおよびチェックアウトする方法など、共通の開発作業全体の一連の順を追った手順を提供します。この章により、必要な作業の速度が上ります。

これは、「Visual Studio® .NET と Visual SourceSafe™ を使用したチーム開発ガイド」の第 6 章です。全容を理解するには、こちらをご覧ください。

この章は、以下の開発作業を実行するために、 Microsoft® Visual Studio® .NET が提供する統合ソース管理機能を使用して作業する場合に役立ちます。

• ソリューションとプロジェクトの作成
• 既存のソリューションおよびプロジェクトを使用する作業
• 既存のソリューションへの新しいプロジェクトの追加
• Microsoft Visual SourceSafe™ (VSS) のソース ファイルのチェックイン
• プロジェクト、ファイル、およびフォルダの名前の変更と削除

この章では、日常的に行われる一般的な作業のガイドとなる一連の処理を簡単なウォークスルーで紹介します。

注意    この章で説明する手順は、Visual SourceSafe Version 6.0c に適用されます。

Visual Studio .NET は完全に統合された VSS サポートを提供します。Visual Studio .NET は各種 .NET プロジェクトを構成するさまざまな種類のファイルを認識しますので、日常的にプロジェクトやファイルを VSS にチェックイン、またはチェックアウトするときには Visual Studio .NET の使用が不可欠です。ソース管理で自動的に適切なファイルを管理する一方で、ユーザー固有のファイルには影響を与えません。また Visual Studio .NET のソース管理機能は、Visual Studio .NET ソリューション ファイルとプロジェクト ファイルに特定の情報を追加します。VSS エクスプローラを直接使用する場合、この機能は使用されません。

図 6.1 に、開発プロセスのおおまかな概要と、VSS との対話処理で実行する必要のある一般的な 4 つの作業を示します。

図 6.1. VSS との対話処理

図 6.1 に示したように、開発者が定期的に実行する基本的な作業は 4 つあります。以下の作業が必要になります。

• 新しいソリューションとプロジェクトを作成し、VSS に追加します。
• 既存のソリューションで 1 回目の作業を行います。
• 以前に作業した既存のソリューションで作業します。
• 既存のソリューションに新しいプロジェクトを追加します。

この章では、上記のそれぞれの作業方法以外に、ソース管理を行っている VSS プロジェクト内のプロジェクト、ファイル、およびフォルダの名前の変更や、多重チェックアウト モードでの VSS の使用など、ときどき必要になることがある他の作業の実行方法について説明します。

新しいソリューションやプロジェクトの作成

ここでは、最初からプロジェクトを 1 つ含む新しいソリューションを作成して、このソリューションとプロジェクトを VSS に追加する状況を想定します。 Web プロジェクトと Web 以外の種類のプロジェクトの作成処理、および推奨するフォルダ構造を採用する処理については、第 3 章「ソリューションとプロジェクトの構造化」で説明しています。以下の手順は、指定の構造に従ってソリューションとプロジェクトを作成したことを前提としています。

注意    各プロジェクト ファイルは、ソリューション内でそのプロジェクトを一意に識別する GUID (グローバル一意識別子) を持っています。このため、既存のプロジェクト ファイルをコピーしたり、名前を変更して新しいプロジェクトを作成しないでください。同一の GUID が共有され、 Visual Studio .NET が互いを区別できなくなります。両方のプロジェクトを同じソリューションに含めた場合には問題が発生します。

新しいソリューションを VSS にチェックインする方法

Visual Studio .NET を使用して新しいソリューション ファイルやプロジェクト ファイルを作成した後、および初期開発を終えたときに、そのソリューションとプロジェクトを VSS にチェックインする必要があります。

新しいソリューションをソース管理に追加するには

1. [ファイル] メニューの [ソース管理] をポイントし、 [ソリューションをソース管理に追加] をクリックします。 ASP.NET Web アプリケーションを VSS に追加する場合は、次のソース管理メッセージ ボックスが表示されます。

   

2. [今後このダイアログ ボックスを表示しない] チェック ボックスをオンにして、 [続行] をクリックしてこのダイアログ ボックスを閉じます。
3. ここで VSS ログイン ダイアログ ボックスが表示される場合があります。これは VSS 管理者がネットワーク ユーザーの自動ログインを使用するように VSS を構成していない場合にのみ表示されます。 VSS ユーザー名を入力して、[参照] をクリックし、 VSS サーバーの VSS データベースに移動します。 VSS サーバーのファイル共有で開発データベースを識別する Srcsafe.ini ファイルを選択します。

   注意 : ネットワーク ユーザーの自動ログインが構成されている場合、 VSS ログイン ダイアログ ボックスは表示されません。この場合に VSS データベースを変更するには、 VSS エクスプローラを実行して [ファイル] メニューの [データベースを開く] をクリックします。そこで 適切な Srcsafe.ini ファイルを参照します。

4. 現在作業しているシステムの名前を示す有効なデータベース名を入力できます。 [開く] をクリックして [OK] をクリックし、データベースに接続します。
5. [Visual SourceSafe に追加] ダイアログ ボックスで、[プロジェクト] を展開し、システム名を選択します。
6. [作成] をクリックします。このソリューション ファイル専用の VSS プロジェクト フォルダが作成されます。 VSS フォルダは Visual Studio .NET ソリューションと同じ名前になります。
7. [OK] をクリックします。
8. 重要 : ASP.NET Web アプリケーションを VSS に追加している場合、それぞれの Visual Studio .NET プロジェクトを VSS に追加するかどうかを確認するメッセージが表示されます。 Web アプリケーションの場合にのみ、以下の手順に従います (以下の 2 つの手順は Web アプリケーション以外では必要ありません)。
   1. [プロジェクト] を展開し、システム名を展開して、ソリューション名をクリックします。 [OK] をクリックします。
   2. プロジェクトを格納する新しい VSS フォルダを作成するかどうかを確認するメッセージが表示されます。 [はい] をクリックして新しいフォルダを作成します。ソリューション内のすべての Web プロジェクトに対してこの処理を繰り返します。

これで VSS のソース管理でソリューション ファイル、プロジェクト ファイル、およびソース ファイルが管理されるようになりました。ソリューション エクスプローラ ウィンドウ内の VSS に追加したすべてのファイルの横に錠前マークが表示されます。この表示は、ファイルが現在 VSS 内でロックされていることを示します。ローカルで作業中のフォルダには読み取り専用属性が割り当てられ、ファイルを VSS からチェックアウトするまでは作業できないようになっています。

編集時にチェックアウト

その後、ロックされているファイルを編集するために開くと、 Visual Studio .NET には編集時に自動的にチェックアウトする機能があり、ファイルをチェックアウトするかどうかを確認するメッセージを表示します。引き続きファイルを編集する場合、 [編集時にチェックアウト] ダイアログ ボックスの [チェックアウト] をクリックします。ファイルが自動的にチェックアウトされます。その後でソリューション エクスプローラのファイルを右クリックして [チェックイン] をクリックすると、 VSS にファイルをチェックインできます。

既存のソリューションを使用する 1 回目の作業

ここでは、チームの別のメンバがソリューションを作成して VSS に追加した状況を想定します。そのソリューションに含まれているプロジェクトの 1 つで作業するために、最初にソリューションを取得する必要があります。

VSS から既存のソリューションを取得するには

1. Visual Studio .NET を起動します。
2. [ファイル] メニューの [ソース管理] をポイントし、 [ソース管理で開く] をクリックします。 VSS ログイン ダイアログ ボックスが表示されます。
3. VSS ユーザー名を入力し、 [参照] をクリックして VSS サーバーの VSS データベースに移動します。 VSS サーバーのファイル共有上で開発データベースを識別する Srcsafe.ini を選択します。このデータベースに以前接続したことがあり、 [次回の起動時にこのデータベースを開く] チェック ボックスをオンにしている場合は、自動的にデータベースが選択されます。
4. [OK] をクリックしてデータベースに接続します。 [プロジェクトからデータベースを作成] ダイアログ ボックスが表示されます。
5. [プロジェクト] を展開し、システム名のフォルダを展開後、取得するソリューションをクリックします。 [フォルダに移動して新しいプロジェクトを作成する] エディット ボックスに、「\Projects\SystemName\SolutionName」と入力します。 "SolutionName" は対象のソリューションの名前です。この結果、適切なローカル ファイル システム構造を持つことを確実にします。
6. [OK] をクリックします。ローカル ソリューション フォルダが存在しない場合、作成するかどうかを確認するメッセージが表示されます。 [すべてはい] をクリックするとソリューション フォルダが作成されます。 Web アプリケーション以外の場合は、プロジェクトのサブフォルダも作成されます。
7. ASP.NET Web アプリケーションの場合は、 [プロジェクト フォルダの設定] ダイアログ ボックスが表示されるので、 Web アプリケーションの作業場所を入力します。ここで Web アプリケーションの仮想ルートへのパスを識別する URL を指定できます。既定では Visual Studio .NET は http://localhost/<projectname> を想定しています。 [OK] をクリックして既定の場所を受け入れた場合、新しい仮想ルートは既定の Web サイトの下に作成されます (通常は \Inetpub\wwwroot です)。チーム環境で作業を行う場合は、アプリケーションをローカルに作成する場合であってもこの場所をお勧めしません。ソリューション フォルダの下のプロジェクト サブフォルダに仮想ルートを作成するには、以下の手順を実行後、[OK] をクリックして [プロジェクト フォルダの設定] ダイアログ ボックスの内容を受け入れます。
   1. Microsoft Windows エクスプローラを使用して、 \Projects\SystemName\SolutionName に作成されたソリューション フォルダの下に、プロジェクト サブフォルダを作成します。このサブフォルダの名前にはプロジェクト名を使用します。
   2. エクスプローラか Microsoft Internet Information Services (IIS) を使用して、このフォルダを IIS の仮想ルートとして設定します。
   3. Visual Studio .NET に戻り、作業場所として「http://localhost/projectname/」と入力します。

      重要 : 既存の URL (Uniform Resource Locator) を上書き入力して変更する必要があります。変更しないと、ダイアログ ボックスは依然として \inetpub\wwwroot の下のフォルダにアドレスをマッピングするよう認識します。

   4. [OK] をクリックして [プロジェクト フォルダの設定] ダイアログ ボックスを閉じます。プロジェクト ファイルと Web アプリケーション ファイルは、ソリューション フォルダの 1 階層下のサブフォルダにマッピングされた仮想ルートに配置されます。
8. ソリューション ファイル、プロジェクト ファイル、ソース ファイルがハード ディスクにダウンロードされます。ただし、VSS でロックされたままであることに注意してください。ソリューション エクスプローラの各ファイルの横に表示された錠前マークからこのことを確認できます。
9. ソリューション エクスプローラで、 1 つ以上のファイルを右クリックして選択し [チェックアウト] をクリックできます。または Visual Studio の編集時にチェックアウト機能がファイルをチェックアウトする必要があるときに自動的にメッセージを表示するので、単純にソース ファイルの編集を開始することもできます。
10. ローカルでの開発が完了後、各ファイルを個別にチェックインするか、または IDE (統合開発環境) の [保留中のチェックイン] ウィンドウを使用できます。このウィンドウが表示されない場合、[表示] メニューの [保留中のチェックイン] をクリックする必要があります。

注意    ファイルをチェックインせずにソリューションを終了すると、メッセージは表示されません。作業者の名前でチェックアウトされたままになります。

既存のソリューションを使用する 2 回目以降の作業

ここでは、以前に 1 回以上作業したソース管理されている既存のソリューションで作業する状況を想定します。ローカル ファイル システムには、以前の作業時に作成されたソリューション フォルダとプロジェクト フォルダが存在します。この中には、読み取り専用のソリューション ファイルとプロジェクト ファイルが含まれています。

VSS から既存のソリューションを取得するには

1. Visual Studio .NET を起動します。
2. 必要なソリューションがスタート ページに表示されている場合はクリックします。表示されていない場合は、ローカル ファイル システムのソリューション (.sln) ファイルを参照してソリューションを開きます。
3. 最新のプロジェクト ファイルを取得するには、ソリューション エクスプローラでソリューションを右クリックして、[最新バージョンを取得 (再帰)] をクリックします。

重要    以前に VSS から取得している既存のソリューションで作業するときは、ローカル ソリューション ファイルを開く必要があります。その場合は [ソース管理で開く] メニューを使用しないでください。使用した場合、Visual Studio .NET がローカル ソリューション ファイルとプロジェクト ファイルの存在を検出して、ファイルの上書きを確認するメッセージが表示されます。また、ファイルを 1 つでもチェックアウトしている場合、ローカル ファイルを VSS からのファイルに置き換えるか、またはローカル ファイルをそのまま開くか問い合わせるメッセージが表示されます。ローカル ソリューション ファイルを開く方が単純で、エラーの発生が少なくなります。

既存のソリューションへの新しいプロジェクトの追加

ここでは、既存のソリューションに新しいプロジェクトを追加する状況を想定します。以下の手順は、ソリューションを VSS から上記の説明どおりに取得していることを想定しています。

新しいプロジェクトを追加して VSS に追加するには

1. [ファイル] メニューの [プロジェクトの追加] をポイントし、 [新しいプロジェクト] をクリックします。
2. 適切なプロジェクトの種類とテンプレートを選択し、プロジェクト名を入力します。
3. ASP.NET Web プロジェクトの場合は、手作業でソリューション フォルダの下にプロジェクト サブフォルダを作成し、 IIS 仮想ルートとしてマークする必要があります。 Web アプリケーション以外の場合、新しいプロジェクト フォルダの場所は既定でソリューション フォルダの 1 レベル下になります。
4. [OK] をクリックします。 Visual Studio .NET は新しいプロジェクトの詳細をソリューション ファイルに追加する必要があるので、 (チェックアウトがまだの場合は) ファイルをチェックアウトするかどうかを確認するメッセージが自動的に表示されます。
5. [チェックアウト] をクリックします。新しいプロジェクトがソリューションに追加され、ソリューション エクスプローラに表示されます。なお、新しいプロジェクトの各ファイルの横には時計のマークが表示されます。このマークは、ファイルのロックが解除されていて、編集用に利用できることを示します。
6. 新しいプロジェクト ファイルを使用した初期開発作業の終了後に、ファイルを VSS にチェックインする必要があります。 (新しいプロジェクトを含めた) ソリューション全体を VSS に戻すには、ソリューション エクスプローラでソリューションを右クリックし、[チェックイン] をクリックします。
7. [チェックイン] ダイアログ ボックスに、現在チェックアウトされているすべてのファイルが表示されます。この中には新しいプロジェクト ファイルとソース ファイルが含まれています。すべてのファイルをチェックインするには、[チェックイン] をクリックします。

VSS へのソース ファイルのチェックイン

ソリューションとプロジェクトが VSS に存在する場合は、更新したファイルだけをチェックインする必要があります。これは、ソリューション エクスプローラで個別のファイルを右クリックして、 [チェックイン] をクリックすると実行できます。または、IDE の最下部に表示される [保留中のチェックイン] ページを使用して、チェックインする必要があるすべてのファイルの一覧を参照できます。このページを使用すると複数のファイルを簡単にチェックインできます。

ビルドの準備が整ったときのみファイルをチェックイン

通常 VSS にプロジェクトとファイルをチェックインするのは、単体テストを完了して、同僚のチーム メンバが他のプロジェクトに対し行った更新と共にビルドするときに、統合による問題が発生する可能性が低い場合に限ります。

重要    これは、一部のファイルを数日間 VSS にチェックインしないことになります。したがって、すべての開発用ワークステーションに対して十分なバックアップ作業が毎日適切に行われるようにしてください。

注意    昇格レベルの概念をネイティブにサポートする変更管理システムを使用して作業する場合は、現在の完成度とは無関係に、定期的にファイルをチェックインしたほうが良い場合があります。昇格レベルをサポートする変更管理システムは、通常特にこの目的での初期 "開発" レベルを提供します。ビルド プロセスはこのレベルからはソース ファイルを抽出しません。 "統合" など、高い昇格レベルに関連付けられているソース ファイルを使用して機能します。開発者やビルド コーディネータは、システム ビルド全体でファイルを統合する準備が整ったときのみファイルをこのレベルに昇格します。

ファイルとフォルダの名前の変更と削除

場合によっては、ソース管理 VSS プロジェクト内に存在する個別のファイルやフォルダの名前を変更したり、削除する必要があります。削除や名前の変更を Visual Studio .NET IDE で行っても自動的には VSS に反映されません。その逆も同じです。したがって、Visual Studio .NET と組み合わせて VSS エクスプローラを使用する必要があります。

ファイル名の変更

以下の手順は、Visual Studio .NET プロジェクト内のファイル名を変更する方法を説明しています。

Visual Studio .NET プロジェクトに含まれる既存ファイルの名前を変更するには

1. VSS エクスプローラを使用して、名前を変更するファイルがチェックアウトされていないことを確認します。
2. VSS エクスプローラを使用して、ファイル名を変更します。
3. Visual Studio .NET を使用して、ファイル名を変更するプロジェクトを含むソリューションを開きます。ソリューション エクスプローラに、VSS で名前を変更したファイルがチェックアウトされていると表示されます。既に Visual Studio .NET にプロジェクトを読み込んでいる場合、ソリューション エクスプローラでプロジェクト ファイルを右クリックし、 [最新バージョンを取得 (再帰)] をクリックします。
4. ソリューション エクスプローラでファイルを右クリックし、 [名前の変更] をクリックします。ファイル名は VSS での新しい名前と一致するように変更します。
5. プロジェクト ファイルはファイルの一覧が保持されているので、チェックアウトするかどうかを確認するメッセージが表示されます。 [編集時にチェックアウト] ダイアログ ボックスで [チェックアウト] をクリックします。
6. ソース管理メッセージ ボックスで、 [変更点を反映して継続] をクリックします。
7. ソリューション エクスプローラに、ファイルがロックされていると表示されます。プロジェクト ファイルを VSS にチェックインします。

プロジェクト名の変更

第 3 章「ソリューションとプロジェクトの構成」の「名前付け規則を慎重に検討する」で説明したように、プロジェクト名を変更するときは、一貫した命名規則に従って以下の項目の名前を変更する必要があります。

• Visual Studio .NET プロジェクト ファイル
• プロジェクト ファイルを保持するローカル ファイル システム フォルダ
• VSS プロジェクト フォルダ
• 出力アセンブリ名
• プロジェクトのルート名前空間

プロジェクト名を変更するには

1. プロジェクト ファイル、そのプロジェクト ファイルを保持するソリューション ファイル、およびプロジェクト内のすべてのファイルがチェックアウトされていないことを確認します。
2. ソリューション ファイルをチェックアウトします。 Visual Studio .NET ソリューション エクスプローラでソリューションを右クリックし、 [チェックアウト] をクリックします。 [チェックアウト] ダイアログ ボックスでソリューション ファイルのみが選択されている (プロジェクト ファイルが選択されていない) ことを確認し、 [チェックアウト] をクリックします。
3. ここで、VSS データベースからプロジェクトをバインド解除する必要があります。 Visual Studio .NET で、[ファイル] メニューの [ソース管理] をポイントして、 [ソース管理の変更] をクリックします。
4. 名前を変更するプロジェクトを選択し (このとき自動的にソリューションも選択される場合があります)、 [バインドの解除] をクリックします。[ソース管理の変更] メッセージ ボックスが表示されるので、 [バインドの解除] をクリックします。
5. [OK] をクリックして [ソース管理の変更] ダイアログ ボックスを閉じます。プロジェクト ファイルは (多くの場合ソリューション ファイルも) VSS データベースとのバインドが解除されます。
6. ソリューション エクスプローラで、名前を変更するプロジェクトを右クリックし、 [名前の変更] をクリックします。新しいプロジェクト名を入力します。
7. [ファイル] メニューの [すべて保存] をクリックします。ローカル ソリューション ファイルが更新されます。
8. ローカル プロジェクト フォルダの名前を変更できるようにするため、ここでプロジェクトをソリューションから一時的に削除する必要があります。ソリューション エクスプローラで、名前を変更するプロジェクトを右クリックし、[削除] をクリックします。 [Microsoft Development Environment] メッセージ ボックスが表示されるので、[OK] をクリックします。
9. エクスプローラを使用して、変更後のプロジェクト ファイル名と一致するようにローカル ファイル システムのプロジェクト フォルダの名前を変更します。
10. Web アプリケーション名を変更する場合、エクスプローラか IIS を使用して、名前を変更したフォルダを IIS の仮想ルートとして確立します。メモ帳を使用してプロジェクト フォルダの .webinfo ファイルを編集し、 URLPath 属性がプロジェクトの新しい仮想ルート フォルダを指すように設定します。
11. Visual Studio .NET に戻ります。ソリューション エクスプローラのソリューション ファイルを右クリックし、[追加] をポイントして [既存のプロジェクト] をクリックします。名前を変更したローカル プロジェクト フォルダを参照し、名前を変更したプロジェクト ファイルを選択して、[開く] をクリックします。
12. VSS エクスプローラを使用して、変更後のプロジェクト名と一致するように VSS プロジェクトの名前を変更します。
13. これでプロジェクトを VSS データベースに再バインドできるようになります。 Visual Studio .NET に戻り、[ファイル] メニューの [ソース管理] をポイントし、[ソース管理の変更] をクリックします。
14. ソリューション ファイルが現在バインド解除されている場合、 [ソース管理の変更] でファイルをクリックして [バインド] をクリックします。このとき、VSS へのログインが必要な場合があります。 VSS のソリューション フォルダに移動してフォルダをクリックし、[OK] をクリックします。
15. [ソース管理の変更] ダイアログ ボックスで、名前を変更したプロジェクトをクリックし、 [バインド] をクリックします。必要に応じて VSS にログインします。
16. VSS で、名前を変更したプロジェクト フォルダに移動し、フォルダをクリックして [OK] をクリックします。
17. [OK] をクリックして [ソース管理の変更] ダイアログ ボックスを閉じます。 [ソース管理] メッセージ ボックスが表示されるので [OK] をクリックします。
18. [保留中のチェックイン] ウィンドウを使用して、ソリューションと、名前を変更したプロジェクトを VSS にチェックインします。
19. ここで、該当するソース ファイルをチェックアウトし、ルート名前空間をプロジェクト名と一致するように更新する必要があります。
20. プロジェクト ファイルをチェックアウトし、プロジェクト プロパティを更新する必要もあります。更新するプロパティは出力 DLL (ダイナミック リンク ライブラリ) や実行可能ファイルの名前を制御する Assembly Name などです。また、C# プロジェクトの場合は Default Namespace を、 Microsoft Visual Basic® .NET プロジェクトの場合は Root Namespace を更新します。この 2 つは新しい種類を追加する既定の名前空間を管理します。

古いプロジェクト ファイルを整理するには

古いプロジェクト ファイル、関連するソース管理メタデータ ファイル、および Web アプリケーションの場合の Web サービス ダイナミック探索ファイルは、名前を変更した VSS プロジェクト フォルダに残存し、ローカル ファイル システムの名前を変更したプロジェクト フォルダにも残存します。このようなアイテムは削除して整理する必要があります。

1. VSS エクスプローラを使用して、名前を変更したプロジェクト フォルダから古いプロジェクト ファイル (*.csproj.proj)、古い Visual Studio ソース管理プロジェクト メタデータ ファイル (*.csproj.vspcc)、および Web アプリケーションの場合の古い Web サービス ダイナミック探索ファイル (*.vsdisco) を削除します。VSS で新しいプロジェクト ファイルが表示されるように、表示を最新状態に更新する必要がある場合があります。
2. エクスプローラを使用して、ローカルに名前を変更したファイル システム プロジェクト フォルダから、古い Visual Studio ソース管理プロジェクト メタデータ ファイル (*.csproj.vspcc) と、Web アプリケーションの場合の古い Web サービス ダイナミック探索ファイル (*.vsdicso) を削除します。なお、これらのファイルはローカル ファイル システムでは読み取り専用です。
3. Web アプリケーションの場合は、IIS を使用して名前を変更した古い仮想ルートを削除します。

VSS からのファイル削除

以下の手順は、プロジェクトを 1 つ以上含む VSS のソリューションを開いていて、プロジェクトに削除するファイルが含まれていることを前提としています。

ファイルを削除するには

1. 削除するファイルがチェックアウトされていないことを確認します。
2. ソリューション エクスプローラで、削除するファイルを右クリックし、 [チェックアウト] をクリックします。
3. [チェックアウト] の構成確認ダイアログ ボックスで、[チェックアウト] をクリックします。既に第三者がファイルをチェックアウトしている場合、ファイルを排他的に利用できるようになるまで待機する必要があります。
4. ソリューション エクスプローラで、ファイルを右クリックし、[削除] をクリックします。
5. ファイルを完全に削除するかどうかを確認する [Microsoft Development Environment] メッセージ ボックスが表示されるので、[OK] をクリックします。
6. プロジェクト ファイルはファイルの一覧が保持されているので、チェックアウトするかどうかを確認するメッセージが表示されます。 [編集時にチェックアウト] ダイアログ ボックスで [チェックアウト] をクリックします。
7. VSS にプロジェクト ファイルをチェックインします。
8. VSS エクスプローラを使用して、 VSS データベースから (チェックアウトの表示になっている) ファイルを削除します。 [Microsoft Visual SourceSafe] メッセージ ボックスが表示されるので、[はい] をクリックしてファイルの削除を確認します。

VSS からのプロジェクトの削除

以下の手順で、VSS からプロジェクトを削除する方法を説明します。

VSS からプロジェクトを削除するには

1. ソリューション エクスプローラで、削除するプロジェクトを右クリックし、[削除] をクリックします。
2. [Microsoft Development Environment] メッセージ ボックスで確認されるので、[OK] をクリックします。
3. ソリューション ファイルはプロジェクトの一覧が保持されているので、チェックアウトするかどうかを確認するメッセージが表示されます。 [編集時にチェックアウト] ダイアログ ボックスで、[チェックアウト] をクリックします。
4. ソリューションを VSS にチェックインします。
5. VSS エクスプローラを使用して、VSS データベースからプロジェクトを削除します。
6. ローカル ハード ディスクからプロジェクト フォルダを削除します。 Web アプリケーションの場合は、IIS を使用して対応する仮想ルートも削除します。

VSS からのソリューションの削除

以下の手順で、VSS からソリューションを削除する方法を説明します。

VSS からソリューション (と内部の全プロジェクト) を削除するには

1. VSS エクスプローラで、ソリューション ファイル、すべてのサブプロジェクト、およびプロジェクト ファイルがいずれもチェックアウトされていないことを確認します。
2. VSS エクスプローラを使用して、 VSS からソリューションを削除します。
3. ローカル ハード ディスクからソリューションを削除します。

注意    削除しようとしていることを他のチーム メンバに連絡して、メンバが現在 Visual Studio .NET にソリューションを読み込んでいる場合にアンロードできるようにする必要があります。削除時にチーム メンバがソリューションを (チェックアウトせずに) 読み込んでいる場合、削除後にソリューションに含まれていたファイルをチェックアウトしようとすると、VSS エラーが発生します。

多重チェックアウト

通常は、VSS からファイルをチェックアウトできるのは一度に 1 人のユーザーだけです。しかし、VSS 管理ツールを使用すると、複数のユーザーが同一のファイルを同時にチェックアウトできるように VSS を構成できます。

多重チェックアウトは、プロジェクト ファイルなど頻繁にアクセスするファイルでの競合回避に役立つので、チーム環境で使用すると有益な場合があります。ただし、この機能を使用する場合、チームのそれぞれのメンバどうしで入念な調整を行う必要があり、 VSS にファイルをチェックインするときに変更が正しくマージされるよう配慮する必要があります。

多重チェックアウト モードのファイルを使って作業するには

1. ソリューション エクスプローラを使用して必要なファイルをチェックアウトします。他のユーザーがファイルをチェックアウトしていることが Visual Studio .NET から警告されます。 [Microsoft Visual SourceSafe] メッセージ ボックスが表示されるので、[はい] をクリックします。
2. ファイルのコピーを変更し、プロジェクトをコンパイルして単体テストを行います。
3. ファイルをチェックインする前に、他の開発者による変更部分をマージし、ローカルで結合してテストする必要があります。これを行うには、ソリューション エクスプローラでファイルを右クリックし、 [最新バージョンの取得] をクリックします。 [Microsoft Visual SourceSafe] メッセージ ボックスが表示されるので、[マージ] をクリックします。 VSS が自動的に VSS のファイルとローカルで作業中のコピーをマージします。マージ後のファイルはコンパイルしてテストできます。
4. テスト終了後、Visual Studio .NET を使用してファイルを VSS にチェックインします。ファイルがマージ済みの場合、VSS は競合がすべて正しく解決されているかチェックするかどうかを確認するメッセージを表示します。メッセージに対し [はい] をクリックすると、ファイルは VSS にチェックインされます。

ソリューション ファイルのチェックアウト

ソリューション ファイルは、マージ処理を困難にし、エラーを発生しやすくする要素であるプロジェクト グループを含んでいるので、同時チェックアウトが特に困難です。他の開発者が既にソリューション ファイルをチェックアウトしている場合は、通常はファイルをチェックアウトしないようにする必要があります。

多重チェックアウトを避ける以外にも、ソリューション ファイルの競合を減らすため、(たとえば、新しいプロジェクトの追加などは) 一度に短時間のチェックアウトを心掛けます。競合が発生した場合は他の開発者と調整し、ソリューション ファイルが排他的に利用できるようになるまで待機してからチェックアウトします。

関連情報

多重チェックアウトの詳細については、「http://www.microsoft.com/japan/msdn/library/ja/guides/html/vstskCheck_Out_Multiple_Files.asp」 を参照してください。

これは、「Visual Studio .NET と Visual SourceSafe を使用したチーム開発ガイド」の第 6 章です。続いて、第 7 章「チーム環境のセットアップと管理」を参照してください。

JUnit 테스트 사례 작성

이제까지 자신이 구현한 IsoDate가 잘 만들어졌는지를 확인해 보기 위한 테스트 클래스 소스를 살펴 보았습니다. 그러면 이제 그러한 테스트 파일을 실제로 구현하는 것에 대해 살펴보기로 하겠습니다.

테스트는 JUnit 프레임워크의 이점을 이용할 수 있도록 JUnit.framework.TestCase로부터 값을 계승하며, 이 클래스 이름은 "Test"라는 말이 덧붙여진 테스트 클래스의 이름이 됩니다. 예를 들어 IsoDate라는 클래스를 테스트하고 있다면, 테스트 클래스 이름은 IsoDateTest가 됩니다. 일반적으로 이 클래스는 개인적인 것들 이외의 모든 메소드에 액세스 할 수 있도록, 테스트 클래스와 동일한 패키지에 들어 있습니다.

클래스 내에서 테스트할 각 메소드에 대한 메소드를 하나씩 작성해야 한다는 것에 유념하십시오. 예를 들어, ISO 데이타 형식을 사용하는 생성자나 메소드를 테스트할 경우에는, ISO 형식의 String을 인수로 하고 toString()을 메소드로 취하는 생성자에 대한 테스트 메소드를 작성해야 할 것입니다. 이름을 짓는 패턴은 테스트 사례의 경우와 유사합니다. 즉, 테스트된 메소드(또는 생성자)의 이름 앞에 "test"를 추가하기만 하면 됩니다.

테스트 메소드의 본문은 assertion을 검증함으로써 테스트 대상 메소드를 시험합니다. 예를 들어 toString() 실행에 대한 테스트 메소드에서 여러분은 초기 시작(UNIX 시스템이 탄생한 1970년 1월 1일 자정)이 메소드에 의해 잘 포맷되어있는지 검사하기를 원할 수 있습니다. 이 assertion을 실행하려면, 프레임워크가 제공하는 assertion 메소드를 사용하면 됩니다. 이들 메소드는 프레임워크의 JUnit.framework.Assert 클래스에서 실행할 수 있으며 테스트에서 액세스할 수 있는데, Assert가 TestCase의 부모 클래스이기 때문입니다. 이들 메소드는 assert Java 키워드(J2EE 1.4의 최신 버전)에 필적하는 것입니다. Assertion 메소드에는 기본 유형들 (부울, 정수 등) 사이의 동등성 또는 객체 사이의 동등성을 검사하는 (()equals 메소드를 사용하여 두 객체가 동일한 것인지 검사함) 메소드들이 있습니다. 다른 assertion 메소드는 두 객체의 동일성 여부를 검사합니다. 즉, 객체가 널(null)인지 아닌지, 그리고 (일반적으로 표현식에서 비롯되는) 부울이 참인지 거짓인지 등을 검사합니다. 이들 메소드는 표 1에 요약되어 있습니다.

부동(float)의 또는 이중 인수(double argument)로 작업하는 assertion에 대해서는, 비교에 허용되는 델타를 인수로 취하는 세 번째 메소드가 있습니다. assertEquals() 및 assertSame() 메소드는 일반적으로 동일한 결과를 만들어내지 않는다는 점에도 유의하십시오. (동일한 값을 가진 두 개의String 이라 할지라도, 서로 다른 메모리 주소를 가진 별개의 객체로서, 동일한 것이 아닐 수도 있습니다.) 그러므로, assertEquals() 는 assertion를 검증하는 반면, assertSame()은 그렇게 하지 못합니다. 표 1 의 각 assertion 메소드에 대해서는, assertion이 실패할 경우, 설명적인 메시지를 제공하는 다른 인수를 포함시킬 수 있습니다. 따라서, 예를 들자면 , assertEquals(int expected, int actual) 은 assertEquals(String Message, int expected, int actual)과 같은 메시지와 함께 사용될 수 있습니다.

Assertion이 실패할 경우, assertion 메소드는 AssertFailedError 이나 ComparisonFailure를 발생시킵니다. AssertionFailedError는 java.lang.Error로부터 계승되므로, 테스트 메소드의 throws 절에 이를 선언할 필요는 없습니다. ComparisonFailure 는 AssertionFailedError로부터 계승되므로, 이것 역시 선언할 필요가 없습니다. Assertion 실패 시 테스트 메소드에 오류가 발생하게 되므로, 후속 assertion은 수행되지 않습니다. 프레임워크는 이 오류들을 잡아낸 다음 테스트가 실패한 것으로 간주하여, 오류 메시지를 인쇄합니다. 이 메시지는 assertion으로부터 생성되어, (있을 경우) assertion 메소드에 전달됨으로써 완성됩니다.

메소드의 끝에 다음과 같은 행을 넣어 보겠습니다

assertEquals("This is a test",1,2);

Now compile the test and run it:

$ javac *.java
$ java junit.textui.TestRunner IsoDateTest
.F.
Time: 0,348

There was 1 failure:
1) testIsoDate(IsoDateTest)junit.framework
.AssertionFailedError: This is a test expected:<1> but was:<2>
      at IsoDateTest.testIsoDate
      (IsoDateTest.java:29)

FAILURES!!!
Tests run: 2,  Failures: 1,  Errors: 0

JUnit은 각각의 처리된 테스트를 위해 점을 인쇄해 주고 실패한 경우에는 F로 표시되고, 실패한 assertion을 위해 메시지를 표시합니다. 이 메시지는 assertion 메소드에 보내진 설명과 (자동으로 생성되는) assertion 결과로 구성됩니다. 여기에서는 assertion 메소드에 대한 인수의 순서가 생성된 메시지를 이해하는 데 매우 중요한 것임을 알 수 있습니다. 첫번 째 인수는 기대 값인 반면 두 번 째 것은 실제 값이기 때문입니다.

테스트용 메소드에 잘못(예를 들어 예외 발생 등)이 발견되면, 툴에 의해 (assertion 실패에서 비롯된 실패가 아니라) 오류로서 표시됩니다. 이제 IsoDateTest 클래스를 수정하여, 전에 추가했던 행을 다음 행으로 바꾸어 보겠습니다.

throw new Exception("This is a test"); 

이제 테스트를 컴파일하고 수행해 보겠습니다.

$ javac *.java

$ java junit.textui.TestRunner IsoDateTest 
.E.
Time: 0,284
There was 1 error:
1) testIsoDate(IsoDateTest)java.lang.
   Exception: This is a test at IsoDate
   Test.testIsoDate(IsoDateTest.java:30)

FAILURES!!!
Tests run: 2,  Failures: 0,  Errors: 1

툴은 예외를 오류로 표시하기 때문에, 오류는 테스트 실행이 손상되었다기 보다는 테스트 메소드가 손상되었음을 의미합니다.

Assert 클래스는 AssertionFailedError을 발생시켜 테스트 실행을 인터럽트하는, fail() 메소드 (그리고 설명 메시지가 있는 버전)을 포함하고 있습니다. 이 메소드는 Assertion 메소드 호출 없이 테스트 실패를 유도하려 할 때 유용하게 쓰입니다. 예를 들어, 하나의 코드가 예외를 발생시켜야 함에도 불구하고 그렇게 하지 않을 경우, 다음과 같이 fail() 메소드를 호출함으로써 테스트 실패를 유도할 수 있습니다.

public void testIndexOutOfBounds() {
  try {
       ArrayList list=new ArrayList();
       list.get(0);
       fail("IndexOutOfBoundsException   
           not thrown");
  } catch(IndexOutOfBoundsException e) {}
}

Junit의 고급 기능

샘플 테스트의 경우 여러분은 여러 테스트를 동시에 실행해 왔을 것입니다. 그러나 실제 상황에서는 구현 방식을 검사하기 위해 하나의 특정한 테스트 방법을 사용하는 것을 선호하기 때문에, 사용할 일련의 테스트를 정의할 필요가 있습니다. 이것이 junit.framework.TestSuite 프레임워크 클래스의 목적입니다. 이 프레임워크는 단순히 일련의 테스트를 추가할 수 있는 컨테이너에 불과합니다. toString() 구현을 위한 테스트 방법을 사용하고 싶다면 suite() 테스트 방법을 다음과 같이 덮어쓰십시오.

public static Test suite() {
  TestSuite suite= new TestSuite();
  suite.addTest(new IsoDateTest
("testToString"));
  return suite;
}

이 방법에서 TestSuite 객체는 인스턴스화가 가능하며 이 객체에 대한 여러 테스트가 추가적으로 이루어질 수 있습니다. 방법 단계에서 테스트를 정의하기 위해, 실시할 방법명을 매개변수로 채택하는 구성자를 이용 함으로써 테스트 클래스는 인스턴스화 됩니다. 이 구성자는 다음과 같이 실행됩니다.

public IsoDateTest(String name) {
  super(name);
}

위에 나와 있는 구성자와 메소드를 IsoDateTest 클래스에 추가하고 (또한 junit.framework.Test와 junit.framework.TestSuite를 임포트할 필요가 있을 수 있습니다), 터미널을 입력합니다.

 
$ javac *.java
$ java junit.textui.TestRunner IsoDateTest
.
Time: 0,31
OK (1 test)

테스트 스위트에 추가된 유일한 테스트 메소드가 toString()인 점을 주목하십시오.
그래픽 인터페이스를 이용한 특정 테스트 메소드는 그림 3에 예시된 것처럼 테스트 Hierarchy 패널에서 선택함으로써 사용할 수 있습니다. 그러나 이 스위트는 전체 테스트 스위트가 한번 실시되면 √로 채워집니다.

TestSuite 객체에 한 테스트 사례의 모든 메소드를 추가하고자 하는 경우, 이를 위한 전용 생성자가 있습니다. 이 생성자는 테스트 사례의 class 객체를 인수로 채택합니다. 예를 들어, IsoDateTest 클래스를 이용하여 suite() 메소드를 다음과 같이 실행할 수 있습니다.

public static Test suite() {
  return new TestSuite(IsoDateTest.class);
}

한 제품을 출시하기 전에 그 제품에 대해 실시되는 모든 테스트와 같이 다른 테스트들로 구성된 일련의 테스트를 실시하고자 하는 경우에는, 원하는 테스트 스위트를 구성하는 suite() 방법을 구현할 클래스를 써야 합니다. 예를 들어 테스트 클래스 Atest 와 Btest를 쓰는 것에 대해 생각해 봅시다. 클래스 ATest의 모든 테스트를 포함하는 테스트 모음과 Btest라고 규정된 테스트 스위트를 정의하기 위해 다음과 같이 클래스를 쓸 수 있습니다.

import junit.framework.*;

/**
 * TestSuite that runs all tests.
 */
public class AllTests {

  public static Test suite() {
     TestSuite suite= new TestSuite("All Tests");
     suite.addTestSuite(ATest.class);
     suite.addTest(BTest.suite());
     return suite;
  }
}

마치 하나의 테스트 사례를 실시하는 것처럼 정확하게 이러한 테스트 스위트를 실시할 수 있습니다. 테스트가 한 테스트 스위트에 두 번 추가된다면 테스트 실행기는 그 테스트를 두 번 실행합니다. (테스트 스위트나 테스트 실행기 중 어떤 것도 테스트가 유일함을 확인하지 못합니다.) 실제 상황에서의 테스트 스위트 실행 방법을 이해하려면, JUnit 테스트 스위트 자체를 살펴봐야 합니다. 그러한 클래스의 소스는 JUnit 설치 프로그램의 junit/tests디렉토리에 있습니다.

테스트 실행기를 사용하지 않고 테스트를 하기 위해서는 테스트나 테스트 스위트에 main()을 추가하는 것이 때로는 편리합니다. 예를 들어, 표준 Java프로그램으로서 AllTests 스위트를 실행하기 위해서는 클래스에 다음과 같은 main()을 추가하십시오.

public static void main(String[] args) {
  junit.textui.TestRunner.run(suite());

}

이제 여러분은 java AllTests를 입력함으로써 이러한 테스트 조를 실행할 수 있습니다.
이 프레임워크는 또한 리소스를 픽스처(Fixture)에 모음으로써 코드를 절약하는 방법을 제공합니다. 예를 들어 예제 테스트 사례는 epoch와 eon이라는 두개의 기준 날짜를 사용합니다. 이러한 날짜를 각 테스트 방법에 다시 구축하는 것은 (잠재적으로 실수하기 쉬운 프로세스일 뿐만 아니라) 시간 낭비일 수 있습니다. 목록 2에서 예시된 것처럼, 이러한 테스트는 픽스처(Fixture)로 다시 쓸 수 있습니다.
참조 날짜를 테스트 클래스의 필드로 정의하고 이를 setUp()에 구축합니다. 이 메소드는 각 테스트 메소드 이전에 호출됩니다. 반대 방법은 tearDown() 인데, 이 방법은 각 테스트 방법이 실행된 후 리소스를 정리합니다. 이 실행에서는 쓰레기 수집기(garbage collector)가 정리하는 일을 하기 때문에 이 메소드는 사실상 아무것도 하지 않습니다. 이제 이러한 테스트 사례를 컴파일하고 실행하되, 이러한 테스트 사례의 소스 코드는 JUnit의 설치 디렉토리에 넣어야 한다는 점을 주의하십시오.

$ javac *.java
$ java junit.textui.TestRunner IsoDateTest2
.setUp()
testIsoDate()
tearDown()
.setUp()
testToString()

tearDown()

Time: 0,373

OK (2 tests)

어떠한 테스트 방법에서 날짜를 수정하더라도 다른 테스트에 역효과를 주지 않도록 참조 날짜를 설정해야 합니다. 이러한 두 가지 방법에 코드를 넣어 데이타베이스 접속과 같은 각 테스트에 필요한 리소스를 설치하고 정리하도록 합니다.

JUnit 배포는 반복적인 테스트 실행과 같은 새로운 기능을 제공하는 테스트 데코레이터인, 확장자(패키지에서는 junit.extensions)와 함께 제공됩니다. 또한 이 배포는 별도의 스레드에서 동시에 모든 테스트를 실행하고 모든 스레드가 끝날 때 멈추는 TestSuite와도 함께 제공됩니다.


出所　－　http://www.oracle.com/global/kr/magazine/webcolumns/2003/o33junit_1.html