"unittest" --- ユニットテストフレームワーク
*******************************************

**ソースコード:** Lib/unittest/__init__.py

======================================================================

(すでにテストの基本概念について詳しいようでしたら、この部分をとばして
アサートメソッド一覧 に進むと良いでしょう。)

"unittest" ユニットテストフレームワークは、もともと JUnit に着想を得た
もので、他の言語の主要なユニットテストフレームワークと似た構成を持ちま
す。 テストの自動化、テストの準備・終了処理の共有、複数のテストの集約
、レポート出力の仕組みからのテストの独立をサポートします。

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

テストフィクスチャ (test fixture)
   テストフィクスチャ (*test fixture*) とは、テスト実行のために必要な
   準備や終了処理を指します。例: テスト用データベースの作成・ディレク
   トリ・サーバプロセスの起動など。

テストケース (test case)
   テストケース (*test case*) は、個々のテストの単位です。 特定の入力
   の組に対し、所定の応答が得られることを確認します。 "unittest" は、
   新しいテストケースを作成するための基底クラス "TestCase" を提供しま
   す。

テストスイート (test suite)
   テストスイート (*test suite*) は、テストケース、テストスイート、ま
   たはその両方の集まりです。 まとめて実行するテストを集約するために使
   います。

テストランナー (test runner)
   テストランナー (*test runner*) はテストの実行を管理し結果を提供する
   要素です。ランナーはグラフィカルインターフェースやテキストインター
   フェースを使用しても構いませんし、テストの実行結果を示す特別な値を
   返しても構いません。

参考:

  "doctest" モジュール
     テストをサポートするもうひとつのモジュールで、このモジュールとは
     趣きがだいぶ異なります。

  Simple Smalltalk Testing: With Patterns
     "unittest" と共通のパターンを使ったテストフレームワークについての
     、Kent Beck による原論文。

  pytest
     サードパーティのユニットテストフレームワークでより軽量な構文でテ
     ストを書くことができます。例えば、"assert func(10) == 42"  のよう
     に書きます。

  The Python Testing Tools Taxonomy
     多くの Python のテストツールが一覧で紹介されています。ファンクシ
     ョナルテストのフレームワークやモックライブラリも掲載されています
     。

  Testing in Python メーリングリスト
     Python でテストやテストツールについての議論に特化したグループです
     。

  Python のソースコード配布物にあるスクリプト
  "Tools/unittestgui/unittestgui.py" はテストディスカバリとテスト実行
  のための GUI ツールです。 主な目的は単体テストの初心者が簡単に使える
  ようにすることです。 実際の生産環境では、 Buildbot, Jenkins 、
  GitHub Actions, AppVeyor のような継続的インテグレーションシステムで
  テストを実行することを推奨します。


基本的な例
==========

"unittest" モジュールは、テストを構築して実行するための豊富なツールを
提供します。 この節では、そのごく一部だけで、ほとんどの利用者の要求を
満たせることを示します。

以下は、三つの文字列メソッドをテストするスクリプトです:

   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'])
           # 区切りが文字列でない場合に s.split が失敗することを確認する
           with self.assertRaises(TypeError):
               s.split(2)

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

テストケースは、 "unittest.TestCase" のサブクラスとして作成します。メ
ソッド名が "test" で始まる三つのメソッドがテストです。テストランナーは
この命名規約によってテストを行うメソッドを検索します。

これらのテスト内では、予定の結果が得られていることを確かめるために
"assertEqual()" を、条件のチェックに "assertTrue()" や "assertFalse()"
を、例外が発生する事を確認するために "assertRaises()" をそれぞれ呼び出
しています。 "assert" 文の代わりにこれらのメソッドを使用すると、テスト
ランナーでテスト結果を集計してレポートを作成する事ができます。

"setUp()" および "tearDown()" メソッドによって各テストメソッドの前後に
実行する命令を実装することが出来ます。 詳細は テストコードの構成 を参
照してください。

最後のブロックは簡単なテストの実行方法を示しています。
"unittest.main()" は、テストスクリプトのコマンドライン用インターフェー
スを提供します。コマンドラインから起動された場合、上記のスクリプトは以
下のような結果を出力します:

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

   OK

"-v" オプションをテストスクリプトに渡すことで "unittest.main()" はより
冗長になり、以下のような出力をします:

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

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

   OK

上の例で紹介した "unittest" のよく使われる機能で、日常的なテストの多く
をまかなえます。 この先のドキュメントでは、すべての機能を基礎から説明
します。

バージョン 3.11 で変更: テストメソッドが（デフォルトの "None" 以外の）
戻り値を返す挙動は現在非推奨です。


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

ユニットテストモジュールはコマンドラインから使って、モジュール、クラス
、あるいは個別のテストメソッドで定義されたテストを実行することが出来ま
す:

   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

引数無しで実行すると テストディスカバリ が開始されます:

   python -m unittest

コマンドラインプションの一覧を表示するには以下のコマンドを実行します:

   python -m unittest -h

バージョン 3.2 で変更: 以前のバージョンでは、個々のテストメソッドしか
実行することができず、モジュール単位やクラス単位で実行することは不可能
でした。

Added in version 3.14: 出力はデフォルトで色付きになり、環境変数で制御
できます。


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

**unittest** には以下のコマンドラインオプションがあります:

-b, --buffer

   標準出力と標準エラーのストリームをテストの実行中にバッファします。
   テストが成功している間は結果の出力は破棄されます。テストの失敗やエ
   ラーの場合、出力は通常通り表示され、エラーメッセージに追加されます
   。

-c, --catch

   "Control"-"C" を実行中のテストが終了するまで遅延させ、そこまでの結
   果を出力します。二回目の "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

   トレースバック内の局所変数を表示します。

--durations N

   実行に時間がかかったテストケースを、遅い順に N 件表示します (N=0 で
   すべて表示)。

Added in version 3.2: コマンドラインオプションの "-b"、"-c"、"-f" が追
加されました。

Added in version 3.5: コマンドラインオプション "--locals"。

Added in version 3.7: コマンドラインオプション "-k"。

Added in version 3.12: コマンドラインオプション "--durations"。

コマンドラインによってテストディスカバリ、すなわちプロジェクトの全テス
トを実行したりサブセットのみを実行したりすることも出来ます。


テストディスカバリ
==================

Added in version 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" オプションは、この順番であれば位置引数とし
て渡す事ができます。以下の二つのコマンドは等価です:

   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" としてインポートされます。グローバ
  ルにインストールされたパッケージがあり、それとは異なるコピーでディス
  カバリしようとしたとき、誤った場所からインポートが行われる *かもしれ
  ません*。 その場合テストディスカバリは警告し、停止します。ディレクト
  リのパスではなくパッケージ名を開始ディレクトリに指定した場合、ディス
  カバリはインポートするいずれの場所も意図した場所とするため、警告を受
  けないはずです。

テストモジュールとパッケージは、 load_tests プロトコル によってテスト
のロードとディスカバリをカスタマイズすることができます。

バージョン 3.4 で変更: ディスカバリが *名前空間パッケージ* をサポート
しました。

バージョン 3.11 で変更: テストディスカバリでの *名前空間パッケージ* の
サポートが削除されました。 この機能は Python 3.7 以降、正常に動作して
いませんでした。 開始ディレクトリと、テストを含むそのサブディレクトリ
は、"__init__.py" ファイルを持つ通常のパッケージでなければなりません。
開始ディレクトリをパッケージのドット区切りの名前で指定する場合、上位の
パッケージは名前空間パッケージでもかまいません。

バージョン 3.14 で変更: 開始ディレクトリとして *名前空間パッケージ* を
再びサポートするようになりました。 Python と無関係なディレクトリの走査
を避けるため、"__init__.py" のないサブディレクトリ内ではテストを検索し
ません。


テストコードの構成
==================

ユニットテストの基本単位はテストケース (*test cases*) です。 それぞれ
が、準備を行い、正しさを確認する 1 つのシナリオに相当します。
"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* メソッド のいずれ
かを使います。 テストが失敗すると、理由を説明するメッセージを伴う例外
が送出され、"unittest" はそのテストケースを失敗 (*failure*) として扱い
ます。 それ以外の例外はエラー (*errors*) として扱います。

テストは多くなり、それらの設定は繰り返しになるかもしれません。 幸いに
も、"setUp()" メソッドを実装することで設定コードをくくり出すことができ
ます。 テストフレームワークは実行するテストごとに自動的に "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()" が実行されます。

そのようなテストコードのための作業環境は *テストフィクスチャ (test
fixture)* と呼ばれます。 新しい TestCase インスタンスはある単一のテス
トフィクスチャとして作成され、個々のテストメソッドを実行するのに使われ
ます。 従って、 "setUp()", "tearDown()", "TestCase.__init__()" は1回の
テストにつき1回だけ呼び出されます。

TestCase の実装を使い、テスト対象の機能に応じてテストをまとめることを
推奨します。 "unittest" はそのための仕組みとして、"unittest" の
"TestSuite" クラスで表されるテストスイート (*test suite*) を提供します
。 ほとんどの場合、"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
       # ...

オプションの set-up と tear-down メソッドを持った同等のテストケースイ
ンスタンスは次のように作成します:

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

注釈:

  "FunctionTestCase" を使うと、既存のテスト群を "unittest" ベースの仕
  組みに素早く移行できますが、この方法は推奨しません。 時間をかけて適
  切な "TestCase" のサブクラスを作成する方が、将来のテストのリファクタ
  リングがはるかに容易になります。

既存のテストが "doctest" を使って書かれている場合もあるでしょう。その
場合、 "doctest" は "DocTestSuite" クラスを提供します。このクラスは、
既存の "doctest"ベースのテストから、自動的に "unittest.TestSuite" のイ
ンスタンスを作成します。


テストのスキップと予期された失敗
================================

Added in version 3.1.

unittest は特定のテストメソッドやテストクラス全体をスキップする仕組み
を備えています。さらに、この機能はテスト結果を「予期された失敗
(expected failure)」とすることができ、テストが失敗しても "TestResult"
の失敗数にはカウントされなくなります。

テストをスキップするには、"@skip" *デコレータ* や条件付きの派生デコレ
ータを使う、"setUp()" またはテストメソッド内で "TestCase.skipTest()"
を呼び出す、あるいは "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):
           # ライブラリの特定のバージョンでだけ動作するテスト
           pass

       @unittest.skipUnless(sys.platform.startswith("win"), "requires Windows")
       def test_windows_support(self):
           # Windows 固有のテストコード
           pass

       def test_maybe_skipped(self):
           if not external_resource_available():
               self.skipTest("external resource not available")
           # 外部リソースに依存するテストコード
           pass

このサンプルを冗長モードで実行すると以下のように出力されます:

   test_format (__main__.MyTestCase.test_format) ... skipped 'not supported in this library version'
   test_nothing (__main__.MyTestCase.test_nothing) ... skipped 'demonstrating skipping'
   test_maybe_skipped (__main__.MyTestCase.test_maybe_skipped) ... skipped 'external resource not available'
   test_windows_support (__main__.MyTestCase.test_windows_support) ... 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)

   *condition* が真の場合、デコレートしたテストをスキップします。

@unittest.skipUnless(condition, reason)

   *condition* が偽の場合、デコレートしたテストをスキップします。

@unittest.expectedFailure

   失敗またはエラーが予期されるテストとしてマークします。 *test
   fixture* のメソッドではなくテスト関数自体で失敗またはエラーが起きた
   場合は、成功とみなされます。 テストが成功した場合は、失敗とみなされ
   ます。

exception unittest.SkipTest(reason)

   この例外はテストをスキップするために送出されます。

   ふつうはこれを直接送出する代わりに "TestCase.skipTest()" やスキッピ
   ングデコレータの一つを使用出来ます。

スキップされるテストでは、前後の "setUp()" と "tearDown()" は実行され
ません。 スキップされるクラスでは、"setUpClass()" と "tearDownClass()"
は実行されません。 スキップされるモジュールでは、"setUpModule()" と
"tearDownModule()" は実行されません。


サブテストを利用して繰り返しテストの区別を付ける
================================================

Added in version 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.test_even) (i=1)
   Test that numbers between 0 and 5 are all even.
   ----------------------------------------------------------------------
   Traceback (most recent call last):
     File "subtests.py", line 11, in test_even
       self.assertEqual(i % 2, 0)
       ^^^^^^^^^^^^^^^^^^^^^^^^^^
   AssertionError: 1 != 0

   ======================================================================
   FAIL: test_even (__main__.NumbersTest.test_even) (i=3)
   Test that numbers between 0 and 5 are all even.
   ----------------------------------------------------------------------
   Traceback (most recent call last):
     File "subtests.py", line 11, in test_even
       self.assertEqual(i % 2, 0)
       ^^^^^^^^^^^^^^^^^^^^^^^^^^
   AssertionError: 1 != 0

   ======================================================================
   FAIL: test_even (__main__.NumbersTest.test_even) (i=5)
   Test that numbers between 0 and 5 are all even.
   ----------------------------------------------------------------------
   Traceback (most recent call last):
     File "subtests.py", line 11, in test_even
       self.assertEqual(i % 2, 0)
       ^^^^^^^^^^^^^^^^^^^^^^^^^^
   AssertionError: 1 != 0

サブテスト無しの場合、最初の失敗で実行は停止し、"i" の値が表示されない
ためエラーの原因を突き止めるのは困難になります:

   ======================================================================
   FAIL: test_even (__main__.NumbersTest.test_even)
   ----------------------------------------------------------------------
   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つ目のグループはテストの実行で使用されます。 2つ目のグループは条件
   のチェックおよび失敗のレポートを行うテストの実装で使用されます。 3
   つ目のグループである問い合わせ用のメソッドによってテスト自身の情報
   が収集されます。

   はじめのグループ (テスト実行) に含まれるメソッドは以下の通りです:

   setUp()

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

   tearDown()

      テストメソッドが実行され、結果が記録された直後に呼び出されるメソ
      ッドです。 このメソッドはテストメソッドで例外が投げられても呼び
      出されます。 そのため、サブクラスでこのメソッドを実装する場合は
      、内部状態を確認することが必要になるでしょう。 このメソッドで
      "AssertionError" や "SkipTest" 以外の例外が発生した場合、テスト
      の失敗とは別のエラーとみなされます (従って報告されるエラーの総数
      は増えます)。 このメソッドは、テストの結果に関わらず "setUp()"
      が成功した場合にのみ呼ばれます。 デフォルトの実装では何も行いま
      せん。

   setUpClass()

      個々のクラスのテストを実行する前に呼び出されるクラスメソッドです
      。 "setUpClass" はクラスを唯一の引数として呼び出され、
      "@classmethod" でデコレートする必要があります。

         @classmethod
         def setUpClass(cls):
             ...

      詳しくは クラスとモジュールのフィクスチャ を参照してください。

      Added in version 3.2.

   tearDownClass()

      個々のクラスのテストを実行した後に呼び出されるクラスメソッドです
      。 "tearDownClass" はクラスを唯一の引数として呼び出され、
      "@classmethod" でデコレートする必要があります。

         @classmethod
         def tearDownClass(cls):
             ...

      詳しくは クラスとモジュールのフィクスチャ を参照してください。

      Added in version 3.2.

   run(result=None)

      テストを実行し、テスト結果を *result* に指定された "TestResult"
      オブジェクトにまとめます。 *result* が省略されるか "None" が渡さ
      れた場合、 ("defaultTestResult()" メソッドを呼んで)  一時的な結
      果オブジェクトを生成し、使用します。 結果オブジェクトは "run()"
      の呼び出し元に返されます。

      このメソッドは、単に "TestCase" インスタンスを呼び出した場合と同
      様に振る舞います。

      バージョン 3.3 で変更: 以前のバージョンの "run" は結果オブジェク
      トを返しませんでした。また "TestCase" インスタンスを呼び出した場
      合も同様でした。

   skipTest(reason)

      テストメソッドや "setUp()" の中で呼び出すと、現在のテストをスキ
      ップします。 詳しくは テストのスキップと予期された失敗 を参照し
      てください。

      Added in version 3.1.

   subTest(msg=None, **params)

      with ブロック内のコードをサブテストとして実行するコンテキストマ
      ネージャを返します。 *msg* と *params* は省略可能な任意の値で、
      サブテストが失敗すると表示されるため、サブテストを明確に識別でき
      ます。

      テストケースには subtest 宣言を幾らでも含めることができ、任意に
      ネストすることができます。

      詳細は サブテストを利用して繰り返しテストの区別を付ける を参照し
      てください。

      Added in version 3.4.

   debug()

      テスト結果を収集せずにテストを実行します。例外が呼び出し元に通知
      されます。また、テストをデバッガで実行することができます。

   "TestCase" クラスは失敗の検査と報告を行う多くのメソッドを提供してい
   ます。 以下の表は最も一般的に使われるメソッドを列挙しています (より
   多くのアサートメソッドについては表の下を見てください):

   +-------------------------------------------+-------------------------------+-----------------+
   | メソッド                                  | 確認事項                      | 初出            |
   |===========================================|===============================|=================|
   | "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             |
   +-------------------------------------------+-------------------------------+-----------------+
   | "assertIsSubclass(a, b)"                  | "issubclass(a, b)"            | 3.14            |
   +-------------------------------------------+-------------------------------+-----------------+
   | "assertNotIsSubclass(a, b)"               | "not issubclass(a, b)"        | 3.14            |
   +-------------------------------------------+-------------------------------+-----------------+

   全てのアサートメソッドは *msg* 引数を受け取り、指定された場合、失敗
   時のエラーメッセージとして使われます。 ("longMessage" も参照してく
   ださい)。 *msg* キーワード引数は "assertRaises()" 、
   "assertRaisesRegex()" 、 "assertWarns()" 、 "assertWarnsRegex()" に
   は、そのメソッドをコンテキストマネージャとして使った場合にのみ使え
   ます。

   assertEqual(first, second, msg=None)

      *first* と *second* が等しいことをテストします。両者が等しくない
      場合、テストは失敗です。

      さらに、*first* と *second* が厳密に同じ型であり、 その型が list
      、tuple、dict、set、frozenset、str のいずれか、 またはサブクラス
      が "addTypeEqualityFunc()" で登録した型の場合は、 より有用なデフ
      ォルトのエラーメッセージを生成するために、その型に固有の等価性判
      定関数が呼ばれます (型固有のメソッドの一覧 も参照してください)。

      バージョン 3.1 で変更: 自動で型固有の比較関数が呼ばれるようにな
      りました。

      バージョン 3.2 で変更: 文字列比較のデフォルトの比較関数として
      "assertMultiLineEqual()" が追加されました。

   assertNotEqual(first, second, msg=None)

      *first* と *second* が等しくないことをテストします。両者が等しい
      場合、テストは失敗です。

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

      Added in version 3.1.

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

      *expr* が "None" であること (および、そうでないこと) をテストし
      ます。

      Added in version 3.1.

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

      *member* が *container* に含まれること (またはそうでないこと) を
      テストします。

      Added in version 3.1.

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

      *obj* が *cls* のインスタンスであること (あるいはそうでないこと)
      をテストします (この *cls* は、 "isinstance()" が扱うことのでき
      る、クラスもしくはクラスのタプルである必要があります)。正確な型
      をチェックするためには、 "assertIs(type(obj), cls)" を使用してく
      ださい。

      Added in version 3.2.

   assertIsSubclass(cls, superclass, msg=None)
   assertNotIsSubclass(cls, superclass, msg=None)

      *cls* が *superclass* のサブクラスであること (またはそうでないこ
      と) をテストします。 *superclass* には "issubclass()" と同様に、
      クラスまたはクラスのタプルを指定できます。 型が厳密に一致するか
      調べるには "assertIs(cls, superclass)" を使ってください。

      Added in version 3.14.

   以下のメソッドを使用して例外、警告、およびログメッセージの発生を確
   認することが出来ます:

   +-----------------------------------------------------------+----------------------------------------+--------------+
   | メソッド                                                  | 確認事項                               | 初出         |
   |===========================================================|========================================|==============|
   | "assertRaises(exc, fun, *args, **kwds)"                   | "fun(*args, **kwds)" が *exc* を送出す |              |
   |                                                           | る                                     |              |
   +-----------------------------------------------------------+----------------------------------------+--------------+
   | "assertRaisesRegex(exc, r, fun, *args, **kwds)"           | "fun(*args, **kwds)" が *exc* を送出し | 3.1          |
   |                                                           | てメッセージが正規表現 *r* と マッチす |              |
   |                                                           | る                                     |              |
   +-----------------------------------------------------------+----------------------------------------+--------------+
   | "assertWarns(warn, fun, *args, **kwds)"                   | "fun(*args, **kwds)" が *warn* を送出  | 3.2          |
   |                                                           | する                                   |              |
   +-----------------------------------------------------------+----------------------------------------+--------------+
   | "assertWarnsRegex(warn, r, fun, *args, **kwds)"           | "fun(*args, **kwds)" が *warn* を送出  | 3.2          |
   |                                                           | してメッセージが正規表現 *r* とマッチ  |              |
   |                                                           | する                                   |              |
   +-----------------------------------------------------------+----------------------------------------+--------------+
   | "assertLogs(logger, level)"                               | "with" ブロックが *logger* に *level*  | 3.4          |
   |                                                           | 以上のレベルでログを出力する           |              |
   +-----------------------------------------------------------+----------------------------------------+--------------+
   | "assertNoLogs(logger, level)"                             | The "with" block does not log on       | 3.10         |
   |                                                           | *logger* with minimum *level*          |              |
   +-----------------------------------------------------------+----------------------------------------+--------------+

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

      *callable* を呼び出した時に例外が発生することをテストします。
      "assertRaises()" で指定した位置パラメータとキーワードパラメータ
      を該当メソッドに渡します。 *exception* が送出された場合、テスト
      は成功です。また、他の例外が投げられた場合はエラー、例外が送出さ
      れなかった場合は失敗になります。複数の例外をキャッチする場合には
      、例外クラスのタプルを *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')

      Added in version 3.1: "assertRaisesRegexp" という名前で追加され
      ました。

      バージョン 3.2 で変更: "assertRaisesRegex()" にリネームされまし
      た。

      バージョン 3.3 で変更: コンテキストマネージャとして使用したとき
      に *msg* キーワード引数が追加されました。

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

      *callable* を呼び出した時に警告が発生することをテストします。
      "assertWarns()" で指定した位置パラメータとキーワードパラメータを
      該当メソッドに渡します。 *warning* が発生した場合にテストが成功
      し、そうでなければ失敗になります。例外が送出された場合はエラーに
      なります。複数の警告を捕捉する場合には、警告クラスのタプルを
      *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)

      コンテキストマネージャを入れ子にして、異なる種類の警告が複数発生
      することをテストできます。

         with (self.assertWarns(SomeWarning),
               self.assertWarns(OtherWarning)):
             do_something()

      このメソッドは呼び出されたときに警告フィルタを無視して動作します
      。

      Added in version 3.2.

      バージョン 3.3 で変更: コンテキストマネージャとして使用したとき
      に *msg* キーワード引数が追加されました。

      バージョン 3.15 で変更: 指定したカテゴリに一致しない警告を抑制し
      なくなりました。 コンテキストマネージャの入れ子に対応しました。

   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')

      コンテキストマネージャを入れ子にして、異なる種類の警告が複数発生
      することをテストできます。

         with (self.assertWarns(SomeWarning, regex1),
               self.assertWarns(OtherWarning, regex2)):
             do_something()

      Added in version 3.2.

      バージョン 3.3 で変更: コンテキストマネージャとして使用したとき
      に *msg* キーワード引数が追加されました。

      バージョン 3.15 で変更: 指定したカテゴリまたは正規表現に一致しな
      い警告を抑制しなくなりました。 コンテキストマネージャの入れ子に
      対応しました。

   assertLogs(logger=None, level=None, formatter=None)

      *logger* かその子ロガーのうちの1つに、少なくとも1つのログメッセ
      ージが少なくとも与えられた *level* で出力されることをテストする
      コンテキストマネージャです。

      *logger* を指定する場合は、"logging.Logger" オブジェクトか、ロガ
      ーの名前を表す "str" を渡します。 デフォルトはルートロガーで、メ
      ッセージを伝播しない子孫ロガーによって遮断されたものを除き、すべ
      てのメッセージを捕捉します。

      *level* が与えられた場合、ログレベルを表す数値もしくはそれに相当
      する文字列 (例えば ""ERROR"" もしくは "logging.ERROR") であるべ
      きです。 デフォルトは "logging.INFO" です。

      *formatter* を指定する場合は、"logging.Formatter" オブジェクトを
      渡します。 デフォルトは書式文字列
      ""%(levelname)s:%(name)s:%(message)s"" を使うフォーマッターです
      。

      "with" ブロック内で出たメッセージの少なくとも一つが *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'])

      Added in version 3.4.

      バージョン 3.15 で変更: メッセージの書式化を制御する *formatter*
      を受け取るようになりました。

   assertNoLogs(logger=None, level=None)

      *logger* またはその子ロガーに、指定した *level* 以上のレベルでメ
      ッセージが一切出力されないことをテストするコンテキストマネージャ
      です。

      *logger* が与えられた場合、 "logging.Logger" オブジェクトもしく
      はロガーの名前である "str" であるべきです。 デフォルトはルートロ
      ガーで、これは全てのメッセージを掴まえます。

      *level* が与えられた場合、ログレベルを表す数値もしくはそれに相当
      する文字列 (例えば ""ERROR"" もしくは "logging.ERROR") であるべ
      きです。 デフォルトは "logging.INFO" です。

      "assertLogs()" と異なり、このコンテキストマネージャは何も返しま
      せん。

      Added in version 3.10.

   より具体的な確認を行うために以下のメソッドが用意されています:

   +-----------------------------------------+----------------------------------+----------------+
   | メソッド                                | 確認事項                         | 初出           |
   |=========================================|==================================|================|
   | "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            |
   |                                         | 同じ要素を含む。                 |                |
   +-----------------------------------------+----------------------------------+----------------+
   | "assertStartsWith(a, b)"                | "a.startswith(b)"                | 3.14           |
   +-----------------------------------------+----------------------------------+----------------+
   | "assertNotStartsWith(a, b)"             | "not a.startswith(b)"            | 3.14           |
   +-----------------------------------------+----------------------------------+----------------+
   | "assertEndsWith(a, b)"                  | "a.endswith(b)"                  | 3.14           |
   +-----------------------------------------+----------------------------------+----------------+
   | "assertNotEndsWith(a, b)"               | "not a.endswith(b)"              | 3.14           |
   +-----------------------------------------+----------------------------------+----------------+
   | "assertHasAttr(a, b)"                   | "hasattr(a, b)"                  | 3.14           |
   +-----------------------------------------+----------------------------------+----------------+
   | "assertNotHasAttr(a, b)"                | "not hasattr(a, b)"              | 3.14           |
   +-----------------------------------------+----------------------------------+----------------+

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

      *first* と *second* が近似的に等しい (等しくない) ことをテストし
      ます。これは、*places* (デフォルト7) で指定した小数位で丸めた差
      分をゼロと比較することで行われます。これらのメソッドは
      ("round()" と同様に) *小数位* を指定するのであって、*有効桁数*
      を指定するのではないことに注意してください。

      *places* の代わりに *delta* が渡された場合には、*first* と
      *second* の差分が *delta* 以下 (または *delta* より大きい) であ
      ることをテストします。

      *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)

      *first* が *second* と比べて、メソッド名に対応して >, >=, < もし
      くは <= であることをテストします。そうでない場合はテストは失敗で
      す:

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

      Added in version 3.1.

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

      *regex* の検索が *text* とマッチする (またはマッチしない) ことを
      テストします。テスト失敗時には、エラーメッセージにパターンと
      *text* が表示されます（もしくは、パターンと意図しないかたちでマ
      ッチした *text* の一部が表示されます）。 *regex* は正規表現オブ
      ジェクトか、 "re.search()" が扱える正規表現が書かれた文字列であ
      る必要があります。

      Added in version 3.1: "assertRegexpMatches" という名前で追加され
      ました。

      バージョン 3.2 で変更: メソッド "assertRegexpMatches()" は
      "assertRegex()" にリネームされました。

      Added in version 3.2: "assertNotRegex()"。

   assertCountEqual(first, second, msg=None)

      シーケンス *first* が *second* と同じ要素を含むことを、順序を無
      視してテストします。 同じ要素を含まない場合は、シーケンス間の違
      いを列挙したエラーメッセージを生成します。

      *first* と *second* の比較では、重複した要素は無視 *されません*
      。 各要素の出現回数が両方のシーケンスで等しいことを検証します。
      このメソッドは "assertEqual(Counter(list(first)),
      Counter(list(second)))" と同等に振る舞うことに加えて、ハッシュ化
      できないオブジェクトのシーケンスでも動作します。

      Added in version 3.2.

   assertStartsWith(s, prefix, msg=None)

   assertNotStartsWith(s, prefix, msg=None)

      Unicode 文字列またはバイト文字列 *s* が *prefix* で始まること (
      または始まらないこと) をテストします。 *prefix* には、候補となる
      文字列のタプルも指定できます。

      Added in version 3.14.

   assertEndsWith(s, suffix, msg=None)

   assertNotEndsWith(s, suffix, msg=None)

      Unicode 文字列またはバイト文字列 *s* が *suffix* で終わること (
      または終わらないこと) をテストします。 *suffix* には、候補となる
      文字列のタプルも指定できます。

      Added in version 3.14.

   assertHasAttr(obj, name, msg=None)

   assertNotHasAttr(obj, name, msg=None)

      オブジェクト *obj* が *name* という属性を持つこと (または持たな
      いこと) をテストします。

      Added in version 3.14.

   "assertEqual()" メソッドは、同じ型のオブジェクトの等価性確認のため
   に、型ごとに特有のメソッドにディスパッチします。これらのメソッドは
   、ほとんどの組み込み型用のメソッドは既に実装されています。さらに、
   "addTypeEqualityFunc()" を使う事で新たなメソッドを登録することがで
   きます:

   addTypeEqualityFunc(typeobj, function)

      "assertEqual()" で呼び出される型特有のメソッドを登録します。登録
      するメソッドは、比較する2つのオブジェクトの型が厳密に *typeobj*
      と同じ (サブクラスでもいけません) の場合に等価性を確認します。
      *function*  は "assertEqual()" と同様に、2つの位置引数と、3番目
      に msg=None のキーワード引数を取れる必要があります。このメソッド
      は、始めの2つに指定したパラメータ間の差分を検出した時に
      "self.failureException(msg)" の例外を投げる必要があります。この
      例外を投げる際は、出来る限り、エラーの内容が分かる有用な情報と差
      分の詳細をエラーメッセージに含めてください。

      Added in version 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)"                    | set または frozenset          | 3.1            |
   +-------------------------------------------+-------------------------------+----------------+
   | "assertDictEqual(a, b)"                   | 辞書                          | 3.1            |
   +-------------------------------------------+-------------------------------+----------------+

   assertMultiLineEqual(first, second, msg=None)

      複数行の文字列 *first* が文字列 *second* と等しいことをテストし
      ます。等しくない場合には、両者の差分がハイライトされてエラーメッ
      セージに表示されます。このメソッドは、デフォルトで、
      "assertEqual()" が string を比較するときに自動的に使用します。

      Added in version 3.1.

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

      2つのシーケンスが等しいことをテストします。*seq_type* が指定され
      た場合、*first* と *second* が *seq_type* のインスタンスで無い場
      合にはテストが失敗します。シーケンスどうしが異なる場合には、両者
      の差分がエラーメッセージに表示されます。

      このメソッドは直接 "assertEqual()" からは呼ばれませんが、
      "assertListEqual()" と "assertTupleEqual()" の実装で使われていま
      す。

      Added in version 3.1.

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

      2つのリストまたはタプルが等しいかどうかをテストします。 等しくな
      い場合には、両者の差分を表示します。 どちらかの引数が要求される
      型でない場合にもエラーになります。 このメソッドは、デフォルトで
      、 "assertEqual()" が list または tuple を比較するときに自動的に
      使用します。

      Added in version 3.1.

   assertSetEqual(first, second, msg=None)

      2つのセットが等しいかどうかをテストします。等しくない場合には、
      両者の差分を表示します。このメソッドは、デフォルトで、
      "assertEqual()" が set もしくは frozenset を比較するときに自動的
      に使用します。

      *first* or *second* のいずれかに "difference()" が無い場合にはテ
      ストは失敗します。

      Added in version 3.1.

   assertDictEqual(first, second, msg=None)

      2つの辞書が等しいかどうかをテストします。等しくない場合には、両
      者の差分を表示します。このメソッドは、デフォルトで、
      "assertEqual()" が dict を比較するときに自動的に使用します。

      Added in version 3.1.

   最後に、 "TestCase" の残りのメソッドと属性を紹介します:

   fail(msg=None)

      無条件にテストを失敗させます。エラーメッセージの表示に、*msg* ま
      たは "None" が使われます。

   failureException

      テストメソッドが送出する例外を指定するクラス属性です。例えばテス
      トフレームワークで追加情報を付した特殊な例外が必要になる場合、こ
      の例外のサブクラスとして作成します。この属性の初期値は
      "AssertionError" です。

   longMessage

      このクラス属性は、失敗した assertXYY の呼び出しで独自の失敗時の
      メッセージが msg 引数として渡されていたときにどうするかを決定し
      ます。 "True" がデフォルト値です。 この場合、標準の失敗時のメッ
      セージの後に独自のメッセージが追記されます。 "False" に設定した
      ときは、標準のメッセージを独自のメッセージで置き換えます。

      アサートメソッドを呼び出す前に、個別のテストメソッドの中でインス
      タンス属性 self.longMessage を "True" または "False" に設定して
      、この設定を上書きできます。

      このクラスの設定はそれぞれのテストを呼び出す前にリセットされます
      。

      Added in version 3.1.

   maxDiff

      この属性は、アサーションメソッドが失敗をレポートする時に表示する
      差分の長さをコントロールします。デフォルトは 80*8 文字です。この
      属性が影響するメソッドは、 "assertSequenceEqual()" (およびこのメ
      ソッドに委譲するシーケンス比較メソッド)、 "assertDictEqual()" と
      "assertMultiLineEqual()" です。

      "maxDiff" を "None" に設定すると差分表示の上限がなくなります。

      Added in version 3.2.

   テストフレームワークは、テスト情報を収集するために以下のメソッドを
   使用します:

   countTestCases()

      テストオブジェクトに含まれるテストの数を返します。 "TestCase" イ
      ンスタンスは常に "1" を返します。

   defaultTestResult()

      このテストケースクラスで使われるテスト結果クラスのインスタンスを
      (もし "run()" メソッドに他の結果インスタンスが提供されないならば
      ) 返します。

      "TestCase" インスタンスに対しては、いつも "TestResult" のインス
      タンスですので、 "TestCase" のサブクラスでは必要に応じてこのメソ
      ッドをオーバライドしてください。

   id()

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

   shortDescription()

      テストの説明を一行分、または説明がない場合には "None" を返します
      。デフォルトでは、テストメソッドの docstring の先頭の一行、また
      は "None" を返します。

      バージョン 3.1 で変更: 3.1で docstring があったとしても、返され
      る短い説明文字列にテスト名が付けられるようになりました。 この変
      更によって unittest 拡張に互換性の問題が発生し、 Python 3.2 でテ
      スト名が追加される場所は "TextTestResult" へ移動しました。

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

      "tearDown()" の後に呼び出される関数を追加します。この関数はリソ
      ースのクリーンアップのために使用します。追加された関数は、追加さ
      れた順と逆の順番で呼び出されます（LIFO (last-in, first-out)）。
      "addCleanup()" に渡された引数とキーワード引数が追加された関数に
      も渡されます。

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

      Added in version 3.1.

   enterContext(cm)

      指定した *context manager* に入ります。 成功した場合は
      "addCleanup()" で "__exit__()" メソッドをクリーンアップ関数とし
      て追加し、"__enter__()" メソッドの結果を返します。

      Added in version 3.11.

   doCleanups()

      このメソッドは、 "tearDown()" の後、もしくは、 "setUp()" が例外
      を投げた場合は "setUp()" の後に、無条件で呼ばれます。

      このメソッドは、 "addCleanup()" で追加された関数を呼び出す責務を
      担います。もし、クリーンアップ関数を "tearDown()" より前に呼び出
      す必要がある場合には、 "doCleanups()" を明示的に呼び出してくださ
      い。

      "doCleanups()" は、どこで呼び出されても、クリーンアップ関数をス
      タックから削除して実行します。

      Added in version 3.1.

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

      "tearDownClass()" の後に呼び出される関数を追加します。この関数は
      リソースのクリーンアップのために使用します。追加された関数は、追
      加された順と逆の順番で呼び出されます（LIFO (last-in, first-out)
      ）。 "addClassCleanup()" に渡された引数とキーワード引数が追加さ
      れた関数にも渡されます。

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

      Added in version 3.8.

   classmethod enterClassContext(cm)

      指定した *context manager* に入ります。 成功した場合は
      "addClassCleanup()" で "__exit__()" メソッドをクリーンアップ関数
      として追加し、"__enter__()" メソッドの結果を返します。

      Added in version 3.11.

   classmethod doClassCleanups()

      このメソッドは、 "tearDownClass()" の後、もしくは、
      "setUpClass()" が例外を投げた場合は "setUpClass()" の後に、無条
      件で呼ばれます。

      このメソッドは、 "addClassCleanup()" で追加された関数を呼び出す
      責務を担います。もし、クリーンアップ関数を "tearDownClass()" よ
      り前に呼び出す必要がある場合には、 "doClassCleanups()" を明示的
      に呼び出してください。

      "doClassCleanups()" は、どこで呼び出されても、クリーンアップ関数
      をスタックから削除して実行します。

      Added in version 3.8.

class unittest.IsolatedAsyncioTestCase(methodName='runTest')

   このクラスは "TestCase" と似たAPIを提供し、テスト関数としてコルーチ
   ンも許容します。

   Added in version 3.8.

   loop_factory

      "asyncio.Runner" に渡す *loop_factory* です。 asyncio のポリシー
      システムを使わないようにするには、サブクラスでこの属性を
      "asyncio.EventLoop" に置き換えてください。

      Added in version 3.13.

   async asyncSetUp()

      テストフィクスチャを用意するために呼び出されるメソッドです。これ
      は "TestCase.setUp()" の後に呼び出されます。これはテストメソッド
      を呼び出す直前に呼び出されます。"AssertionError" と "SkipTest"
      を除いて、このメソッドのによって送出されたあらゆる例外はテストの
      失敗ではなくエラーとみなされます。デフォルトの実装では何もしませ
      ん。

   async asyncTearDown()

      テストメソッドが呼び出され、その結果が記録された直後に呼び出され
      るメソッドです。これは "tearDown()" の前に呼び出されます。これは
      テストメソッドが例外を送出した場合でも呼び出されるので、サブクラ
      スの実装では内部状態のチェックに特に気を付ける必要があります。こ
      のメソッドで送出された "AssertionError" と "SkipTest" 以外の例外
      は、テストの失敗ではなく追加のエラーとみなされます(そのため、報
      告されるエラーの総数が増えることになります)。このメソッドはテス
      トメソッドの結果に関係なく、"asyncSetUp()" が成功した場合にのみ
      呼び出されます。デフォルトの実装では何もしません。

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

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

   async enterAsyncContext(cm)

      指定した *asynchronous context manager* に入ります。 成功した場
      合は "addAsyncCleanup()" で "__aexit__()" メソッドをクリーンアッ
      プ関数として追加し、"__aenter__()" メソッドの結果を返します。

      Added in version 3.11.

   run(result=None)

      テストを実行するための新しいイベントループを作成し、 *result* と
      して渡された "TestResult" オブジェクトに結果を収集します。
      *result* が省略された場合や "None" の場合は、一時的なresultオブ
      ジェクトが("defaultTestResult()" メソッドの呼び出しによって)作成
      され、使用されます。このresultオブジェクトは "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)

   This class implements the portion of the "TestCase" interface which
   allows the test runner to drive the test, but does not provide the
   methods which test code can use to check and report errors.  This
   is used to create test cases using legacy test code, allowing it to
   be integrated into a "unittest"-based test framework.


テストのグループ化
------------------

class unittest.TestSuite(tests=())

   このクラスは、個々のテストケースやテストスイートの集合を表現してい
   ます。 通常のテストケースと同じようにテストランナーで実行するための
   インターフェースを備えています。 "TestSuite" インスタンスを実行する
   ことはスイートをイテレートして得られる個々のテストを実行することと
   同じです。

   *tests* を指定する場合は、スイートを最初に構築するための個々のテス
   トケースや他のテストスイートを要素とするイテラブルでなければなりま
   せん。 後からテストケースやスイートを追加するためのメソッドも用意さ
   れています。

   "TestSuite" オブジェクトは、実際にはテストを実装していない点を除き
   、"TestCase" オブジェクトとよく似た振る舞いをします。 テストを実装
   する代わりに、まとめて実行するテストをグループ化するために使います
   。 "TestSuite" インスタンスにテストを追加するためのメソッドもありま
   す。

   addTest(test)

      "TestCase" 又は "TestSuite" のインスタンスをスイートに追加します
      。

   addTests(tests)

      イテラブル *tests* に含まれる全ての "TestCase" 又は "TestSuite"
      のインスタンスをスイートに追加します。

      このメソッドは *tests* 上のイテレーションをしながらそれぞれの要
      素に "addTest()" を呼び出すのと等価です。

   "TestSuite" クラスは "TestCase" と以下のメソッドを共有します:

   run(result)

      スイート内のテストを実行し、結果を *result* で指定した結果オブジ
      ェクトに収集します。 "TestCase.run()" と異なり、
      "TestSuite.run()" では必ず結果オブジェクトを指定する必要がありま
      す。

   debug()

      このスイートに関連づけられたテストを結果を収集せずに実行します。
      これによりテストで送出された例外は呼び出し元に伝わるようになり、
      デバッガの下でのテスト実行をサポートできるようになります。

   countTestCases()

      このテストオブジェクトによって表現されるテストの数を返します。こ
      れには個別のテストと下位のスイートも含まれます。

   __iter__()

      "TestSuite" でグループ化されたテストは反復アクセスできます。 サ
      ブクラスは "__iter__()" をオーバーライドすることで、遅延処理でテ
      ストを提供できます。 1つのスイート内でこのメソッドは何度も呼ばれ
      る可能性があることに注意してください (例えば、テスト数のカウント
      や等価性の比較)。 そのため、 "TestSuite.run()" を実行する前に反
      復アクセスを何度繰り返しても同じテスト群を返すようにしなければな
      りません。 呼び出し側が "TestSuite._removeTestAtIndex()" をオー
      バーライドしたサブクラスを使いテストへの参照を保存していない限り
      、 "TestSuite.run()" を実行した後はこのメソッドが返すテスト群を
      信頼すべきではありません。

      バージョン 3.2 で変更: 以前のバージョンでは "TestSuite" はイテレ
      ータではなく、直接テストにアクセスしていました。そのため、
      "__iter__()" をオーバーラードしてもテストにアクセスできませんで
      した。

      バージョン 3.4 で変更: 以前のバージョンでは、 "TestSuite.run()"
      の実行後は "TestSuite" が各 "TestCase" への参照を保持していまし
      た。 サブクラスで "TestSuite._removeTestAtIndex()" をオーバーラ
      イドすることでこの振る舞いを復元できます。

   通常、 "TestSuite" の "run()" メソッドは "TestRunner" が起動するた
   め、ユーザが直接実行する必要はありません。


テストのロードと起動
--------------------

class unittest.TestLoader

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

   "TestLoader" オブジェクトには以下の属性があります:

   errors

      テストの読み込み中に起きた致命的でないエラーのリストです。 どの
      時点でもローダーからリセットされることはありません。 致命的なエ
      ラーは適切なメソッドが例外を送出して、呼び出し元に通知します。
      致命的でないエラーについても、実行すると元のエラーを送出するテス
      トが生成され、エラーが通知されます。

      Added in version 3.5.

   "TestLoader" のオブジェクトには以下のメソッドがあります:

   loadTestsFromTestCase(testCaseClass)

      "TestCase" の派生クラス "testCaseClass" に含まれる全テストケース
      のスイートを返します。

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

   loadTestsFromModule(module, *, pattern=None)

      指定したモジュールに含まれる全テストケースのスイートを返します。
      このメソッドは *module* 内の "TestCase" 派生クラスを検索し、見つ
      かったクラスのテストメソッドごとにクラスのインスタンスを作成しま
      す。

      注釈:

        "TestCase" から派生したクラス階層は、フィクスチャやヘルパー関
        数を共有するのに便利ですが、 直接インスタンス化するつもりのな
        い基底クラスにテストメソッドを定義すると、このメソッドではうま
        く扱えません。 ただし、サブクラスごとに異なるフィクスチャを定
        義する場合には、こうしたテストメソッドの定義が役立つこともあり
        ます。

      モジュールが "load_tests" 関数を用意している場合、この関数がテス
      トの読み込みに使われます。 これによりテストの読み込み処理がカス
      タマイズできます。 これが load_tests プロトコル です。 *pattern*
      引数は "load_tests" に第3引数として渡されます。

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

      バージョン 3.5 で変更: キーワード専用引数 *pattern* に対応しまし
      た。

      バージョン 3.12 で変更: 文書化されていなかった非公式の引数
      *use_load_tests* が削除されました。

   loadTestsFromName(name, module=None)

      文字列で指定される全テストケースを含むスイートを返します。

      *name* には "ドット修飾名" でモジュールかテストケースクラス、テ
      ストケースクラス内のメソッド、 "TestSuite" インスタンスまたは
      "TestCase" か "TestSuite" のインスタンスを返す呼び出し可能オブジ
      ェクトを指定します。このチェックはここで挙げた順番に行なわれます
      。すなわち、候補テストケースクラス内のメソッドは「呼び出し可能オ
      ブジェクト」としてではなく「テストケースクラス内のメソッド」とし
      て拾い出されます。

      例えば、モジュール "SampleTests" に "TestCase" の派生クラス
      "SampleTestCase" があり、 3 つのテストメソッド ("test_one()"、
      "test_two()"、"test_three()") を持つとします。
      "'SampleTests.SampleTestCase'" を指定すると、このメソッドは 3 つ
      すべてのテストメソッドを実行するスイートを返します。
      "'SampleTests.SampleTestCase.test_two'" を指定すると、
      "test_two()" メソッドだけを実行するテストスイートを返します。 ま
      だインポートしていないモジュールやパッケージも指定でき、その場合
      は名前の解決に伴ってインポートされます。

      また、*module* を指定した場合、*module* 内の *name* を取得します
      。

      バージョン 3.5 で変更: *name* を巡回している間に "ImportError"
      か "AttributeError" が発生した場合、実行するとその例外を発生させ
      るようなテストを合成して返します。それらのエラーは self.errors
      に集められます。

   loadTestsFromNames(names, module=None)

      "loadTestsFromName()" と同じですが、名前を一つだけ指定するのでは
      なく、複数の名前のシーケンスを指定する事ができます。戻り値は
      *names* 中の名前で指定されるテスト全てを含むテストスイートです。

   getTestCaseNames(testCaseClass)

      *testCaseClass* 中の全てのメソッド名を含むソート済みシーケンスを
      返します。 *testCaseClass* は "TestCase" のサブクラスでなければ
      なりません。

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

      指定された開始ディレクトリからサブディレクトリに再帰することです
      べてのテストモジュールを検索し、それらを含む TestSuite オブジェ
      クトを返します。*pattern* にマッチしたテストファイルだけがロード
      の対象になります。 (シェルスタイルのパターンマッチングが使われま
      す)。その中で、インポート可能なもジュール (つまり Python の識別
      子として有効であるということです) がロードされます。

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

      シンタックスエラーなどでモジュールのインポートに失敗した場合、エ
      ラーが記録され、ディスカバリ自体は続けられます。 import  の失敗
      が "SkipTest" 例外が発生したためだった場合は、そのモジュールはエ
      ラーではなく skip として記録されます。

      パッケージ ("__init__.py" という名前のファイルがあるディレクトリ
      ) が見付かった場合、そのパッケージに "load_tests" 関数があるかを
      チェックします。 関数があった場合、次に
      "package.load_tests(loader, tests, pattern)" が呼ばれます。 テス
      トの検索の実行では、たとえ load_tests 関数自身が
      "loader.discover" を呼んだとしても、パッケージのチェックは1回の
      みとなることが保証されています。

      "load_tests" が存在する場合、ディスカバリはそのパッケージ内を再
      帰的に検索しません。 パッケージ内のすべてのテストの読み込みは
      "load_tests" が担当します。

      パッケージ自身が探索を続けられるように、パターンは意図的にローダ
      ーの属性に保存していません。

      *top_level_dir* は内部に保存され、入れ子になった "discover()" の
      呼び出しでデフォルト値として使われます。 つまり、パッケージの
      "load_tests" が "loader.discover()" を呼び出す場合、この引数を渡
      す必要はありません。

      *start_dir* はドット付のモジュール名でもディレクトリでも構いませ
      ん。

      Added in version 3.2.

      バージョン 3.4 で変更: インポート時に "SkipTest" を送出するモジ
      ュールはエラーではなくスキップとして記録されます。*start_dir* に
      *名前空間パッケージ* を指定できます。ファイルシステムの順序がフ
      ァイル名に従わないとしても実行順序が一定になるように、パスはイン
      ポートする前にソートされます。

      バージョン 3.5 で変更: パッケージ名がデフォルトのパターンに適合
      するのは不可能なので、パスが *pattern* に適合するかどうかに関係
      無く、見付けたパッケージに "load_tests" があるかをチェックするよ
      うになりました。

      バージョン 3.11 で変更: *start_dir* に *名前空間パッケージ* を指
      定できなくなりました。 この機能は Python 3.7 以降動作しておらず
      、Python 3.11 で正式に削除されました。

      バージョン 3.13 で変更: *top_level_dir* は *discover* の呼び出し
      中だけ保存されるようになりました。

      バージョン 3.14 で変更: *start_dir* に再び *namespace package*
      を指定できるようになりました。

   以下の属性は、サブクラス化またはインスタンスの属性値を変更して
   "TestLoader" をカスタマイズする場合に使用します:

   testMethodPrefix

      テストメソッドの名前と判断されるメソッド名の接頭語を示す文字列。
      デフォルト値は "'test'" です。

      この値は "getTestCaseNames()" と全ての "loadTestsFrom*" メソッド
      に影響を与えます。

   sortTestMethodsUsing

      "getTestCaseNames()" および全ての "loadTestsFrom*" メソッドでメ
      ソッド名をソートする際に使用する比較関数。

   suiteClass

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

      この値は全ての "loadTestsFrom*" メソッドに影響を与えます。

   testNamePatterns

      テストメソッドがテストスイートに含まれるためにマッチしなければな
      らないUnixシェルスタイルのワイルドカードテスト名パターンのリスト
      です("-k" オプションを参照)。

      この属性が "None" (デフォルト)でない場合、テストスイートに含まれ
      るすべてのテストメソッドはこのリストのパターンのいずれかにマッチ
      していなければなりません。マッチは常に "fnmatch.fnmatchcase()"
      を使用して実行されるため、"-k" オプションに渡されるパターンとは
      異なり、単純な部分文字列パターンは "*" ワイルドカードを使用して
      変換する必要があることに注意してください。

      この値は全ての "loadTestsFrom*" メソッドに影響を与えます。

      Added in version 3.7.

class unittest.TestResult

   このクラスはどのテストが成功しどのテストが失敗したかという情報を収
   集するのに使います。

   "TestResult" は、複数のテスト結果を記録します。 "TestCase" クラスと
   "TestSuite" クラスのテスト結果を正しく記録しますので、テスト開発者
   が独自にテスト結果を管理する処理を開発する必要はありません。

   "unittest" を基盤とするテストフレームワークでは、結果を報告するため
   に、テスト群の実行によって生成された "TestResult" オブジェクトにア
   クセスしたい場合があります。 このため、"TestRunner.run()" メソッド
   は "TestResult" インスタンスを返します。

   "TestResult" インスタンスの以下の属性は、テストの実行結果を検査する
   際に使用することができます:

   errors

      "TestCase" と例外のトレースバック情報をフォーマットした文字列の
      2 要素タプルからなるリスト。それぞれのタプルは予想外の例外を送出
      したテストに対応します。

   failures

      "TestCase" と例外のトレースバック情報をフォーマットした文字列の
      2 要素タプルからなるリスト。それぞれのタプルは assert* メソッド
      を使って見つけ出した失敗に対応します。

   skipped

      "TestCase" インスタンスとテストをスキップした理由を保持する文字
      列の2要素タプルからなるリストです。

      Added in version 3.1.

   expectedFailures

      "TestCase" と例外のトレースバック情報をフォーマット済の文字列の
      2 要素タプルからなるリストです。それぞれのタプルは予期された失敗
      またはエラーに対応します。

   unexpectedSuccesses

      予期された失敗とされていながら成功してしまった "TestCase" のイン
      スタンスのリスト。

   collectedDurations

      実行した各テストについて、テストケース名と経過時間を表す浮動小数
      点数からなる 2 要素タプルを格納したリストです。

      Added in version 3.12.

   shouldStop

      "stop()" によってテストの実行を停止すべき状態になると、"True" に
      設定されます。

   testsRun

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

   buffer

      "True" が設定されると、 "sys.stdout" と "sys.stderr" は、
      "startTest()" から "stopTest()" が呼ばれるまでの間バッファリング
      されます。 実際に、結果が "sys.stdout" と "sys.stderr" に出力さ
      れるのは、テストが失敗するかエラーが発生した時になります。 出力
      は失敗やエラーのメッセージにも添付されます。

      Added in version 3.2.

   failfast

      真の場合 "stop()" が始めの失敗もしくはエラーの時に呼び出され、テ
      ストの実行が終了します。

      Added in version 3.2.

   tb_locals

      真の場合、局所変数がトレースバックに表示されます。

      Added in version 3.5.

   wasSuccessful()

      これまでに実行したテストが全て成功していれば "True" を、それ以外
      なら "False" を返します。

      バージョン 3.4 で変更: "@expectedFailure" デコレータを付けたテス
      トに "unexpectedSuccesses" があれば、"False" を返すようになりま
      した。

   stop()

      このメソッドを呼び出して "TestResult" の "shouldStop" 属性に
      "True" をセットすることで、実行中のテストは中断しなければならな
      いというシグナルを送ることができます。 "TestRunner" オブジェクト
      はこのフラグを順守してそれ以上のテストを実行することなく復帰しな
      ければなりません。

      たとえばこの機能は、ユーザのキーボード割り込みを受け取って
      "TextTestRunner" クラスがテストフレームワークを停止させるのに使
      えます。 "TestRunner" の実装を提供する対話的なツールでも同じよう
      に使用することができます。

   "TestResult" クラスの以下のメソッドは内部データ管理用のメソッドです
   が、対話的にテスト結果をレポートするテストツールを開発する場合など
   にはサブクラスで拡張することができます。

   startTest(test)

      *test* を実行する直前に呼び出されます。

   stopTest(test)

      *test* の実行直後に、テスト結果に関わらず呼び出されます。

   startTestRun()

      全てのテストが実行される前に一度だけ実行されます。

      Added in version 3.1.

   stopTestRun()

      全てのテストが実行された後に一度だけ実行されます。

      Added in version 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)

      テストケース *test* が成功した場合に呼び出されます。

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

   addSkip(test, reason)

      *test* がスキップされた時に呼び出されます。*reason* はスキップの
      際に渡された理由の文字列です。

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

   addExpectedFailure(test, err)

      "@expectedFailure" デコレータが付いたテストケース *test* が失敗
      するか、エラーになったときに呼び出されます。

      デフォルトの実装では "(test, formatted_err)" のタプルをインスタ
      ンスの "expectedFailures" に追加します。ここで *formatted_err*
      は *err* から派生した整形されたトレースバックです。

   addUnexpectedSuccess(test)

      "@expectedFailure" デコレータが付いたテストケース *test* が成功
      したときに呼び出されます。

      デフォルトの実装ではテストをインスタンスの "unexpectedSuccesses"
      属性に追加します。

   addSubTest(test, subtest, outcome)

      サブテストが終了すると呼ばれます。 *test* はテストメソッドに対応
      するテストケースです。 *subtest* はサブテストを記述するカスタム
      の "TestCase" インスタンスです。

      *outcome* が "None" の場合、サブテストは成功です。 それ以外の場
      合は例外によって失敗しており、*outcome* は "sys.exc_info()" が返
      す形式のタプル "(type, value, traceback)" です。

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

      Added in version 3.4.

   addDuration(test, elapsed)

      テストケースが終了したときに呼び出されます。 *elapsed* は秒単位
      の経過時間で、クリーンアップ関数の実行時間も含みます。

      Added in version 3.12.

class unittest.TextTestResult(stream, descriptions, verbosity, *, durations=None)

   "TextTestRunner" が使う "TestResult" の具体的な実装です。 インター
   フェースが変更されたときの互換性を保つため、サブクラスは "**kwargs"
   を受け取るようにしてください。

   Added in version 3.2.

   バージョン 3.12 で変更: *durations* キーワード引数が追加されました
   。

unittest.defaultTestLoader

   "TestLoader" のインスタンスで、共用することが目的です。
   "TestLoader" をカスタマイズする必要がなければ、新しい "TestLoader"
   オブジェクトを作らずにこのインスタンスを使用します。

class unittest.TextTestRunner(stream=None, descriptions=True, verbosity=1, failfast=False, buffer=False, resultclass=None, warnings=None, *, tb_locals=False, durations=None)

   結果をストリームに出力する、基本的なテストランナーの実装です。
   *stream* が "None" の場合、デフォルトで "sys.stderr" が出力ストリー
   ムとして使われます。 このクラスはいくつかの設定項目があるだけで、基
   本的に非常に単純です。 グラフィカルなテスト実行アプリケーションでは
   、独自のテストランナーを実装してください。 テストランナーの実装は、
   unittest に新しい機能が追加されランナーを構築するインターフェースが
   変更されたときに備えて "**kwargs" を受け取れるようにするべきです。

   By default this runner shows "DeprecationWarning",
   "PendingDeprecationWarning", "ResourceWarning" and "ImportWarning"
   even if they are ignored by default.  This behavior can be
   overridden using Python's "-Wd" or "-Wa" options (see Warning
   control) and leaving *warnings* to "None".

   バージョン 3.2 で変更: *warnings* 引数が追加されました。

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

   バージョン 3.5 で変更: *tb_locals* 引数が追加されました。

   バージョン 3.12 で変更: *durations* 引数が追加されました。

   _makeResult()

      このメソッドは "run()" で使われる "TestResult" のインスタンスを
      返します。このメソッドは明示的に呼び出す必要はありませんが、サブ
      クラスで "TestResult" をカスタマイズすることができます。

      "_makeResult()" は、 "TextTestRunner" のコンストラクタで
      "resultclass" 引数として渡されたクラスもしくはコーラブルオブジェ
      クトをインスタンス化します。 "resultclass" が指定されていない場
      合には、デフォルトで "TextTestResult" が使用されます。結果のクラ
      スは以下の引数が渡されインスタンス化されます:

         stream, descriptions, verbosity

   run(test)

      このメソッドは "TextTestRunner" へのメインの公開インターフェース
      です。 このメソッドは "TestSuite" インスタンスあるいは
      "TestCase" インスタンスを受け取ります。 "_makeResult()" が呼ばれ
      て "TestResult" が作成され、テストが実行され、結果が標準出力に表
      示されます。

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)

   *module* から複数のテストを読み込んで実行するためのコマンドラインプ
   ログラム。この関数を使えば、簡単に実行可能なテストモジュールを作成
   する事ができます。一番簡単なこの関数の使い方は、以下の行をテストス
   クリプトの最後に置くことです:

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

   より詳細な情報は verbosity 引数を指定して実行すると得られます:

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

   *defaultTest* 引数は、 *argv* にテスト名が指定されていない場合に実
   行する、ある1つのテストの名前もしくはテスト名のイテラブルです。 こ
   の引数を指定しないか "None" を指定し、かつ *argv* にテスト名が与え
   られない場合は、 *module* にある全てのテストを実行します。

   *argv* 引数には、プログラムに渡されたオプションのリストを、最初の要
   素がプログラム名のままで渡せます。指定しないか "None" の場合は
   "sys.argv" が使われます。

   *testRunner* 引数には、テストランナーのクラスか、すでに作成したその
   インスタンスを指定できます。 デフォルトでは "main" は "sys.exit()"
   を呼び出し、実行したテストの成功 (0) または失敗 (1) を示す終了コー
   ドを渡します。 終了コード 5 は、実行もスキップもされたテストがなか
   ったことを示します。

   *testLoader* 引数は "TestLoader" インスタンスでなければなりません。
   デフォルトは "defaultTestLoader" です。

   "main" は、 "exit=False" を指定する事で対話的なインタプリタから使用
   することもできます。この引数を指定すると、 "sys.exit()" を呼ばずに
   、結果のみを出力します:

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

   *failfast*, *catchbreak*, *buffer* は、コマンドラインオプション に
   ある同名のオプションと同じ効果のあるパラメータです。

   *warnings* 引数では、テストの実行中に使うべき 警告フィルタ を指定し
   ます。 この引数が指定されない場合には、 "-W" オプションが
   **python** に渡されていれば "None" のまま (警告の制御 を参照してく
   ださい) で、そうでなければ "'default'" が設定されます。

   "main" を呼び出すと、実行したテストの結果を "unittest.TestResult"
   として保持する "result" 属性を持つオブジェクトを返します。

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

   バージョン 3.2 で変更: *verbosity*、*failfast*、*catchbreak*、
   *buffer*、*warnings* 引数が追加されました。

   バージョン 3.4 で変更: *defaultTest* 引数がテスト名のイテラブルも受
   け取るようになりました。


load_tests プロトコル
~~~~~~~~~~~~~~~~~~~~~

Added in version 3.2.

モジュールやパッケージには、"load_tests" と呼ばれる関数を実装できます
。これにより、通常のテスト実行時やテストディスカバリ時のテストのロード
され方をカスタマイズできます。

テストモジュールが "load_tests" を定義していると、それが
"TestLoader.loadTestsFromModule()" から呼ばれます。引数は以下です:

   load_tests(loader, standard_tests, pattern)

*pattern* は "loadTestsFromModule" からそのまま渡されます。デフォルト
は "None" です。

これは "TestSuite" を返すべきです。

*loader* はローディングを行う "TestLoader" のインスタンスです。
*standard_tests* は、そのモジュールからデフォルトでロードされるテスト
です。これは、テストの標準セットのテストの追加や削除のみを行いたいテス
トモジュールに一般に使われます。第三引数は、パッケージをテストディスカ
バリの一部としてロードするときに使われます。

特定の "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):
       # トップレベルのディレクトリはローダーのインスタンスにキャッシュされている
       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 で変更: パッケージ名がデフォルトのパターンに適合するの
が不可能なため、検索ではパッケージ名が *pattern* に適合するかのチェッ
クは行われなくなりました。


クラスとモジュールのフィクスチャ
================================

クラスレベルとモジュールレベルのフィクスチャが "TestSuite" に実装され
ました。 テストスイートが新しいクラスのテストを始める時、以前のクラス
(あれば)の "tearDownClass()" を呼び出し、その後に新しいクラスの
"setUpClass()" を呼び出します。

同様に、今回のテストのモジュールが前回のテストとは異なる場合、以前のモ
ジュールの "tearDownModule" を実行し、次に新しいモジュールの
"setUpModule" を実行します。

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

なお、共有フィクスチャは、テストの並列化などの [潜在的な] 機能と同時に
はうまくいかず、テストの分離を壊すので、気をつけて使うべきです。

unittest テストローダによるテスト作成のデフォルトの順序では、同じモジ
ュールやクラスからのテストはすべて同じグループにまとめられます。これに
より、"setUpClass" / "setUpModule" (など) は、一つのクラスやモジュール
につき一度だけ呼ばれます。この順序をバラバラにし、異なるモジュールやク
ラスのテストが並ぶようにすると、共有フィクスチャ関数は、一度のテストで
複数回呼ばれるようにもなります。

共有フィクスチャは標準でない順序で実行されることを意図していません。
共有フィクスチャをサポートしたくないフレームワークのために、
"BaseTestSuite" がまだ存在しています。

共有フィクスチャ関数のいずれかで例外が発生した場合、そのテストはエラー
として報告されます。 そのとき、対応するテストインスタンスが無いので
("TestCase" と同じインターフェースの) "_ErrorHolder" オブジェクトが生
成され、エラーを表します。 標準 unittest テストランナーを使っている場
合はこの詳細は問題になりませんが、あなたがフレームワークの作者である場
合は注意してください。


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 (last-in, first-out)）。
   "addModuleCleanup()" に渡された引数とキーワード引数が追加された関数
   にも渡されます。

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

   Added in version 3.8.

unittest.enterModuleContext(cm)

   指定した *context manager* に入ります。 成功した場合は
   "addModuleCleanup()" で "__exit__()" メソッドをクリーンアップ関数と
   して追加し、"__enter__()" メソッドの結果を返します。

   Added in version 3.11.

unittest.doModuleCleanups()

   この関数は、 "tearDownModule()" の後、もしくは、 "setUpModule()" が
   例外を投げた場合は "setUpModule()" の後に、無条件で呼ばれます。

   このメソッドは、 "addModuleCleanup()" で追加された関数を呼び出す責
   務を担います。もし、クリーンアップ関数を "tearDownModule()" より前
   に呼び出す必要がある場合には、 "doModuleCleanups()" を明示的に呼び
   出してください。

   "doModuleCleanups()" は、どこで呼び出されても、クリーンアップ関数を
   スタックから削除して実行します。

   Added in version 3.8.


シグナルハンドリング
====================

Added in version 3.2.

unittest の "-c/--catch" コマンドラインオプションや、
"unittest.main()" の "catchbreak" パラメタは、テスト実行中の control-C
の処理をよりフレンドリーにします。中断捕捉動作を有効である場合、
control-C が押されると、現在実行されているテストまで完了され、そのテス
トランが終わると今までの結果が報告されます。control-C がもう一度押され
ると、通常通り "KeyboardInterrupt" が送出されます。

control-c を処理するシグナルハンドラは、独自の "signal.SIGINT" ハンド
ラを登録するコードやテストとの互換性を保つように動作します。
"unittest" のハンドラが呼び出されたとき、その時点で登録されている
"signal.SIGINT" ハンドラが自身で *なければ*、デフォルトのハンドラを呼
び出します。 これは、テスト対象のシステムがハンドラを置き換え、元のハ
ンドラに処理を委譲した場合に当たります。 通常、登録済みのハンドラを置
き換えて元のハンドラに委譲するコードが期待するのは、この動作です。 個
々のテストで "unittest" の control-c 処理を無効にする必要がある場合は
、"removeHandler()" デコレータを使えます。

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

unittest.installHandler()

   control-c ハンドラをインストールします。(主にユーザが control-c を
   押したことにより) "signal.SIGINT" が受け取られると、登録した結果す
   べてに "stop()" が呼び出されます。

unittest.registerResult(result)

   control-c 処理のために "TestResult" を登録します。結果を登録すると
   それに対する弱参照が格納されるので、結果がガベージコレクトされるの
   を妨げません。

   control-c 処理が有効でなければ、 "TestResult" オブジェクトの登録に
   は副作用がありません。ですからテストフレームワークは、処理が有効か
   無効かにかかわらず、作成する全ての結果を無条件に登録できます。

unittest.removeResult(result)

   登録された結果を削除します。一旦結果が削除されると、control-c が押
   された際にその結果オブジェクトに対して "stop()" が呼び出されなくな
   ります。

unittest.removeHandler(function=None)

   引数なしで呼び出すと、登録されている control-c ハンドラを削除します
   。 この関数は、テストの実行中だけハンドラを一時的に削除するテストデ
   コレータとしても使えます。

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