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

提供：Dev Guides
< PythonPython/docs/3.8/library/unittest
移動先:案内、検索

unittest —ユニットテストフレームワーク

ソースコード： ：source： `Lib / unittest / __ init __。py`


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

unittest ユニットテストフレームワークは、もともとJUnitに触発されており、他の言語の主要なユニットテストフレームワークと同様のフレーバーを持っています。 テストの自動化、テストのセットアップコードとシャットダウンコードの共有、テストのコレクションへの集約、およびレポートフレームワークからのテストの独立性をサポートします。

これを実現するために、 unittest は、オブジェクト指向の方法でいくつかの重要な概念をサポートしています。

テストフィクスチャ
テストフィクスチャは、1つ以上のテストを実行するために必要な準備、および関連するクリーンアップアクションを表します。 これには、たとえば、一時データベースまたはプロキシデータベース、ディレクトリの作成、またはサーバープロセスの開始が含まれる場合があります。
テストケース
テストケースは、個々のテスト単位です。 特定の入力セットに対する特定の応答をチェックします。 unittest は、新しいテストケースを作成するために使用できる基本クラス TestCase を提供します。
テストスイート
テストスイートは、テストケース、テストスイート、またはその両方のコレクションです。 一緒に実行する必要があるテストを集約するために使用されます。
テストランナー
テストランナーは、テストの実行を調整し、ユーザーに結果を提供するコンポーネントです。 ランナーは、グラフィカルインターフェイス、テキストインターフェイスを使用するか、テストの実行結果を示す特別な値を返すことができます。

も参照してください

モジュール doctest
非常に異なるフレーバーを持つ別のテストサポートモジュール。
単純なSmalltalkテスト：パターンを使用
unittest によって共有されるパターンを使用したフレームワークのテストに関するKentBeckのオリジナルペーパー。
pytest
テストを作成するための軽量構文を備えたサードパーティの単体テストフレームワーク。 たとえば、assert func(10) == 42です。
Pythonテストツールの分類法
機能テストフレームワークやモックオブジェクトライブラリを含むPythonテストツールの広範なリスト。
Pythonメーリングリストでのテスト
Pythonでのテストおよびテストツールについて議論するための分科会。

PythonソースディストリビューションのスクリプトTools/unittestgui/unittestgui.pyは、テストの検出と実行のためのGUIツールです。 これは主に、単体テストを初めて使用する人が使いやすいようにすることを目的としています。 実稼働環境では、 Buildbot 、 Jenkins 、 Travis-CI 、 AppVeyor などの継続的インテグレーションシステムでテストを実行することをお勧めします。 ]。


基本例

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

-vオプションをテストスクリプトに渡すと、 unittest.main（）に、より高いレベルの詳細度を有効にするように指示され、次の出力が生成されます。 

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

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

OK

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


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

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

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

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

テストモジュールは、ファイルパスでも指定できます。 

python -m unittest tests/test_something.py

これにより、シェルファイル名補完を使用してテストモジュールを指定できます。 指定されたファイルは、モジュールとしてインポート可能である必要があります。 パスは、「。py」を削除し、パス区切り文字を「。」に変換することにより、モジュール名に変換されます。 モジュールとしてインポートできないテストファイルを実行する場合は、代わりにファイルを直接実行する必要があります。

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

python -m unittest -v test_module

引数なしで実行すると、 Test Discovery が開始されます。 

python -m unittest

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

python -m unittest -h

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


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

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

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

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

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

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

パターンまたはサブストリングに一致するテストメソッドとクラスのみを実行します。 このオプションは複数回使用できます。その場合、指定されたパターンに一致するすべてのテストケースが含まれます。

ワイルドカード文字（*）を含むパターンは、 fnmatch.fnmatchcase（）を使用してテスト名と照合されます。 それ以外の場合は、大文字と小文字を区別する単純な部分文字列マッチングが使用されます。

パターンは、テストローダーによってインポートされた完全修飾テストメソッド名と照合されます。

たとえば、-k fooはfoo_tests.SomeTest.test_something、bar_tests.SomeTest.test_fooと一致しますが、bar_tests.FooTest.test_somethingとは一致しません。

--locals
トレースバックでローカル変数を表示します。

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


バージョン3.5の新機能：コマンドラインオプション--locals。


バージョン3.7の新機能：コマンドラインオプション-k。


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


テストディスカバリー

バージョン3.2の新機能。


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

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

cd project_directory
python -m unittest discover

ノート

ショートカットとして、python -m unittestはpython -m unittest discoverと同等です。 検出をテストするために引数を渡す場合は、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プロトコルを介してテストのロードと検出をカスタマイズできます。

バージョン3.4で変更：テスト検出は、開始ディレクトリの名前空間パッケージをサポートします。 トップレベルのディレクトリにも移動する必要があることに注意してください。 （例えば python -m unittest discover -s root/namespace -t root）。


テストコードの整理

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

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

最も単純な TestCase サブクラスは、単にテストメソッドを実装します（つまり、 特定のテストコードを実行するために、名前がtest）で始まるメソッド： 

import unittest

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

何かをテストするために、 TestCase 基本クラスによって提供されるassert*()メソッドの1つを使用することに注意してください。 テストが失敗した場合、説明メッセージとともに例外が発生し、 unittest はテストケースを失敗として識別します。 その他の例外はエラーとして扱われます。

テストは多数あり、セットアップは繰り返し行うことができます。 幸い、 setUp（）というメソッドを実装することで、セットアップコードを除外できます。このメソッドは、実行するすべてのテストに対してテストフレームワークが自動的に呼び出します。 

import unittest

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

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

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

ノート

さまざまなテストが実行される順序は、文字列の組み込みの順序に関してテストメソッド名を並べ替えることによって決定されます。


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

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

import unittest

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

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

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

このようなテストコードの作業環境は、テストフィクスチャと呼ばれます。 新しいTestCaseインスタンスは、個々のテストメソッドを実行するために使用される一意のテストフィクスチャとして作成されます。 したがって、 setUp（）、 tearDown（）、および__init__()は、テストごとに1回呼び出されます。

TestCase実装を使用して、テストする機能に応じてテストをグループ化することをお勧めします。 unittest は、このためのメカニズムを提供します。[X59X] test suite は、 unittest の TestSuite クラスで表されます。 ほとんどの場合、 unittest.main（）を呼び出すと正しいことが行われ、モジュールのすべてのテストケースが収集されて実行されます。

ただし、テストスイートの構築をカスタマイズする場合は、自分で行うことができます。 

def suite():
    suite = unittest.TestSuite()
    suite.addTest(WidgetTestCase('test_default_widget_size'))
    suite.addTest(WidgetTestCase('test_widget_resize'))
    return suite

if __name__ == '__main__':
    runner = unittest.TextTestRunner()
    runner.run(suite())

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

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


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

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

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

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

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

オプションのセットアップおよびティアダウンメソッドを使用して、次のように同等のテストケースインスタンスを作成できます。 

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

ノート

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


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


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

バージョン3.1の新機能。


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

テストをスキップするには、 skip（） デコレータまたはその条件付きバリアントの1つを使用して、内で TestCase.skipTest（）を呼び出すだけです。 setUp（）またはテストメソッド、または SkipTest を直接発生させます。

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

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

    def test_maybe_skipped(self):
        if not external_resource_available():
            self.skipTest("external resource not available")
        # test code that depends on the external resource
        pass

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

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

----------------------------------------------------------------------
Ran 4 tests in 0.005s

OK (skipped=4)

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

@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（）は実行されません。 スキップされたモジュールでは、setUpModule()またはtearDownModule()は実行されません。


サブテストを使用してテストの反復を区別する

バージョン3.4の新機能。


一部のパラメーターなど、テスト間に非常に小さな違いがある場合、unittestでは、 subTest（）コンテキストマネージャーを使用して、テストメソッドの本体内でそれらを区別できます。

たとえば、次のテスト： 

class NumbersTest(unittest.TestCase):

    def test_even(self):
        """
        Test that numbers between 0 and 5 are all even.
        """
        for i in range(0, 6):
            with self.subTest(i=i):
                self.assertEqual(i % 2, 0)

次の出力が生成されます。 

======================================================================
FAIL: test_even (__main__.NumbersTest) (i=1)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 32, in test_even
    self.assertEqual(i % 2, 0)
AssertionError: 1 != 0

======================================================================
FAIL: test_even (__main__.NumbersTest) (i=3)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 32, in test_even
    self.assertEqual(i % 2, 0)
AssertionError: 1 != 0

======================================================================
FAIL: test_even (__main__.NumbersTest) (i=5)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 32, in test_even
    self.assertEqual(i % 2, 0)
AssertionError: 1 != 0

サブテストを使用しないと、最初の失敗後に実行が停止し、iの値が表示されないため、エラーの診断が容易になりません。 

======================================================================
FAIL: test_even (__main__.NumbersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 32, in test_even
    self.assertEqual(i % 2, 0)
AssertionError: 1 != 0

クラスと関数

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

テストケース

class unittest.TestCase(methodName='runTest')

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

TestCase の各インスタンスは、 methodName という名前のメソッドという単一の基本メソッドを実行します。 TestCase のほとんどの使用法では、 methodName を変更したり、デフォルトのrunTest()メソッドを再実装したりすることはありません。

バージョン3.2での変更： TestCase は、 methodName を指定しなくても正常にインスタンス化できます。 これにより、インタラクティブインタプリタから TestCase を簡単に試すことができます。

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

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

setUp()

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

tearDown()

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

setUpClass()

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

@classmethod
def setUpClass(cls):
    ...

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

バージョン3.2の新機能。

tearDownClass()

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

@classmethod
def tearDownClass(cls):
    ...

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

バージョン3.2の新機能。

run(result=None)

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

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

バージョン3.3で変更：以前のバージョンのrunは結果を返しませんでした。 インスタンスの呼び出しもしませんでした。

skipTest(reason)

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

バージョン3.1の新機能。

subTest(msg=None, **params)

同封のコードブロックをサブテストとして実行するコンテキストマネージャーを返します。 msg および params はオプションの任意の値であり、サブテストが失敗するたびに表示されるため、明確に識別できます。

テストケースには、任意の数のサブテスト宣言を含めることができ、それらは任意にネストできます。

詳細については、サブテストを使用したテスト反復の識別を参照してください。

バージョン3.4の新機能。

debug()

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

TestCase クラスは、失敗をチェックして報告するためのいくつかのアサートメソッドを提供します。 次の表に、最も一般的に使用されるメソッドを示します（その他の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

3.1

assertIsNot(a, b)

a is not b

3.1

assertIsNone(x)

x is None

3.1

assertIsNotNone(x)

x is not None

3.1

assertIn(a, b)

a in b

3.1

assertNotIn(a, b)

a not in b

3.1

assertIsInstance(a, b)

isinstance(a, b)

3.2

assertNotIsInstance(a, b)

not isinstance(a, b)

3.2

すべてのassertメソッドは、 msg 引数を受け入れます。この引数は、指定されている場合、失敗時のエラーメッセージとして使用されます（ longMessage も参照）。 msg キーワード引数は、 assertRaises（）、 assertRaisesRegex（）、 assertWarns（）、 assertWarnsRegexに渡すことができることに注意してください。 （）コンテキストマネージャーとして使用される場合のみ。

assertEqual(first, second, msg=None)

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

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

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

バージョン3.2で変更： assertMultiLineEqual（）が、文字列を比較するためのデフォルトの型等価関数として追加されました。

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 が同じオブジェクトである（または同じでない）ことをテストします。

バージョン3.1の新機能。

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

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

バージョン3.1の新機能。

assertIn(member, container, msg=None)
assertNotIn(member, container, msg=None)

メンバーがコンテナにある（またはない）ことをテストします。

バージョン3.1の新機能。

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

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

バージョン3.2の新機能。

次の方法を使用して、例外、警告、およびログメッセージの生成を確認することもできます。

方法

それをチェックします

の新機能

assertRaises(exc, fun, *args, **kwds)

fun(*args, **kwds)は exc を発生させます

assertRaisesRegex(exc, r, fun, *args, **kwds)

fun(*args, **kwds)は exc を発生させ、メッセージは正規表現 r と一致します

3.1

assertWarns(warn, fun, *args, **kwds)

fun(*args, **kwds)は警告を発生させます

3.2

assertWarnsRegex(warn, r, fun, *args, **kwds)

fun(*args, **kwds)は警告を発生させ、メッセージは正規表現 r と一致します

3.2

assertLogs(logger, level)

withブロックは、最小レベルでロガーにログオンします。

3.4

assertRaises(exception, callable, *args, **kwds)
assertRaises(exception, *, msg=None)

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

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

with self.assertRaises(SomeException):
    do_something()

assertRaises（）は、コンテキストマネージャーとして使用される場合、追加のキーワード引数 msg を受け入れます。

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

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

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

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

バージョン3.2で変更： exception属性が追加されました。

バージョン3.3で変更：コンテキストマネージャーとして使用する場合に msg キーワード引数を追加しました。

assertRaisesRegex(exception, regex, callable, *args, **kwds)
assertRaisesRegex(exception, regex, *, msg=None)

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

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

また：

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

バージョン3.1の新機能： assertRaisesRegexpという名前で追加されました。

バージョン3.2で変更： assertRaisesRegex（）に名前が変更されました。

バージョン3.3で変更：コンテキストマネージャーとして使用する場合に msg キーワード引数を追加しました。

assertWarns(warning, callable, *args, **kwds)
assertWarns(warning, *, msg=None)

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

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

with self.assertWarns(SomeWarning):
    do_something()

assertWarns（）は、コンテキストマネージャーとして使用される場合、追加のキーワード引数 msg を受け入れます。

コンテキストマネージャーは、キャッチされた警告オブジェクトをwarning属性に格納し、警告をトリガーしたソース行をfilenameおよびlineno属性に格納します。 これは、キャッチされた警告に対して追加のチェックを実行することが目的の場合に役立ちます。

with self.assertWarns(SomeWarning) as cm:
    do_something()

self.assertIn('myfile.py', cm.filename)
self.assertEqual(320, cm.lineno)

このメソッドは、呼び出されたときに配置されている警告フィルターに関係なく機能します。

バージョン3.2の新機能。

バージョン3.3で変更：コンテキストマネージャーとして使用する場合に msg キーワード引数を追加しました。

assertWarnsRegex(warning, regex, callable, *args, **kwds)
assertWarnsRegex(warning, regex, *, msg=None)

assertWarns（）と同様ですが、トリガーされた警告のメッセージで regex が一致することもテストします。 regex は、正規表現オブジェクト、または re.search（）での使用に適した正規表現を含む文字列です。 例：

self.assertWarnsRegex(DeprecationWarning,
                      r'legacy_function\(\) is deprecated',
                      legacy_function, 'XYZ')

また：

with self.assertWarnsRegex(RuntimeWarning, 'unsafe frobnicating'):
    frobnicate('/etc/passwd')

バージョン3.2の新機能。

バージョン3.3で変更：コンテキストマネージャーとして使用する場合に msg キーワード引数を追加しました。

assertLogs(logger=None, level=None)

少なくとも1つのメッセージがロガーまたはその子の1つに、少なくとも指定されたレベルで記録されていることをテストするコンテキストマネージャー。

指定する場合、 logger は logging.Logger オブジェクトまたはロガーの名前を指定する str である必要があります。 デフォルトはルートロガーであり、伝播しない子孫ロガーによってブロックされなかったすべてのメッセージをキャッチします。

指定する場合、 level は、数値のログレベルまたはそれに相当する文字列（たとえば、"ERROR"またはlogging.ERROR）のいずれかである必要があります。 デフォルトはlogging.INFOです。

withブロック内で発行されたメッセージの少なくとも1つが logger および level の条件に一致する場合、テストは合格です。それ以外の場合は失敗します。

コンテキストマネージャーによって返されるオブジェクトは、一致するログメッセージを追跡する記録ヘルパーです。 これには2つの属性があります。

records

一致するログメッセージの logging.LogRecord オブジェクトのリスト。

output

一致するメッセージのフォーマットされた出力を含む str オブジェクトのリスト。

例：

with self.assertLogs('foo', level='INFO') as cm:
   logging.getLogger('foo').info('first message')
   logging.getLogger('foo.bar').error('second message')
self.assertEqual(cm.output, ['INFO:foo:first message',
                             'ERROR:foo.bar:second message'])

バージョン3.4の新機能。

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

方法

それをチェックします

の新機能

assertAlmostEqual(a, b)

round(a-b, 7) == 0

assertNotAlmostEqual(a, b)

round(a-b, 7) != 0

assertGreater(a, b)

a > b

3.1

assertGreaterEqual(a, b)

a >= b

3.1

assertLess(a, b)

a < b

3.1

assertLessEqual(a, b)

a <= b

3.1

assertRegex(s, r)

r.search(s)

3.1

assertNotRegex(s, r)

not r.search(s)

3.2

assertCountEqual(a, b)

a と b は、順序に関係なく、同じ番号の同じ要素を持っています。

3.2

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]デルタ。

delta と places の両方を指定すると、 TypeError が発生します。

バージョン3.2で変更： 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"

バージョン3.1の新機能。

assertRegex(text, regex, msg=None)
assertNotRegex(text, regex, msg=None)

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

バージョン3.1の新機能： assertRegexpMatchesという名前で追加されました。

バージョン3.2で変更：メソッドassertRegexpMatches()は assertRegex（）に名前が変更されました。

バージョン3.2の新機能： assertNotRegex（）。

バージョン3.5の新機能：名前assertNotRegexpMatchesは、 assertNotRegex（）の非推奨のエイリアスです。

assertCountEqual(first, second, msg=None)

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

最初のと 2番目のを比較する場合、重複する要素は無視されません。 各要素が両方のシーケンスで同じカウントを持っているかどうかを検証します。 assertEqual(Counter(list(first)), Counter(list(second)))と同等ですが、ハッシュ不可能なオブジェクトのシーケンスでも機能します。

バージョン3.2の新機能。

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

addTypeEqualityFunc(typeobj, function)

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

バージョン3.1の新機能。

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

方法

比較に使用

の新機能

assertMultiLineEqual(a, b)

文字列

3.1

assertSequenceEqual(a, b)

シーケンス

3.1

assertListEqual(a, b)

リスト

3.1

assertTupleEqual(a, b)

タプル

3.1

assertSetEqual(a, b)

セットまたは冷凍セット

3.1

assertDictEqual(a, b)

口述

3.1

assertMultiLineEqual(first, second, msg=None)

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

バージョン3.1の新機能。

assertSequenceEqual(first, second, msg=None, seq_type=None)

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

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

バージョン3.1の新機能。

assertListEqual(first, second, msg=None)
assertTupleEqual(first, second, msg=None)

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

バージョン3.1の新機能。

assertSetEqual(first, second, msg=None)

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

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

バージョン3.1の新機能。

assertDictEqual(first, second, msg=None)

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

バージョン3.1の新機能。

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

fail(msg=None)

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

failureException

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

longMessage

このクラス属性は、失敗したassertXYY呼び出しにカスタム失敗メッセージがmsg引数として渡されたときに何が起こるかを決定します。 Trueがデフォルト値です。 この場合、カスタムメッセージは標準の失敗メッセージの最後に追加されます。 Falseに設定すると、カスタムメッセージが標準メッセージに置き換わります。

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

クラス設定は、各テスト呼び出しの前にリセットされます。

バージョン3.1の新機能。

maxDiff

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

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

バージョン3.2の新機能。

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

countTestCases()

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

defaultTestResult()

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

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

id()

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

shortDescription()

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

バージョン3.1で変更： 3.1では、docstringが存在する場合でも、短い説明にテスト名を追加するように変更されました。 これにより、ユニットテスト拡張機能との互換性の問題が発生し、テスト名の追加がPython3.2の TextTestResult に移動されました。

addCleanup(function, *args, **kwargs)

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

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

バージョン3.1の新機能。

doCleanups()

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

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

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

バージョン3.1の新機能。

classmethod addClassCleanup(function, /, *args, **kwargs)

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

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

バージョン3.8の新機能。

classmethod doClassCleanups()

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

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

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

バージョン3.8の新機能。

class unittest.IsolatedAsyncioTestCase(methodName='runTest')

このクラスは、 TestCase と同様のAPIを提供し、テスト関数としてコルーチンも受け入れます。

バージョン3.8の新機能。

addAsyncCleanup(function, /, *args, **kwargs)

このメソッドは、クリーンアップ関数として使用できるコルーチンを受け入れます。

run(result=None)

テストを実行するための新しいイベントループを設定し、結果を result として渡された TestResult オブジェクトに収集します。 result を省略またはNoneの場合、一時的な結果オブジェクトが作成され（defaultTestResult()メソッドを呼び出すことにより）、使用されます。 結果オブジェクトは run（）の呼び出し元に返されます。 テストの終了時に、イベントループ内のすべてのタスクがキャンセルされます。

順序を示す例：

from unittest import IsolatedAsyncioTestCase

events = []


class Test(IsolatedAsyncioTestCase):


    def setUp(self):
        events.append("setUp")

    async def asyncSetUp(self):
        self._async_connection = await AsyncConnection()
        events.append("asyncSetUp")

    async def test_response(self):
        events.append("test_response")
        response = await self._async_connection.get("https://example.com")
        self.assertEqual(response.status_code, 200)
        self.addAsyncCleanup(self.on_cleanup)

    def tearDown(self):
        events.append("tearDown")

    async def asyncTearDown(self):
        await self._async_connection.close()
        events.append("asyncTearDown")

    async def on_cleanup(self):
        events.append("cleanup")

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

テストの実行後、eventsには["setUp", "asyncSetUp", "test_response", "asyncTearDown", "tearDown", "cleanup"]が含まれます。

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

非推奨のエイリアス

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

メソッド名 非推奨のエイリアス 非推奨のエイリアス
assertEqual() failUnlessEqual assertEquals
assertNotEqual() failIfEqual assertNotEquals
assertTrue() 失敗しない限り 主張する_
assertFalse() failIf
assertRaises() failUnlessRaises
assertAlmostEqual() failUnlessAlmostEqual assertAlmostEquals
assertNotAlmostEqual() failIfAlmostEqual assertNotAlmostEquals
assertRegex() assertRegexpMatches
assertNotRegex() assertNotRegexpMatches
assertRaisesRegex() assertRaisesRegexp

バージョン3.1以降非推奨： 2番目の列にリストされているfail *エイリアスは非推奨になりました。


バージョン3.2以降非推奨： 3番目の列にリストされているassert *エイリアスは非推奨になりました。


バージョン3.2以降非推奨： assertRegexpMatchesおよびassertRaisesRegexpは assertRegex（）および assertRaisesRegex（）に名前が変更されました。


バージョン3.5以降非推奨： assertNotRegexpMatches名は非推奨になり、 assertNotRegex（）が優先されます。


グループ化テスト

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 __（）をオーバーライドすることにより、遅延テストを提供できます。 このメソッドは単一のスイートで複数回呼び出される可能性があるため（たとえば、テストをカウントしたり、等しいかどうかを比較したりする場合）、 TestSuite.run（）の前に繰り返される反復によって返されるテストは各呼び出しで同じである必要があります。反復。 TestSuite.run（）の後、呼び出し元がTestSuite._removeTestAtIndex()をオーバーライドしてテスト参照を保持するサブクラスを使用しない限り、呼び出し元はこのメソッドによって返されるテストに依存しないでください。

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

バージョン3.4での変更：以前のバージョンでは、 TestSuite は、 TestSuite.run（）の後に各 TestCase への参照を保持していました。 サブクラスは、TestSuite._removeTestAtIndex()をオーバーライドすることにより、その動作を復元できます。

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


テストの読み込みと実行

class unittest.TestLoader

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

TestLoader オブジェクトには、次の属性があります。

errors

テストのロード中に発生した致命的でないエラーのリスト。 どの時点でもローダーによってリセットされません。 致命的なエラーは、呼び出し元に例外を発生させる関連するメソッドによって通知されます。 致命的でないエラーは、実行時に元のエラーを発生させる合成テストによっても示されます。

バージョン3.5の新機能。

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

loadTestsFromTestCase(testCaseClass)

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

テストケースインスタンスは、 getTestCaseNames（）で指定されたメソッドごとに作成されます。 デフォルトでは、これらはtestで始まるメソッド名です。 getTestCaseNames（）がメソッドを返さないが、runTest()メソッドが実装されている場合、代わりにそのメソッドに対して単一のテストケースが作成されます。

loadTestsFromModule(module, pattern=None)

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

ノート

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

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

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

バージョン3.5で変更：文書化されていない非公式の use_load_tests のデフォルト引数は非推奨になり、無視されますが、下位互換性のために引き続き受け入れられます。 このメソッドは、3番目の引数としてload_testsに渡されるキーワードのみの引数 pattern も受け入れるようになりました。

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()テストメソッドのみを実行するテストスイートが返されます。 指定子は、インポートされていないモジュールおよびパッケージを参照できます。 それらは副作用としてインポートされます。

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

バージョン3.5で変更： ImportError または AttributeError が name のトラバース中に発生した場合、実行時にそのエラーを発生させる合成テストは次のようになります。戻ってきた。 これらのエラーは、self.errorsによって累積されたエラーに含まれます。

loadTestsFromNames(names, module=None)

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

getTestCaseNames(testCaseClass)

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

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

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

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

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

パッケージ（__init__.pyという名前のファイルを含むディレクトリ）が見つかった場合、そのパッケージはload_tests関数についてチェックされます。 これが存在する場合は、package.load_tests(loader, tests, pattern)と呼ばれます。 テスト検出は、load_tests関数自体がloader.discoverを呼び出した場合でも、呼び出し中にパッケージのテストが1回だけチェックされるように注意します。

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

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

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

バージョン3.2の新機能。

バージョン3.4で変更：インポート時に SkipTest を発生させるモジュールは、エラーではなくスキップとして記録されます。

バージョン3.4で変更： start_dir は名前空間パッケージにすることができます。

バージョン3.4で変更：パスはインポートされる前にソートされるため、基になるファイルシステムの順序がファイル名に依存していなくても実行順序は同じです。

バージョン3.5での変更：見つかったパッケージは、パスがパターンと一致するかどうかに関係なく、load_testsについてチェックされるようになりました。これは、パッケージ名がデフォルトのパターンと一致することができないためです。 。

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

testMethodPrefix

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

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

sortTestMethodsUsing

getTestCaseNames（）およびすべてのloadTestsFrom*()メソッドでメソッド名を並べ替えるときにメソッド名を比較するために使用される関数。

suiteClass

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

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

testNamePatterns

テストスイートに含めるためにテストメソッドが一致する必要があるUnixシェルスタイルのワイルドカードテスト名パターンのリスト（-vオプションを参照）。

この属性がNone（デフォルト）でない場合、テストスイートに含まれるすべてのテストメソッドは、このリストのパターンの1つと一致する必要があります。 一致は常に fnmatch.fnmatchcase（）を使用して実行されるため、-vオプションに渡されるパターンとは異なり、単純なサブストリングパターンは*ワイルドカードを使用して変換する必要があります。

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

バージョン3.7の新機能。

class unittest.TestResult

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

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

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

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

errors

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

failures

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

skipped

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

バージョン3.1の新機能。

expectedFailures

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

unexpectedSuccesses

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

shouldStop

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

testsRun

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

buffer

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

バージョン3.2の新機能。

failfast

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

バージョン3.2の新機能。

tb_locals

trueに設定すると、ローカル変数がトレースバックに表示されます。

バージョン3.5の新機能。

wasSuccessful()

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

バージョン3.4で変更： expectedFailure（）デコレータでマークされたテストから unexpectedSuccesses があった場合、はFalseを返します。

stop()

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

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

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

startTest(test)

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

stopTest(test)

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

startTestRun()

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

バージョン3.1の新機能。

stopTestRun()

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

バージョン3.1の新機能。

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 属性にテストが追加されます。

addSubTest(test, subtest, outcome)

サブテストが終了したときに呼び出されます。 test は、テスト方法に対応するテストケースです。 subtest は、サブテストを説明するカスタム TestCase インスタンスです。

結果がなしの場合、サブテストは成功しました。 それ以外の場合は、 results が sys.exc_info（）によって返される形式のタプル(type, value, traceback)であるという例外を除いて失敗しました。

デフォルトの実装は、結果が成功の場合は何もせず、サブテストの失敗を通常の失敗として記録します。

バージョン3.4の新機能。

class unittest.TextTestResult(stream, descriptions, verbosity)

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

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

unittest.defaultTestLoader
共有を目的とした TestLoader クラスのインスタンス。 TestLoader のカスタマイズが必要ない場合は、新しいインスタンスを繰り返し作成する代わりに、このインスタンスを使用できます。
class unittest.TextTestRunner(stream=None, descriptions=True, verbosity=1, failfast=False, buffer=False, resultclass=None, warnings=None, *, tb_locals=False)

結果をストリームに出力する基本的なテストランナーの実装。 stream がNoneの場合、デフォルトの sys.stderr が出力ストリームとして使用されます。 このクラスにはいくつかの構成可能なパラメーターがありますが、基本的に非常に単純です。 テストスイートを実行するグラフィカルアプリケーションは、代替の実装を提供する必要があります。 このような実装では、ユニットテストに機能が追加されたときにランナーの変更を構築するためのインターフェイスとして**kwargsを受け入れる必要があります。

デフォルトでは、このランナーは、デフォルトで無視されている場合でも、 DeprecationWarning 、 PendingDeprecationWarning 、 ResourceWarning 、および ImportWarning を表示します。 非推奨のユニットテストメソッドによって引き起こされる非推奨の警告も特殊なケースであり、警告フィルターが'default'または'always'の場合、モジュールごとに1回だけ順番に表示されます。警告メッセージが多すぎないようにします。 この動作は、Pythonの-Wdまたは-Waオプション（警告制御を参照）を使用してオーバーライドし、警告をNoneのままにすることができます。

バージョン3.2で変更： warnings引数を追加しました。

バージョン3.2で変更：デフォルトのストリームは、インポート時ではなくインスタンス化時に sys.stderr に設定されます。

バージョン3.5で変更： tb_localsパラメーターを追加しました。

_makeResult()

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

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

stream, descriptions, verbosity
run(test)

このメソッドは、TextTestRunnerへの主要なパブリックインターフェイスです。 このメソッドは、 TestSuite または TestCase インスタンスを取ります。 TestResult は、 _makeResult（）を呼び出すことによって作成され、テストが実行され、結果がstdoutに出力されます。

unittest.main(module='__main__', defaultTest=None, argv=None, testRunner=None, testLoader=unittest.defaultTestLoader, exit=True, verbosity=1, failfast=None, catchbreak=None, buffer=None, warnings=None)

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

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 パラメーターは、同じ名前のコマンドラインオプションと同じ効果があります。

warnings 引数は、テストの実行中に使用する必要がある warning filter を指定します。 指定されていない場合、-Wオプションが python に渡されるとNoneのままになります（警告制御を参照）。そうでない場合は設定されます。 'default'に。

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

バージョン3.1で変更： exit パラメーターが追加されました。

バージョン3.2で変更： 冗長性、フェイルファスト、キャッチブレイク、バッファー、警告[X129X ]パラメータが追加されました。

バージョン3.4で変更： defaultTest パラメーターが変更され、反復可能なテスト名も受け入れるようになりました。

load_testsプロトコル

バージョン3.2の新機能。


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

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

load_tests(loader, standard_tests, pattern)

ここで、パターンはloadTestsFromModuleから直接渡されます。 デフォルトは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の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

バージョン3.5での変更：デフォルトのパターンに一致するパッケージ名が不可能なため、 Discoveryはパターンに一致するパッケージ名をチェックしなくなりました。


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

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

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

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

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

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

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

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

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 例外の場合、クラスはエラーではなくスキップされたものとして報告されます。


setUpModuleおよびtearDownModule

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

def setUpModule():
    createConnection()

def tearDownModule():
    closeConnection()

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

例外が発生した場合でも実行する必要のあるクリーンアップコードを追加するには、addModuleCleanupを使用します。

unittest.addModuleCleanup(function, /, *args, **kwargs)

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

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

バージョン3.8の新機能。

unittest.doModuleCleanups()

この関数は、tearDownModule()の後、またはsetUpModule()が例外を発生させた場合はsetUpModule()の後に無条件に呼び出されます。

addCleanupModule()によって追加されたすべてのクリーンアップ関数を呼び出す責任があります。 前からtearDownModule()にクリーンアップ関数を呼び出す必要がある場合は、 doModuleCleanups（）を自分で呼び出すことができます。

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

バージョン3.8の新機能。


信号処理

バージョン3.2の新機能。


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（）が呼び出されます。
unittest.registerResult(result)

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

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

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

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

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



「https://www.finddevguides.com/index.php?title=Python/docs/3.8/library/unittest&oldid=99236」から取得
Powered by MediaWiki