25.3. unittest —ユニットテストフレームワーク—Pythonドキュメント

25.3。 単体テスト —ユニットテストフレームワーク

バージョン2.1の新機能。

（テストの基本概念に既に精通している場合は、アサートメソッドのリストにスキップすることをお勧めします。）

「PyUnit」と呼ばれることもあるPythonユニットテストフレームワークは、KentBeckとErichGammaによるJUnitのPython言語バージョンです。 JUnitは、KentのSmalltalkテストフレームワークのJavaバージョンです。 それぞれが、それぞれの言語の事実上の標準ユニットテストフレームワークです。

unittest は、テストの自動化、テストのセットアップコードとシャットダウンコードの共有、テストのコレクションへの集約、およびレポートフレームワークからのテストの独立性をサポートします。 unittest モジュールは、一連のテストでこれらの品質を簡単にサポートできるようにするクラスを提供します。

これを実現するために、 unittest はいくつかの重要な概念をサポートしています。

テストフィクスチャ

テストフィクスチャは、1つ以上のテストを実行するために必要な準備、および関連するクリーンアップアクションを表します。 これには、たとえば、一時データベースまたはプロキシデータベース、ディレクトリの作成、またはサーバープロセスの開始が含まれる場合があります。

テストケース

テストケースは、テストの最小単位です。 特定の入力セットに対する特定の応答をチェックします。 unittest は、新しいテストケースを作成するために使用できる基本クラス TestCase を提供します。

テストスイート

テストスイートは、テストケース、テストスイート、またはその両方のコレクションです。 一緒に実行する必要があるテストを集約するために使用されます。

テストランナー

テストランナーは、テストの実行を調整し、ユーザーに結果を提供するコンポーネントです。 ランナーは、グラフィカルインターフェイス、テキストインターフェイスを使用するか、テストの実行結果を示す特別な値を返すことができます。

テストケースとテストフィクスチャの概念は、 TestCase および FunctionTestCase クラスを通じてサポートされています。 前者は新しいテストを作成するときに使用する必要があり、後者は既存のテストコードを unittest 駆動型フレームワークと統合するときに使用できます。 TestCase を使用してテストフィクスチャを構築する場合、 setUp（）および tearDown（）メソッドをオーバーライドして、フィクスチャの初期化とクリーンアップを提供できます。 FunctionTestCase を使用すると、これらの目的で既存の関数をコンストラクターに渡すことができます。 テストが実行されると、フィクスチャの初期化が最初に実行されます。 成功した場合、テストの結果に関係なく、テストの実行後にクリーンアップメソッドが実行されます。 TestCase の各インスタンスは、単一のテストメソッドを実行するためにのみ使用されるため、テストごとに新しいフィクスチャが作成されます。

テストスイートは、 TestSuite クラスによって実装されます。 このクラスを使用すると、個々のテストとテストスイートを集約できます。 スイートが実行されると、スイートに直接追加されたすべてのテストと「子」テストスイートが実行されます。

テストランナーは、 TestCase または TestSuite オブジェクトをパラメーターとして受け取り、結果オブジェクトを返す単一のメソッドrun()を提供するオブジェクトです。 クラス TestResult は、結果オブジェクトとして使用するために提供されています。 unittest は、デフォルトで標準エラーストリームのテスト結果を報告するテストランナーの例として TextTestRunner を提供します。 代替ランナーは、特定のクラスから派生する必要なしに、他の環境（グラフィカル環境など）に実装できます。

も参照してください

モジュール doctest

非常に異なるフレーバーを持つ別のテストサポートモジュール。

unittest2：Python2.4-2.6の新しいユニットテスト機能のバックポート

Python 2.7のユニットテストには、テスト検出など、多くの新機能が追加されました。 unittest2を使用すると、これらの機能を以前のバージョンのPythonで使用できます。

単純なSmalltalkテスト：パターンを使用

unittest によって共有されるパターンを使用したフレームワークのテストに関するKentBeckのオリジナルペーパー。

ノーズおよび pytest

テストを作成するためのより軽量な構文を備えたサードパーティの単体テストフレームワーク。 たとえば、assert func(10) == 42です。

Pythonテストツールの分類法

機能テストフレームワークやモックオブジェクトライブラリを含むPythonテストツールの広範なリスト。

Pythonメーリングリストでのテスト

Pythonでのテストおよびテストツールについて議論するための分科会。

25.3.1。 基本例

unittest モジュールは、テストを構築および実行するための豊富なツールセットを提供します。 このセクションでは、ほとんどのユーザーのニーズを満たすには、ツールの小さなサブセットで十分であることを示します。

3つの文字列メソッドをテストするための短いスクリプトを次に示します。

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

if __name__ == '__main__':
    unittest.main()

テストケースは、 unittest.TestCase をサブクラス化することによって作成されます。 3つの個別のテストは、名前が文字testで始まるメソッドで定義されます。 この命名規則は、どのメソッドがテストを表すかについてテストランナーに通知します。

各テストの要点は、 assertEqual（）を呼び出して、期待される結果を確認することです。 assertTrue（）または assertFalse（）を使用して、状態を確認します。 または assertRaises（）を使用して、特定の例外が発生したことを確認します。 これらのメソッドは、 assert ステートメントの代わりに使用されるため、テストランナーはすべてのテスト結果を蓄積してレポートを作成できます。

setUp（）および tearDown（）メソッドを使用すると、各テストメソッドの前後に実行される命令を定義できます。 これらについては、テストコードの整理のセクションで詳しく説明しています。

最後のブロックは、テストを実行する簡単な方法を示しています。 unittest.main（）は、テストスクリプトへのコマンドラインインターフェイスを提供します。 コマンドラインから実行すると、上記のスクリプトは次のような出力を生成します。

...
----------------------------------------------------------------------
Ran 3 tests in 0.000s

OK

unittest.main（）の代わりに、より細かいレベルの制御、より簡潔な出力、およびコマンドラインから実行する必要のないテストを実行する他の方法があります。 たとえば、最後の2行は次のように置き換えることができます。

suite = unittest.TestLoader().loadTestsFromTestCase(TestStringMethods)
unittest.TextTestRunner(verbosity=2).run(suite)

インタプリタまたは別のスクリプトから改訂されたスクリプトを実行すると、次の出力が生成されます。

test_isupper (__main__.TestStringMethods) ... ok
test_split (__main__.TestStringMethods) ... ok
test_upper (__main__.TestStringMethods) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK

上記の例は、最も一般的に使用される unittest 機能を示しています。これらの機能は、日常の多くのテストニーズを満たすのに十分です。 ドキュメントの残りの部分では、第一原理からの完全な機能セットについて説明します。

25.3.2。 コマンドラインインターフェイス

unittestモジュールは、コマンドラインから使用して、モジュール、クラス、または個々のテストメソッドからテストを実行できます。

python -m unittest test_module1 test_module2
python -m unittest test_module.TestClass
python -m unittest test_module.TestClass.test_method

モジュール名と完全修飾クラス名またはメソッド名の任意の組み合わせでリストを渡すことができます。

-vフラグを渡すことにより、より詳細な（より詳細な）テストを実行できます。

python -m unittest -v test_module

すべてのコマンドラインオプションのリストについては、以下を参照してください。

python -m unittest -h

バージョン2.7での変更：以前のバージョンでは、個々のテストメソッドのみを実行でき、モジュールやクラスは実行できませんでした。

25.3.2.1。 コマンドラインオプション

unittest は、次のコマンドラインオプションをサポートしています。

-b, --buffer

標準出力と標準エラーストリームは、テスト実行中にバッファリングされます。 合格テスト中の出力は破棄されます。 出力は、テストの失敗またはエラー時に通常どおりエコーされ、失敗メッセージに追加されます。

-c, --catch

テスト実行中の Control-C は、現在のテストが終了するのを待ってから、これまでのすべての結果を報告します。 2番目の Control-C は、通常のKeyboardInterrupt例外を発生させます。

この機能を提供する機能については、信号処理を参照してください。

-f, --failfast

最初のエラーまたは失敗でテストの実行を停止します。

バージョン2.7の新機能：コマンドラインオプション-b、-c、および-fが追加されました。

コマンドラインは、テストの検出、プロジェクト内のすべてのテストの実行、またはサブセットのみに使用することもできます。

25.3.3。 テストディスカバリー

バージョン2.7の新機能。

Unittestは、単純なテスト検出をサポートします。 テスト検出と互換性を持たせるには、すべてのテストファイルがプロジェクトの最上位ディレクトリからインポート可能なモジュールまたはパッケージである必要があります（つまり、ファイル名が有効である必要があります） 識別子）。

テスト検出は TestLoader.discover（）に実装されていますが、コマンドラインからも使用できます。 基本的なコマンドラインの使用法は次のとおりです。

cd project_directory
python -m unittest discover

discoverサブコマンドには次のオプションがあります。

-v, --verbose

冗長出力

-s, --start-directory directory

検出を開始するディレクトリ（.デフォルト）

-p, --pattern pattern

テストファイルに一致するパターン（test*.pyデフォルト）

-t, --top-level-directory directory

プロジェクトの最上位ディレクトリ（デフォルトは開始ディレクトリ）

-s 、 -p 、および -t オプションは、位置引数としてこの順序で渡すことができます。 次の2つのコマンドラインは同等です。

python -m unittest discover -s project_directory -p "*_test.py"
python -m unittest discover project_directory "*_test.py"

パスであるだけでなく、myproject.subpackage.testなどのパッケージ名を開始ディレクトリとして渡すこともできます。 指定したパッケージ名がインポートされ、ファイルシステム上のその場所が開始ディレクトリとして使用されます。

注意

テスト検出は、テストをインポートしてロードします。 テスト検出が開始ディレクトリからすべてのテストファイルを検出すると、指定したパスをパッケージ名に変換してインポートします。 たとえば、foo/bar/baz.pyはfoo.bar.bazとしてインポートされます。

パッケージがグローバルにインストールされていて、パッケージの別のコピーでテストディスカバリーを試行した場合、インポートは間違った場所から発生する可能性があります。 これが発生した場合、テスト検出は警告を表示して終了します。

開始ディレクトリをディレクトリへのパスではなくパッケージ名として指定した場合、discoverは、インポート元の場所が目的の場所であると想定するため、警告は表示されません。

テストモジュールとパッケージは、 load_testsプロトコルを介してテストのロードと検出をカスタマイズできます。

25.3.4。 テストコードの整理

単体テストの基本的な構成要素は、テストケースです。これは、セットアップして正しいかどうかを確認する必要がある単一のシナリオです。 unittest では、テストケースは unittest の TestCase クラスのインスタンスで表されます。 独自のテストケースを作成するには、 TestCase のサブクラスを作成するか、 FunctionTestCase を使用する必要があります。

TestCase から派生したクラスのインスタンスは、オプションのセットアップおよび整理コードとともに、単一のテストメソッドを完全に実行できるオブジェクトです。

TestCase インスタンスのテストコードは完全に自己完結型である必要があります。これにより、単独で、または他の任意の数のテストケースと任意に組み合わせて実行できます。

最も単純な TestCase サブクラスは、特定のテストコードを実行するために、runTest()メソッドをオーバーライドするだけです。

import unittest

class DefaultWidgetSizeTestCase(unittest.TestCase):
    def runTest(self):
        widget = Widget('The widget')
        self.assertEqual(widget.size(), (50, 50), 'incorrect default size')

何かをテストするために、 TestCase 基本クラスによって提供されるassert*()メソッドの1つを使用することに注意してください。 テストが失敗した場合、例外が発生し、 unittest はテストケースを失敗として識別します。 その他の例外はエラーとして扱われます。 これは、問題がどこにあるかを特定するのに役立ちます。障害は、誤った結果（6を期待していた5）が原因で発生します。 エラーは不正なコードが原因で発生します。たとえば、TypeErrorは不正な関数呼び出しが原因です。

テストケースを実行する方法については、後で説明します。 今のところ、そのようなテストケースのインスタンスを構築するために、引数なしでそのコンストラクターを呼び出すことに注意してください。

testCase = DefaultWidgetSizeTestCase()

現在、そのようなテストケースは多数ある可能性があり、それらのセットアップは繰り返しになる可能性があります。 上記の場合、100個のウィジェットテストケースサブクラスのそれぞれでWidgetを作成すると、見苦しい重複が発生します。

幸い、 setUp（）というメソッドを実装することで、このようなセットアップコードを除外できます。このメソッドは、テストの実行時にテストフレームワークによって自動的に呼び出されます。

import unittest

class SimpleWidgetTestCase(unittest.TestCase):
    def setUp(self):
        self.widget = Widget('The widget')

class DefaultWidgetSizeTestCase(SimpleWidgetTestCase):
    def runTest(self):
        self.assertEqual(self.widget.size(), (50,50),
                         'incorrect default size')

class WidgetResizeTestCase(SimpleWidgetTestCase):
    def runTest(self):
        self.widget.resize(100,150)
        self.assertEqual(self.widget.size(), (100,150),
                         'wrong size after resize')

テストの実行中に setUp（）メソッドで例外が発生した場合、フレームワークはテストでエラーが発生したと見なし、runTest()メソッドは実行されません。

同様に、runTest()メソッドの実行後に整理する tearDown（）メソッドを提供できます。

import unittest

class SimpleWidgetTestCase(unittest.TestCase):
    def setUp(self):
        self.widget = Widget('The widget')

    def tearDown(self):
        self.widget.dispose()
        self.widget = None

setUp（）が成功した場合、runTest()が成功したかどうかに関係なく、 tearDown（）メソッドが実行されます。

このようなテストコードの作業環境は、フィクスチャと呼ばれます。

多くの場合、多くの小さなテストケースは同じフィクスチャを使用します。 この場合、SimpleWidgetTestCaseをDefaultWidgetSizeTestCaseなどの多くの小さな1メソッドクラスにサブクラス化することになります。 これは時間がかかり、落胆するため、JUnitと同じように、 unittest はより単純なメカニズムを提供します。

import unittest

class WidgetTestCase(unittest.TestCase):
    def setUp(self):
        self.widget = Widget('The widget')

    def tearDown(self):
        self.widget.dispose()
        self.widget = None

    def test_default_size(self):
        self.assertEqual(self.widget.size(), (50,50),
                         'incorrect default size')

    def test_resize(self):
        self.widget.resize(100,150)
        self.assertEqual(self.widget.size(), (100,150),
                         'wrong size after resize')

ここでは、runTest()メソッドを提供していませんが、代わりに2つの異なるテストメソッドを提供しています。 クラスインスタンスはそれぞれtest_*()メソッドの1つを実行し、self.widgetはインスタンスごとに個別に作成および破棄されます。 インスタンスを作成するときは、実行するテストメソッドを指定する必要があります。 これを行うには、コンストラクターでメソッド名を渡します。

defaultSizeTestCase = WidgetTestCase('test_default_size')
resizeTestCase = WidgetTestCase('test_resize')

テストケースインスタンスは、テストする機能に従ってグループ化されます。 unittest は、このためのメカニズムを提供します。 unittest の TestSuite クラスで表されるテストスイート：

widgetTestSuite = unittest.TestSuite()
widgetTestSuite.addTest(WidgetTestCase('test_default_size'))
widgetTestSuite.addTest(WidgetTestCase('test_resize'))

後で説明するように、テストの実行を容易にするために、事前に作成されたテストスイートを返す呼び出し可能なオブジェクトを各テストモジュールに提供することをお勧めします。

def suite():
    suite = unittest.TestSuite()
    suite.addTest(WidgetTestCase('test_default_size'))
    suite.addTest(WidgetTestCase('test_resize'))
    return suite

あるいは：

def suite():
    tests = ['test_default_size', 'test_resize']

    return unittest.TestSuite(map(WidgetTestCase, tests))

多くの同様の名前のテスト関数を使用して TestCase サブクラスを作成するのが一般的なパターンであるため、 unittest は TestLoader クラスを提供します。テストスイートを作成し、個々のテストを入力します。 例えば、

suite = unittest.TestLoader().loadTestsFromTestCase(WidgetTestCase)

WidgetTestCase.test_default_size()およびWidgetTestCase.test_resizeを実行するテストスイートを作成します。 TestLoader は、'test'メソッド名プレフィックスを使用して、テストメソッドを自動的に識別します。

さまざまなテストケースが実行される順序は、文字列の組み込みの順序に従ってテスト関数名を並べ替えることによって決定されることに注意してください。

多くの場合、システム全体のテストを一度に実行するために、テストケースのスイートをグループ化することが望ましいです。 TestCase インスタンスを TestSuite に追加できるのと同じように、 TestSuite インスタンスを TestSuite に追加できるのでこれは簡単です。

suite1 = module1.TheTestSuite()
suite2 = module2.TheTestSuite()
alltests = unittest.TestSuite([suite1, suite2])

テストケースとテストスイートの定義は、テストするコードと同じモジュール（widget.pyなど）に配置できますが、テストコードを別のモジュールに配置することには、次のようないくつかの利点があります。 test_widget.py：

• テストモジュールは、コマンドラインからスタンドアロンで実行できます。
• テストコードは、出荷されたコードからより簡単に分離できます。
• 正当な理由なしに、テストするコードに合うようにテストコードを変更する誘惑は少なくなります。
• テストコードは、テストするコードよりもはるかに少ない頻度で変更する必要があります。
• テストされたコードは、より簡単にリファクタリングできます。
• Cで記述されたモジュールのテストは、とにかく別々のモジュールで行う必要があるので、一貫性を持たないのはなぜですか？
• テスト戦略が変更された場合、ソースコードを変更する必要はありません。

25.3.5。 古いテストコードの再利用

一部のユーザーは、すべての古いテスト関数を TestCase サブクラスに変換せずに、 unittest から実行したい既存のテストコードがあることに気付くでしょう。

このため、 unittest は FunctionTestCase クラスを提供します。 TestCase のこのサブクラスは、既存のテスト関数をラップするために使用できます。 セットアップおよび分解機能も提供できます。

次のテスト関数が与えられます。

def testSomething():
    something = makeSomething()
    assert something.name is not None
    # ...

次のように、同等のテストケースインスタンスを作成できます。

testcase = unittest.FunctionTestCase(testSomething)

テストケースの操作の一部として呼び出す必要のある追加のセットアップメソッドとティアダウンメソッドがある場合は、次のように提供することもできます。

testcase = unittest.FunctionTestCase(testSomething,
                                     setUp=makeSomethingDB,
                                     tearDown=deleteSomethingDB)

既存のテストスイートの移行を容易にするために、 unittest は、テストの失敗を示すためにAssertionErrorを発生させるテストをサポートしています。 ただし、 unittest の将来のバージョンではAssertionErrorの処理が異なる可能性があるため、代わりに明示的なTestCase.fail*()メソッドとTestCase.assert*()メソッドを使用することをお勧めします。

ノート

FunctionTestCase を使用して、既存のテストベースを unittest ベースのシステムにすばやく変換できますが、このアプローチはお勧めしません。 時間をかけて適切な TestCase サブクラスを設定すると、将来のテストリファクタリングが非常に簡単になります。

場合によっては、既存のテストが doctest モジュールを使用して作成されている可能性があります。 その場合、 doctest はDocTestSuiteクラスを提供し、既存の doctest ベースのテストから unittest.TestSuite インスタンスを自動的にビルドできます。

25.3.6。 テストのスキップと予想される失敗

バージョン2.7の新機能。

Unittestは、個々のテストメソッド、さらにはテストのクラス全体のスキップをサポートします。 さらに、テストを「予期される失敗」としてマークすることをサポートします。これは、壊れて失敗するテストですが、 TestResult では失敗としてカウントされるべきではありません。

テストをスキップするには、 skip（） デコレータまたはその条件付きバリアントの1つを使用するだけです。

基本的なスキップは次のようになります。

class MyTestCase(unittest.TestCase):

    @unittest.skip("demonstrating skipping")
    def test_nothing(self):
        self.fail("shouldn't happen")

    @unittest.skipIf(mylib.__version__ < (1, 3),
                     "not supported in this library version")
    def test_format(self):
        # Tests that work for only a certain version of the library.
        pass

    @unittest.skipUnless(sys.platform.startswith("win"), "requires Windows")
    def test_windows_support(self):
        # windows specific testing code
        pass

これは、上記の例を冗長モードで実行した結果です。

test_format (__main__.MyTestCase) ... skipped 'not supported in this library version'
test_nothing (__main__.MyTestCase) ... skipped 'demonstrating skipping'
test_windows_support (__main__.MyTestCase) ... skipped 'requires Windows'

----------------------------------------------------------------------
Ran 3 tests in 0.005s

OK (skipped=3)

クラスは、メソッドと同じようにスキップできます。

@unittest.skip("showing class skipping")
class MySkippedTestCase(unittest.TestCase):
    def test_not_run(self):
        pass

TestCase.setUp（）もテストをスキップできます。 これは、設定が必要なリソースが利用できない場合に役立ちます。

予想される障害は、 expectedFailure（）デコレータを使用します。

class ExpectedFailureTestCase(unittest.TestCase):
    @unittest.expectedFailure
    def test_fail(self):
        self.assertEqual(1, 0, "broken")

スキップしたいときにテストで skip（）を呼び出すデコレータを作成することで、独自のスキップデコレータを簡単にロールできます。 このデコレータは、渡されたオブジェクトに特定の属性がない限り、テストをスキップします。

def skipUnlessHasattr(obj, attr):
    if hasattr(obj, attr):
        return lambda func: func
    return unittest.skip("{!r} doesn't have {!r}".format(obj, attr))

次のデコレータは、テストのスキップと予想される失敗を実装します。

unittest.skip(reason)

装飾されたテストを無条件にスキップします。 reason は、テストがスキップされる理由を説明する必要があります。

unittest.skipIf(condition, reason)

条件が真の場合、装飾テストをスキップします。

unittest.skipUnless(condition, reason)

条件が真でない限り、装飾されたテストをスキップします。

unittest.expectedFailure()

テストを予想される失敗としてマークします。 実行時にテストが失敗した場合、テストは失敗としてカウントされません。

exception unittest.SkipTest(reason)

この例外は、テストをスキップするために発生します。

通常、これを直接上げる代わりに、 TestCase.skipTest（）またはスキップデコレータの1つを使用できます。

スキップされたテストでは、setUp()またはtearDown()が実行されません。 スキップされたクラスでは、setUpClass()またはtearDownClass()は実行されません。

25.3.7。 クラスと関数

このセクションでは、 unittest のAPIについて詳しく説明します。

25.3.7.1。 テストケース

class unittest.TestCase(methodName='runTest')

TestCase クラスのインスタンスは、 unittest ユニバースでテスト可能な最小のユニットを表します。 このクラスは基本クラスとして使用することを目的としており、特定のテストは具体的なサブクラスによって実装されます。 このクラスは、テストランナーがテストを実行できるようにするために必要なインターフェイスと、テストコードがさまざまな種類の障害をチェックして報告するために使用できるメソッドを実装します。

TestCase の各インスタンスは、 methodName という名前のメソッドという単一のテストメソッドを実行します。 覚えているかと思いますが、以前の例では次のようになりました。

def suite():
    suite = unittest.TestSuite()
    suite.addTest(WidgetTestCase('test_default_size'))
    suite.addTest(WidgetTestCase('test_resize'))
    return suite

ここでは、WidgetTestCaseの2つのインスタンスを作成し、それぞれが1つのテストを実行します。

methodName のデフォルトはrunTest()です。

TestCase インスタンスは、3つのメソッドグループを提供します。1つはテストの実行に使用され、もう1つはテスト実装が条件をチェックして失敗を報告するために使用し、いくつかの照会メソッドはテスト自体に関する情報を収集できるようにします。

最初のグループ（テストの実行）のメソッドは次のとおりです。

setUp()

テストフィクスチャを準備するために呼び出されるメソッド。 これは、テストメソッドを呼び出す直前に呼び出されます。 AssertionErrorまたは SkipTest 以外の場合、このメソッドによって発生した例外は、テストの失敗ではなくエラーと見なされます。 デフォルトの実装は何もしません。

tearDown()

テストメソッドが呼び出され、結果が記録された直後に呼び出されたメソッド。 これは、テストメソッドで例外が発生した場合でも呼び出されるため、サブクラスでの実装では、内部状態のチェックに特に注意する必要があります。 このメソッドによって発生したAssertionErrorまたは SkipTest 以外の例外は、テストの失敗ではなく追加のエラーと見なされます（したがって、報告されるエラーの総数が増加します）。 このメソッドは、テストメソッドの結果に関係なく、 setUp（）が成功した場合にのみ呼び出されます。 デフォルトの実装は何もしません。

setUpClass()

個々のクラスのテストが実行される前に呼び出されるクラスメソッド。 setUpClassは、クラスを唯一の引数として呼び出され、 classmethod（）として装飾する必要があります。

@classmethod
def setUpClass(cls):
    ...

詳細については、クラスおよびモジュールフィクスチャを参照してください。

バージョン2.7の新機能。

tearDownClass()

個々のクラスのテストが実行された後に呼び出されるクラスメソッド。 tearDownClassは、クラスを唯一の引数として呼び出され、 classmethod（）として装飾する必要があります。

@classmethod
def tearDownClass(cls):
    ...

詳細については、クラスおよびモジュールフィクスチャを参照してください。

バージョン2.7の新機能。

run(result=None)

テストを実行し、 result として渡されたテスト結果オブジェクトに結果を収集します。 result が省略またはNoneの場合、一時的な結果オブジェクトが作成され（ defaultTestResult（）メソッドを呼び出すことによって）使用されます。 結果オブジェクトは run（）の呼び出し元に返されません。

TestCase インスタンスを呼び出すだけでも、同じ効果が得られる場合があります。

skipTest(reason)

テストメソッドまたは setUp（）中にこれを呼び出すと、現在のテストがスキップされます。 詳細については、スキップテストと予想される障害を参照してください。

バージョン2.7の新機能。

debug()

結果を収集せずにテストを実行します。 これにより、テストによって発生した例外を呼び出し元に伝播でき、デバッガーでのテストの実行をサポートするために使用できます。

TestCase クラスは、失敗をチェックして報告するためのいくつかのassertメソッドを提供します。 次の表に、最も一般的に使用されるメソッドを示します（その他のassertメソッドについては、以下の表を参照してください）。

方法	それをチェックします	の新機能
assertEqual(a, b)	a == b
assertNotEqual(a, b)	a != b
assertTrue(x)	bool(x) is True
assertFalse(x)	bool(x) is False
assertIs(a, b)	a is b	2.7
assertIsNot(a, b)	a is not b	2.7
assertIsNone(x)	x is None	2.7
assertIsNotNone(x)	x is not None	2.7
assertIn(a, b)	a in b	2.7
assertNotIn(a, b)	a not in b	2.7
assertIsInstance(a, b)	isinstance(a, b)	2.7
assertNotIsInstance(a, b)	not isinstance(a, b)	2.7

すべてのassertメソッド（ assertRaises（）、 assertRaisesRegexp（）を除く）は、 msg 引数を受け入れます。この引数は、指定されている場合、失敗時のエラーメッセージとして使用されます（ longMessage も参照してください）。

assertEqual(first, second, msg=None)

最初のと 2番目のが等しいことをテストします。 値が等しく比較されない場合、テストは失敗します。

さらに、 first と second がまったく同じ型であり、list、tuple、dict、set、frozenset、unicodeのいずれか、またはサブクラスが addTypeEqualityFuncに登録する任意の型の場合（）より有用なデフォルトのエラーメッセージを生成するために、型固有の等価関数が呼び出されます（型固有のメソッドのリストも参照してください）。

バージョン2.7で変更：タイプ固有の等価関数の自動呼び出しが追加されました。

assertNotEqual(first, second, msg=None)

最初のと 2番目のが等しくないことをテストします。 値が等しく比較される場合、テストは失敗します。

assertTrue(expr, msg=None)
assertFalse(expr, msg=None)

expr が真（または偽）であることをテストします。

これはbool(expr) is Trueと同等であり、expr is Trueと同等ではないことに注意してください（後者にはassertIs(expr, True)を使用してください）。 この方法は、より具体的な方法が利用できる場合にも避ける必要があります（例： assertTrue(a == b)の代わりにassertEqual(a, b)）。これは、障害が発生した場合のエラーメッセージが改善されるためです。

assertIs(first, second, msg=None)
assertIsNot(first, second, msg=None)

first と second が同じオブジェクトに対して評価する（または評価しない）ことをテストします。

バージョン2.7の新機能。

assertIsNone(expr, msg=None)
assertIsNotNone(expr, msg=None)

expr がNoneである（またはそうでない）ことをテストします。

バージョン2.7の新機能。

assertIn(first, second, msg=None)
assertNotIn(first, second, msg=None)

最初のが秒にある（またはない）ことをテストします。

バージョン2.7の新機能。

assertIsInstance(obj, cls, msg=None)
assertNotIsInstance(obj, cls, msg=None)

obj が cls のインスタンスである（またはそうでない）ことをテストします（ isinstance（）でサポートされているように、クラスまたはクラスのタプルにすることができます）。 。 正確なタイプを確認するには、 assertIs（type（obj）、cls）を使用します。

バージョン2.7の新機能。

次の方法を使用して、例外と警告が発生したことを確認することもできます。

方法	それをチェックします	の新機能
assertRaises(exc, fun, *args, **kwds)	fun(*args, **kwds)は exc を発生させます
assertRaisesRegexp(exc, r, fun, *args, **kwds)	fun(*args, **kwds)は exc を発生させ、メッセージは正規表現 r と一致します	2.7

assertRaises(exception, callable, *args, **kwds)
assertRaises(exception)

callable が、 assertRaises（）にも渡される位置引数またはキーワード引数を使用して呼び出されたときに、例外が発生することをテストします。 exception が発生した場合はテストに合格し、別の例外が発生した場合はエラーになり、例外が発生しなかった場合は失敗します。 例外のグループのいずれかをキャッチするために、例外クラスを含むタプルを exception として渡すことができます。

exception 引数のみが指定されている場合は、コンテキストマネージャーを返し、テスト対象のコードを関数としてではなくインラインで記述できるようにします。

with self.assertRaises(SomeException):
    do_something()

コンテキストマネージャは、キャッチされた例外オブジェクトをexception属性に格納します。 これは、発生した例外に対して追加のチェックを実行することが目的の場合に役立ちます。

with self.assertRaises(SomeException) as cm:
    do_something()

the_exception = cm.exception
self.assertEqual(the_exception.error_code, 3)

バージョン2.7で変更：コンテキストマネージャーとして assertRaises（）を使用する機能が追加されました。

assertRaisesRegexp(exception, regexp, callable, *args, **kwds)
assertRaisesRegexp(exception, regexp)

assertRaises（）と同様ですが、 regexp が発生した例外の文字列表現と一致することもテストします。 regexp は、正規表現オブジェクト、または re.search（）での使用に適した正規表現を含む文字列です。 例：

self.assertRaisesRegexp(ValueError, "invalid literal for.*XYZ'$",
                        int, 'XYZ')

また：

with self.assertRaisesRegexp(ValueError, 'literal'):
   int('XYZ')

バージョン2.7の新機能。

次のような、より具体的なチェックを実行するために使用される他の方法もあります。

方法	それをチェックします	の新機能
assertAlmostEqual(a, b)	round(a-b, 7) == 0
assertNotAlmostEqual(a, b)	round(a-b, 7) != 0
assertGreater(a, b)	a > b	2.7
assertGreaterEqual(a, b)	a >= b	2.7
assertLess(a, b)	a < b	2.7
assertLessEqual(a, b)	a <= b	2.7
assertRegexpMatches(s, r)	r.search(s)	2.7
assertNotRegexpMatches(s, r)	not r.search(s)	2.7
assertItemsEqual(a, b)	ソート済み（a）==ソート済み（b）であり、ハッシュ不可能なオブジェクトで機能します	2.7
assertDictContainsSubset(a, b)	a のすべてのキー/値ペアは b に存在します	2.7

assertAlmostEqual(first, second, places=7, msg=None, delta=None)
assertNotAlmostEqual(first, second, places=7, msg=None, delta=None)

first と second がほぼ等しい（またはほぼ等しくない）ことをテストします。差を計算し、指定された小数点以下の桁数の桁数（デフォルトは7）に丸めます。ゼロと比較します。 これらのメソッドは、値を指定された数の小数点以下の桁数に丸めることに注意してください（つまり、 round（）関数のように）、有効数字ではありません。

place の代わりに delta が指定されている場合、 first と second の差は[以下）[以上]である必要があります。 X163X]デルタ。

デルタとプレイスの両方を指定すると、TypeErrorが発生します。

バージョン2.7で変更： assertAlmostEqual（）は、同等と比較されるほぼ同等のオブジェクトを自動的に考慮します。 assertNotAlmostEqual（）は、オブジェクトの比較が等しい場合、自動的に失敗します。 delta キーワード引数を追加しました。

assertGreater(first, second, msg=None)
assertGreaterEqual(first, second, msg=None)
assertLess(first, second, msg=None)
assertLessEqual(first, second, msg=None)

それをテストする初めそれぞれ>、> =、 2番目メソッド名によって異なります。 そうでない場合、テストは失敗します。

>>> self.assertGreaterEqual(3, 4)
AssertionError: "3" unexpectedly not greater than or equal to "4"

バージョン2.7の新機能。

assertRegexpMatches(text, regexp, msg=None)

regexp 検索が text と一致することをテストします。 失敗した場合、エラーメッセージにはパターンとテキスト（またはパターンとテキストの予期せず一致した部分）が含まれます。 regexp は、正規表現オブジェクト、または re.search（）での使用に適した正規表現を含む文字列です。

バージョン2.7の新機能。

assertNotRegexpMatches(text, regexp, msg=None)

regexp 検索が text と一致しないことを確認します。 パターンとテキストの一致する部分を含むエラーメッセージで失敗します。 regexp は、正規表現オブジェクト、または re.search（）での使用に適した正規表現を含む文字列です。

バージョン2.7の新機能。

assertItemsEqual(actual, expected, msg=None)

シーケンス expected に、順序に関係なく、 actual と同じ要素が含まれていることをテストします。 そうでない場合は、シーケンス間の違いをリストしたエラーメッセージが生成されます。

実際のと予想されるを比較する場合、重複する要素は無視されません。 各要素が両方のシーケンスで同じカウントを持っているかどうかを確認します。 assertEqual(sorted(expected), sorted(actual))と同等ですが、ハッシュ不可能なオブジェクトのシーケンスでも機能します。

Python 3では、このメソッドの名前はassertCountEqualです。

バージョン2.7の新機能。

assertDictContainsSubset(expected, actual, msg=None)

辞書 actual のキー/値ペアが expected のキー/値ペアのスーパーセットであるかどうかをテストします。 そうでない場合は、欠落しているキーと不一致の値をリストするエラーメッセージが生成されます。

バージョン2.7の新機能。

バージョン3.2以降非推奨。

assertEqual（）メソッドは、同じタイプのオブジェクトの等価性チェックを異なるタイプ固有のメソッドにディスパッチします。 これらのメソッドは、ほとんどの組み込み型にすでに実装されていますが、 addTypeEqualityFunc（）を使用して新しいメソッドを登録することもできます。

addTypeEqualityFunc(typeobj, function)

assertEqual（）によって呼び出されるタイプ固有のメソッドを登録して、まったく同じ typeobj （サブクラスではない）の2つのオブジェクトが等しいかどうかを確認します。 function は、 assertEqual（）と同様に、2つの位置引数と3番目のmsg = Noneキーワード引数を取る必要があります。 最初の2つのパラメーター間の不等式が検出された場合は、 self.failureException（msg）を発生させる必要があります。有用な情報を提供し、エラーメッセージで不等式を詳細に説明している可能性があります。

バージョン2.7の新機能。

assertEqual（）によって自動的に使用されるタイプ固有のメソッドのリストを次の表に要約します。 通常、これらのメソッドを直接呼び出す必要はないことに注意してください。

方法	比較に使用	の新機能
assertMultiLineEqual(a, b)	文字列	2.7
assertSequenceEqual(a, b)	シーケンス	2.7
assertListEqual(a, b)	リスト	2.7
assertTupleEqual(a, b)	タプル	2.7
assertSetEqual(a, b)	セットまたは冷凍セット	2.7
assertDictEqual(a, b)	口述	2.7

assertMultiLineEqual(first, second, msg=None)

複数行の文字列 first が文字列 second と等しいことをテストします。 等しくない場合、違いを強調する2つの文字列の差分がエラーメッセージに含まれます。 このメソッドは、Unicode文字列を assertEqual（）と比較するときにデフォルトで使用されます。

バージョン2.7の新機能。

assertSequenceEqual(seq1, seq2, msg=None, seq_type=None)

2つのシーケンスが等しいことをテストします。 seq_type が指定されている場合、 seq1 と seq2 の両方が seq_type のインスタンスである必要があります。そうでない場合、エラーが発生します。 シーケンスが異なる場合は、2つの違いを示すエラーメッセージが作成されます。

このメソッドは assertEqual（）によって直接呼び出されませんが、 assertListEqual（）および assertTupleEqual（）を実装するために使用されます。

バージョン2.7の新機能。

assertListEqual(list1, list2, msg=None)
assertTupleEqual(tuple1, tuple2, msg=None)

2つのリストまたはタプルが等しいことをテストします。 そうでない場合は、2つの違いのみを示すエラーメッセージが作成されます。 いずれかのパラメータのタイプが間違っている場合にもエラーが発生します。 これらのメソッドは、リストまたはタプルを assertEqual（）と比較するときにデフォルトで使用されます。

バージョン2.7の新機能。

assertSetEqual(set1, set2, msg=None)

2つのセットが等しいことをテストします。 そうでない場合は、セット間の違いをリストするエラーメッセージが作成されます。 このメソッドは、セットまたはフリーズセットを assertEqual（）と比較するときにデフォルトで使用されます。

set1 または set2 のいずれかにset.difference()メソッドがない場合は失敗します。

バージョン2.7の新機能。

assertDictEqual(expected, actual, msg=None)

2つの辞書が等しいことをテストします。 そうでない場合は、辞書の違いを示すエラーメッセージが作成されます。 このメソッドは、 assertEqual（）の呼び出しで辞書を比較するためにデフォルトで使用されます。

バージョン2.7の新機能。

最後に、 TestCase は、次のメソッドと属性を提供します。

fail(msg=None)

エラーメッセージは msg またはNoneで、無条件にテストの失敗を通知します。

failureException

このクラス属性は、テストメソッドによって発生した例外を示します。 テストフレームワークが特殊な例外を使用する必要がある場合、おそらく追加情報を運ぶために、フレームワークと「公平にプレイ」するために、この例外をサブクラス化する必要があります。 この属性の初期値はAssertionErrorです。

longMessage

Trueに設定すると、 assertメソッドに渡す明示的な失敗メッセージは、通常の失敗メッセージの最後に追加されます。 通常のメッセージには、関連するオブジェクトに関する有用な情報が含まれています。たとえば、assertEqualからのメッセージは、2つの等しくないオブジェクトのreprを示しています。 この属性をTrueに設定すると、通常のエラーメッセージに加えてカスタムエラーメッセージを表示できます。

この属性のデフォルトはFalseです。これは、assertメソッドに渡されたカスタムメッセージが通常のメッセージを無音にすることを意味します。

クラス設定は、assertメソッドを呼び出す前にTrueまたはFalseにインスタンス属性を割り当てることにより、個々のテストでオーバーライドできます。

バージョン2.7の新機能。

maxDiff

この属性は、失敗時に差分を報告するassertメソッドによって出力される差分の最大長を制御します。 デフォルトは80 * 8文字です。 この属性の影響を受けるアサートメソッドは、 assertSequenceEqual（）（それに委任するすべてのシーケンス比較メソッドを含む）、 assertDictEqual（）、および assertMultiLineEqual（）です。

maxDiffをNoneに設定すると、差分の最大長がなくなります。

バージョン2.7の新機能。

テストフレームワークは、次の方法を使用してテストに関する情報を収集できます。

countTestCases()

このテストオブジェクトによって表されるテストの数を返します。 TestCase インスタンスの場合、これは常に1になります。

defaultTestResult()

このテストケースクラスに使用する必要があるテスト結果クラスのインスタンスを返します（ run（）メソッドに他の結果インスタンスが提供されていない場合）。

TestCase インスタンスの場合、これは常に TestResult のインスタンスになります。 TestCase のサブクラスは、必要に応じてこれをオーバーライドする必要があります。

id()

特定のテストケースを識別する文字列を返します。 これは通常、モジュール名とクラス名を含む、テストメソッドのフルネームです。

shortDescription()

テストの説明を返します。説明が指定されていない場合はNoneを返します。 このメソッドのデフォルトの実装は、テストメソッドのdocstringの最初の行（使用可能な場合）、または None を返します。

addCleanup(function, *args, **kwargs)

tearDown（）の後に呼び出される関数を追加して、テスト中に使用されたリソースをクリーンアップします。 関数は、追加された順序とは逆の順序で呼び出されます（LIFO）。 これらは、追加時に addCleanup（）に渡される引数とキーワード引数を使用して呼び出されます。

setUp（）が失敗した場合、つまり tearDown（）が呼び出されなかった場合でも、追加されたクリーンアップ関数は呼び出されます。

バージョン2.7の新機能。

doCleanups()

このメソッドは、 tearDown（）の後、または setUp（）が例外を発生させた場合は、 setUp（）の後に無条件に呼び出されます。

addCleanup（）によって追加されたすべてのクリーンアップ関数を呼び出す必要があります。 before から tearDown（）にクリーンアップ関数を呼び出す必要がある場合は、 doCleanups（）を自分で呼び出すことができます。

doCleanups（）は、クリーンアップ関数のスタックからメソッドを一度に1つずつポップするため、いつでも呼び出すことができます。

バージョン2.7の新機能。

class unittest.FunctionTestCase(testFunc, setUp=None, tearDown=None, description=None)

このクラスは、 TestCase インターフェイスの一部を実装して、テストランナーがテストを実行できるようにしますが、テストコードがエラーのチェックとレポートに使用できるメソッドを提供しません。 これは、レガシーテストコードを使用してテストケースを作成するために使用され、 unittest ベースのテストフレームワークに統合できるようにします。

25.3.7.1.1。 非推奨のエイリアス

歴史的な理由から、一部の TestCase メソッドには1つ以上のエイリアスがあり、現在は非推奨になっています。 次の表に、正しい名前と非推奨のエイリアスを示します。

メソッド名	非推奨のエイリアス
assertEqual()	failUnlessEqual、assertEquals
assertNotEqual()	failIfEqual
assertTrue()	failUnless、assert_
assertFalse()	failIf
assertRaises()	failUnlessRaises
assertAlmostEqual()	failUnlessAlmostEqual
assertNotAlmostEqual()	failIfAlmostEqual

バージョン2.7以降非推奨： 2番目の列にリストされているエイリアス

25.3.7.2。 グループ化テスト

class unittest.TestSuite(tests=())

このクラスは、個々のテストケースとテストスイートの集合体を表します。 このクラスは、テストランナーが他のテストケースと同じように実行できるようにするために必要なインターフェイスを提供します。 TestSuite インスタンスの実行は、スイートを反復処理して各テストを個別に実行することと同じです。

tests が指定されている場合、最初にスイートを構築するために使用される個々のテストケースまたは他のテストスイートの反復可能である必要があります。 後でコレクションにテストケースとスイートを追加するための追加のメソッドが提供されています。

TestSuite オブジェクトは、実際にテストを実装しないことを除いて、 TestCase オブジェクトとほとんど同じように動作します。 代わりに、一緒に実行する必要があるテストのグループにテストを集約するために使用されます。 TestSuite インスタンスにテストを追加するためにいくつかの追加の方法が利用可能です。

addTest(test)

TestCase または TestSuite をスイートに追加します。

addTests(tests)

反復可能な TestCase および TestSuite インスタンスからのすべてのテストをこのテストスイートに追加します。

これは、要素ごとに addTest（）を呼び出して、テストを反復処理するのと同じです。

TestSuite は、 TestCase と次のメソッドを共有しています。

run(result)

このスイートに関連付けられたテストを実行し、結果を result として渡されたテスト結果オブジェクトに収集します。 TestCase.run（）とは異なり、 TestSuite.run（）では結果オブジェクトを渡す必要があることに注意してください。

debug()

結果を収集せずに、このスイートに関連付けられたテストを実行します。 これにより、テストによって発生した例外を呼び出し元に伝播し、デバッガーでのテストの実行をサポートするために使用できます。

countTestCases()

すべての個別のテストとサブスイートを含む、このテストオブジェクトによって表されるテストの数を返します。

__iter__()

TestSuite によってグループ化されたテストには、常に反復によってアクセスされます。 サブクラスは、 __ iter __（）をオーバーライドすることにより、遅延テストを提供できます。 このメソッドは、単一のスイートで複数回呼び出される可能性があるため（たとえば、テストをカウントしたり、等しいかどうかを比較したりする場合）、繰り返される反復で返されるテストは同じである必要があることに注意してください。

バージョン2.7での変更：以前のバージョンでは、 TestSuite は反復ではなく直接テストにアクセスしたため、 __ iter __（）をオーバーライドするだけではテストを提供できませんでした。

TestSuite オブジェクトの一般的な使用法では、 run（）メソッドは、エンドユーザーのテストハーネスではなくTestRunnerによって呼び出されます。

25.3.7.3。 テストのロードと実行

class unittest.TestLoader

TestLoader クラスは、クラスとモジュールからテストスイートを作成するために使用されます。 通常、このクラスのインスタンスを作成する必要はありません。 unittest モジュールは、 unittest.defaultTestLoader として共有できるインスタンスを提供します。 ただし、サブクラスまたはインスタンスを使用すると、いくつかの構成可能なプロパティをカスタマイズできます。

TestLoader オブジェクトには次のメソッドがあります。

loadTestsFromTestCase(testCaseClass)

TestCase から派生したtestCaseClassに含まれるすべてのテストケースのスイートを返します。

loadTestsFromModule(module)

指定されたモジュールに含まれるすべてのテストケースのスイートを返します。 このメソッドは、 module で TestCase から派生したクラスを検索し、クラスに定義された各テストメソッドのクラスのインスタンスを作成します。

ノート

TestCase から派生したクラスの階層を使用すると、フィクスチャとヘルパー関数を共有するのに便利ですが、直接インスタンス化することを目的としない基本クラスでテストメソッドを定義することは、このメソッドではうまく機能しません。 ただし、そうすることは、フィクスチャが異なり、サブクラスで定義されている場合に役立ちます。

モジュールがload_tests関数を提供する場合、テストをロードするために呼び出されます。 これにより、モジュールでテストの読み込みをカスタマイズできます。 これは load_testsプロトコルです。

バージョン2.7で変更： load_testsのサポートが追加されました。

loadTestsFromName(name, module=None)

文字列指定子を指定して、すべてのテストケースのスイートを返します。

指定子 name は、モジュール、テストケースクラス、テストケースクラス内のテストメソッド、 TestSuite インスタンス、または呼び出し可能オブジェクトのいずれかに解決できる「ドット名」です。 TestCase または TestSuite インスタンスを返すオブジェクト。 これらのチェックは、ここにリストされている順序で適用されます。 つまり、可能なテストケースクラスのメソッドは、「呼び出し可能なオブジェクト」ではなく、「テストケースクラス内のテストメソッド」として取得されます。

たとえば、 TestCase から派生したクラスSampleTestCaseと3つのテストメソッド（test_one()、test_two()）を含むモジュールSampleTestsがあるとします。 、およびtest_three()）、指定子'SampleTests.SampleTestCase'により、このメソッドは3つのテストメソッドすべてを実行するスイートを返します。 指定子'SampleTests.SampleTestCase.test_two'を使用すると、test_two()テストメソッドのみを実行するテストスイートが返されます。 指定子は、インポートされていないモジュールおよびパッケージを参照できます。 それらは副作用としてインポートされます。

このメソッドは、オプションで、指定されたモジュールに関連する名前を解決します。

loadTestsFromNames(names, module=None)

loadTestsFromName（）に似ていますが、単一の名前ではなく一連の名前を取ります。 戻り値は、名前ごとに定義されたすべてのテストをサポートするテストスイートです。

getTestCaseNames(testCaseClass)

testCaseClass 内で見つかったメソッド名のソートされたシーケンスを返します。 これは TestCase のサブクラスである必要があります。

discover(start_dir, pattern='test*.py', top_level_dir=None)

指定された開始ディレクトリからサブディレクトリに再帰してすべてのテストモジュールを検索し、それらを含むTestSuiteオブジェクトを返します。 パターンに一致するテストファイルのみがロードされます。 （シェルスタイルのパターンマッチングを使用します。）インポート可能なモジュール名のみ（つまり、 有効なPython識別子です）がロードされます。

すべてのテストモジュールは、プロジェクトのトップレベルからインポート可能である必要があります。 開始ディレクトリが最上位ディレクトリでない場合は、最上位ディレクトリを個別に指定する必要があります。

構文エラーなどが原因でモジュールのインポートが失敗した場合、これは単一のエラーとして記録され、検出が続行されます。

テストパッケージ名（__init__.pyのディレクトリ）がパターンと一致する場合、パッケージはload_tests機能についてチェックされます。 これが存在する場合は、ローダー、テスト、パターンで呼び出されます。

load_testsが存在する場合、検出はパッケージにしない再帰を行い、load_testsはパッケージ内のすべてのテストをロードする責任があります。

パッケージが自身で検出を継続できるように、パターンはローダー属性として意図的に保存されていません。 top_level_dir が格納されるため、load_testsはこの引数をloader.discover()に渡す必要はありません。

start_dir は、ディレクトリだけでなく、ドット付きのモジュール名にすることもできます。

バージョン2.7の新機能。

TestLoader の次の属性は、インスタンスのサブクラス化または割り当てのいずれかによって構成できます。

testMethodPrefix

テストメソッドとして解釈されるメソッド名のプレフィックスを与える文字列。 デフォルト値は'test'です。

これは、 getTestCaseNames（）およびすべてのloadTestsFrom*()メソッドに影響します。

sortTestMethodsUsing

getTestCaseNames（）およびすべてのloadTestsFrom*()メソッドでメソッド名を並べ替えるときにメソッド名を比較するために使用される関数。 デフォルト値は、組み込みの cmp（）関数です。 属性を None に設定して、ソートを無効にすることもできます。

suiteClass

テストのリストからテストスイートを構築する呼び出し可能なオブジェクト。 結果のオブジェクトに対するメソッドは必要ありません。 デフォルト値は TestSuite クラスです。

これは、すべてのloadTestsFrom*()メソッドに影響します。

class unittest.TestResult

このクラスは、どのテストが成功し、どのテストが失敗したかに関する情報をコンパイルするために使用されます。

TestResult オブジェクトは、一連のテストの結果を格納します。 TestCase および TestSuite クラスは、結果が適切に記録されることを保証します。 テストの作成者は、テストの結果を記録することを心配する必要はありません。

unittest の上に構築されたテストフレームワークは、レポート目的で一連のテストを実行することによって生成された TestResult オブジェクトへのアクセスを必要とする場合があります。 TestResult インスタンスは、この目的のためにTestRunner.run()メソッドによって返されます。

TestResult インスタンスには、一連のテストの実行結果を検査するときに重要となる次の属性があります。

errors

TestCase インスタンスの2タプルとフォーマットされたトレースバックを保持する文字列を含むリスト。 各タプルは、予期しない例外を発生させたテストを表します。

バージョン2.2で変更： sys.exc_info（）の結果ではなく、フォーマットされたトレースバックが含まれています。

failures

TestCase インスタンスの2タプルとフォーマットされたトレースバックを保持する文字列を含むリスト。 各タプルは、TestCase.assert*()メソッドを使用して障害が明示的に通知されたテストを表します。

バージョン2.2で変更： sys.exc_info（）の結果ではなく、フォーマットされたトレースバックが含まれています。

skipped

TestCase インスタンスの2タプルとテストをスキップする理由を保持する文字列を含むリスト。

バージョン2.7の新機能。

expectedFailures

TestCase インスタンスの2タプルとフォーマットされたトレースバックを保持する文字列を含むリスト。 各タプルは、テストケースの予想される失敗を表します。

unexpectedSuccesses

予想される失敗としてマークされたが成功した TestCase インスタンスを含むリスト。

shouldStop

stop（）でテストの実行を停止する場合は、Trueに設定してください。

testsRun

これまでに実行されたテストの総数。

buffer

trueに設定すると、sys.stdoutとsys.stderrは、呼び出される startTest（）と stopTest（）の間にバッファリングされます。 収集された出力は、テストが失敗またはエラーになった場合にのみ、実際のsys.stdoutおよびsys.stderrにエコーされます。 すべての出力は、失敗/エラーメッセージにも添付されます。

バージョン2.7の新機能。

failfast

trueに設定すると、最初の失敗またはエラー時に stop（）が呼び出され、テストの実行が停止します。

バージョン2.7の新機能。

wasSuccessful()

これまでに実行されたすべてのテストに合格した場合はTrueを返し、それ以外の場合はFalseを返します。

stop()

このメソッドを呼び出して、 shouldStop 属性をTrueに設定することにより、実行中の一連のテストを中止する必要があることを通知できます。 TestRunnerオブジェクトはこのフラグを尊重し、追加のテストを実行せずに戻る必要があります。

たとえば、この機能は TextTestRunner クラスによって使用され、ユーザーがキーボードから割り込みを通知したときにテストフレームワークを停止します。 TestRunner実装を提供するインタラクティブツールは、これを同様の方法で使用できます。

TestResult クラスの次のメソッドは、内部データ構造を維持するために使用され、追加のレポート要件をサポートするためにサブクラスで拡張される場合があります。 これは、テストの実行中にインタラクティブなレポートをサポートするツールを構築する場合に特に役立ちます。

startTest(test)

テストケーステストが実行されようとしているときに呼び出されます。

stopTest(test)

結果に関係なく、テストケース test が実行された後に呼び出されます。

startTestRun()

テストが実行される前に1回呼び出されます。

バージョン2.7の新機能。

stopTestRun()

すべてのテストが実行された後に1回呼び出されます。

バージョン2.7の新機能。

addError(test, err)

テストケース test で予期しない例外が発生したときに呼び出されます。 err は、 sys.exc_info（）：(type, value, traceback)によって返される形式のタプルです。

デフォルトの実装では、タプル(test, formatted_err)がインスタンスの errors 属性に追加されます。ここで、 formatted_err は、 err から派生したフォーマット済みトレースバックです。

addFailure(test, err)

テストケース test が失敗を通知したときに呼び出されます。 err は、 sys.exc_info（）：(type, value, traceback)によって返される形式のタプルです。

デフォルトの実装では、タプル(test, formatted_err)がインスタンスの failures 属性に追加されます。ここで、 formatted_err は、 err から派生したフォーマット済みトレースバックです。

addSuccess(test)

テストケーステストが成功したときに呼び出されます。

デフォルトの実装は何もしません。

addSkip(test, reason)

テストケーステストがスキップされたときに呼び出されます。 reason は、テストがスキップした理由です。

デフォルトの実装では、インスタンスの skipped 属性にタプル(test, reason)が追加されます。

addExpectedFailure(test, err)

テストケース test が失敗したが、 expectedFailure（）デコレータでマークされたときに呼び出されます。

デフォルトの実装では、タプル(test, formatted_err)がインスタンスの expectedFailures 属性に追加されます。ここで、 formatted_err は、 err から派生したフォーマット済みトレースバックです。

addUnexpectedSuccess(test)

テストケース test が expectedFailure（）デコレータでマークされたときに呼び出されましたが、成功しました。

デフォルトの実装では、インスタンスの unexpectedSuccesses 属性にテストが追加されます。

class unittest.TextTestResult(stream, descriptions, verbosity)

TextTestRunner によって使用される TestResult の具体的な実装。

バージョン2.7の新機能：このクラスは以前は_TextTestResultという名前でした。 古い名前はまだエイリアスとして存在しますが、非推奨です。

unittest.defaultTestLoader

共有を目的とした TestLoader クラスのインスタンス。 TestLoader のカスタマイズが必要ない場合は、新しいインスタンスを繰り返し作成する代わりに、このインスタンスを使用できます。

class unittest.TextTestRunner(stream=sys.stderr, descriptions=True, verbosity=1, failfast=False, buffer=False, resultclass=None)

標準エラーで結果を出力する基本的なテストランナーの実装。 構成可能なパラメーターがいくつかありますが、基本的に非常に単純です。 テストスイートを実行するグラフィカルアプリケーションは、代替の実装を提供する必要があります。

_makeResult()

このメソッドは、run()によって使用されるTestResultのインスタンスを返します。 直接呼び出すことを意図したものではありませんが、サブクラスでオーバーライドして、カスタムTestResultを提供できます。

_makeResult()は、TextTestRunnerコンストラクターでresultclass引数として渡されたクラスまたは呼び出し可能オブジェクトをインスタンス化します。 resultclassが指定されていない場合、デフォルトで TextTestResult になります。 結果クラスは、次の引数でインスタンス化されます。

stream, descriptions, verbosity

unittest.main([module[, defaultTest[, argv[, testRunner[, testLoader[, exit[, verbosity[, failfast[, catchbreak[, buffer]]]]]]]]]])

モジュールから一連のテストをロードして実行するコマンドラインプログラム。 これは主に、テストモジュールを便利に実行できるようにするためのものです。 この関数の最も簡単な使用法は、テストスクリプトの最後に次の行を含めることです。

if __name__ == '__main__':
    unittest.main()

詳細な引数を渡すことで、より詳細な情報を使用してテストを実行できます。

if __name__ == '__main__':
    unittest.main(verbosity=2)

defaultTest 引数は、 argv でテスト名が指定されていない場合に実行するテストの名前です。 指定されていないか、Noneであり、 argv を介してテスト名が提供されていない場合、モジュールで見つかったすべてのテストが実行されます。

argv 引数は、プログラムに渡されるオプションのリストにすることができ、最初の要素はプログラム名です。 指定されていない場合、またはNoneの場合、 sys.argv の値が使用されます。

testRunner 引数は、テストランナークラスまたはその作成済みインスタンスのいずれかです。 デフォルトでは、mainは、テスト実行の成功または失敗を示す終了コードを使用して sys.exit（）を呼び出します。

testLoader 引数は TestLoader インスタンスである必要があり、デフォルトは defaultTestLoader です。

mainは、引数exit=Falseを渡すことにより、対話型インタープリターからの使用をサポートします。 これにより、 sys.exit（）を呼び出さずに結果が標準出力に表示されます。

>>> from unittest import main
>>> main(module='test_module', exit=False)

failfast 、 catchbreak 、および buffer パラメーターは、同じ名前のコマンドラインオプションと同じ効果があります。

mainを呼び出すと、実際にはTestProgramクラスのインスタンスが返されます。 これは、実行されたテストの結果をresult属性として保存します。

バージョン2.7で変更： exit 、 verbosity 、 failfast 、 catchbreak 、 buffer [X125X ]パラメータが追加されました。

25.3.7.3.1。 load_testsプロトコル

バージョン2.7の新機能。

モジュールまたはパッケージは、load_testsと呼ばれる関数を実装することにより、通常のテスト実行またはテスト検出中にそれらからテストをロードする方法をカスタマイズできます。

テストモジュールがload_testsを定義している場合、次の引数を使用して TestLoader.loadTestsFromModule（）によって呼び出されます。

load_tests(loader, standard_tests, None)

TestSuite を返す必要があります。

loader は、ロードを実行する TestLoader のインスタンスです。 standard_tests は、モジュールからデフォルトでロードされるテストです。 テストモジュールでは、標準のテストセットからテストを追加または削除するだけでよいのが一般的です。 3番目の引数は、テスト検出の一部としてパッケージをロードするときに使用されます。

TestCase クラスの特定のセットからテストをロードする典型的なload_tests関数は次のようになります。

test_cases = (TestCase1, TestCase2, TestCase3)

def load_tests(loader, tests, pattern):
    suite = TestSuite()
    for test_class in test_cases:
        tests = loader.loadTestsFromTestCase(test_class)
        suite.addTests(tests)
    return suite

コマンドラインから、または TestLoader.discover（）を呼び出して、パッケージ名と一致するパターンで検出を開始すると、パッケージ__init__.pyの [がチェックされます。 X194X]。

ノート

デフォルトのパターンは'test*.py'です。 これは、'test'で始まるすべてのPythonファイルに一致しますが、はどのテストディレクトリにも一致しません。

'test*'のようなパターンは、モジュールだけでなくテストパッケージにも一致します。

パッケージ__init__.pyがload_testsを定義している場合、それは呼び出され、検出はパッケージ内で続行されません。 load_testsは、次の引数で呼び出されます。

load_tests(loader, standard_tests, pattern)

これにより、パッケージのすべてのテストを表す TestSuite が返されます。 （standard_testsには、__init__.pyから収集されたテストのみが含まれます。）

パターンはload_testsに渡されるため、パッケージは自由にテスト検出を続行（および場合によっては変更）できます。 テストパッケージの「何もしない」load_tests関数は次のようになります。

def load_tests(loader, standard_tests, pattern):
    # top level directory cached on loader instance
    this_dir = os.path.dirname(__file__)
    package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
    standard_tests.addTests(package_tests)
    return standard_tests

25.3.8。 クラスおよびモジュールの備品

クラスおよびモジュールレベルのフィクスチャは、 TestSuite に実装されています。 テストスイートが新しいクラスからのテストに遭遇すると、前のクラス（存在する場合）のtearDownClass()が呼び出され、続いて新しいクラスのsetUpClass()が呼び出されます。

同様に、テストが前のテストとは異なるモジュールからのものである場合、前のモジュールのtearDownModuleが実行され、続いて新しいモジュールのsetUpModuleが実行されます。

すべてのテストが実行された後、最後のtearDownClassおよびtearDownModuleが実行されます。

共有フィクスチャは、テストの並列化などの[潜在的な]機能ではうまく機能せず、テストの分離を破ることに注意してください。 それらは注意して使用する必要があります。

unittestテストローダーによって作成されるテストのデフォルトの順序は、同じモジュールおよびクラスからのすべてのテストをグループ化することです。 これにより、setUpClass / setUpModule（など）がクラスおよびモジュールごとに1回だけ呼び出されます。 順序をランダム化して、異なるモジュールおよびクラスからのテストが互いに隣接するようにすると、これらの共有フィクスチャ関数は、1回のテスト実行で複数回呼び出される可能性があります。

共有フィクスチャは、非標準の順序のスイートで機能することを目的としていません。 BaseTestSuiteは、共有フィクスチャをサポートしたくないフレームワーク用に引き続き存在します。

共有フィクスチャ機能の1つで例外が発生した場合、テストはエラーとして報告されます。 対応するテストインスタンスがないため、エラーを表すために_ErrorHolderオブジェクト（ TestCase と同じインターフェイスを持つ）が作成されます。 標準の単体テストテストランナーを使用しているだけの場合、この詳細は重要ではありませんが、フレームワークの作成者であれば、関連性がある可能性があります。

25.3.8.1。 setUpClassとtearDownClass

これらはクラスメソッドとして実装する必要があります。

import unittest

class Test(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        cls._connection = createExpensiveConnectionObject()

    @classmethod
    def tearDownClass(cls):
        cls._connection.destroy()

基本クラスのsetUpClassとtearDownClassを呼び出す場合は、自分で呼び出す必要があります。 TestCase の実装は空です。

setUpClass中に例外が発生した場合、クラス内のテストは実行されず、tearDownClassは実行されません。 スキップされたクラスでは、setUpClassまたはtearDownClassは実行されません。 例外が SkipTest 例外の場合、クラスはエラーではなくスキップされたものとして報告されます。

25.3.8.2。 setUpModuleおよびtearDownModule

これらは関数として実装する必要があります。

def setUpModule():
    createConnection()

def tearDownModule():
    closeConnection()

setUpModuleで例外が発生した場合、モジュール内のテストは実行されず、tearDownModuleは実行されません。 例外が SkipTest 例外の場合、モジュールはエラーとしてではなくスキップされたものとして報告されます。

25.3.9。 信号処理

unittestの -c / -catch コマンドラインオプションは、 unittest.main（）のcatchbreakパラメーターとともに、制御のより使いやすい処理を提供します-テスト実行中のC。 キャッチブレーク動作を有効にすると、control-Cにより、現在実行中のテストが完了し、テストの実行が終了して、これまでのすべての結果が報告されます。 2番目のcontrol-cは、通常の方法でKeyboardInterruptを発生させます。

control-c処理シグナルハンドラーは、独自のsignal.SIGINTハンドラーをインストールするコードまたはテストとの互換性を維持しようとします。 unittestハンドラーが呼び出されたが、がインストールされたsignal.SIGINTハンドラーではない場合、つまり テスト対象のシステムに置き換えられ、委任された後、デフォルトのハンドラーを呼び出します。 これは通常、インストールされたハンドラーを置き換えてそれに委任するコードによって期待される動作になります。 unittest control-c処理を無効にする必要がある個々のテストでは、 removeHandler（）デコレータを使用できます。

フレームワークの作成者がテストフレームワーク内でcontrol-c処理機能を有効にするためのユーティリティ関数がいくつかあります。

unittest.installHandler()

control-cハンドラーをインストールします。 signal.SIGINTを受信すると（通常、ユーザーがcontrol-cを押すと）、登録されたすべての結果で stop（）が呼び出されます。

バージョン2.7の新機能。

unittest.registerResult(result)

control-c処理用に TestResult オブジェクトを登録します。 結果を登録すると、その結果への弱参照が格納されるため、結果がガベージコレクションされるのを防ぐことはできません。

TestResult オブジェクトの登録は、control-c処理が有効になっていない場合でも副作用がないため、テストフレームワークは、処理が有効かどうかに関係なく、作成するすべての結果を無条件に登録できます。

バージョン2.7の新機能。

unittest.removeResult(result)

登録した結果を削除します。 結果が削除されると、control-cに応答して、その結果オブジェクトで stop（）が呼び出されなくなります。

バージョン2.7の新機能。

unittest.removeHandler(function=None)

この関数を引数なしで呼び出すと、control-cハンドラーがインストールされている場合は削除されます。 この関数は、テストの実行中にハンドラーを一時的に削除するためのテストデコレータとしても使用できます。

@unittest.removeHandler
def test_signal_handling(self):
    ...

バージョン2.7の新機能。