"unittest" --- 단위 테스트 프레임워크
*************************************

**소스 코드:** Lib/unittest/__init__.py

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

(당신이 이미 테스트 기본 개념에 친숙하다면, assert 메서드 목록으로 건
너뛰어도 좋습니다.)

"unittest" 단위 테스트 프레임워크는 본래 JUnit으로부터 영감을 받고 다
른 언어의 주요 단위 테스트 프레임워크와 비슷한 특징을 가지고 있습니다.
이것은 테스트 자동화, 테스트를 위한 사전 설정(setup)과 종료(shutdown)
코드 공유, 테스트를 컬렉션에 종합하기, 테스트와 리포트 프레임워크의 분
리 등을 지원합니다.

이를 달성하기 위해 "unittest"는 객체 지향적인 방법으로 몇 가지 중요한
개념을 지원합니다.

테스트 픽스쳐
   *테스트 픽스쳐 (test fixture)*는 1개 또는 그 이상의 테스트를 수행할
   때 필요한 준비와 그와 관련된 정리 동작에 해당합니다. 예를 들어 이것
   은 임시 또는 프락시 데이터베이스, 디렉터리를 생성하거나 서버 프로세
   스를 시작하는 것 등을 포함합니다.

테스트 케이스
   *테스트 케이스(test case)*는 테스트의 개별 단위입니다. 이것은 특정
   한 입력 모음에 대해서 특정한 결과를 확인합니다. "unittest"는 베이스
   클래스인 "TestCase"를 지원합니다. 이 클래스는 새로운 테스트 케이스
   를 만드는 데 사용됩니다.

테스트 묶음
   *테스트 묶음(test suite)*은 여러 테스트 케이스, 테스트 묶음, 또는
   둘 다의 모임입니다. 이것은 서로 같이 실행되어야 할 테스트들을 종합
   하는 데 사용됩니다.

테스트 실행자
   *테스트 실행자(test runner)*는 테스트 실행을 조율하고 테스트 결과를
   사용자에게 제공하는 역할을 하는 컴포넌트입니다. 실행자는 테스트 실
   행 결과를 보여주기 위해 그래픽 인터페이스, 텍스트 인터페이스를 사용
   하거나 특별한 값을 반환할 수도 있습니다.

더 보기:

  "doctest" 모듈
     매우 다른 특징을 가지고 있는 또 다른 테스트 지원 모듈

  Simple Smalltalk Testing: With Patterns
     "unittest"에 영향을 준 Kent Beck의 패턴을 사용한 테스트 프레임워
     크 원본 논문

  pytest
     테스트를 작성하기에 간편한 문법을 가지고 있는 제삼자의 단위 테스
     트 프레임워크. 예시, "assert func(10) == 42".

  파이썬 테스트 도구 분류
     함수형 테스트 프레임워크와 모의 객체 라이브러리를 포함한 광범위한
     파이썬 테스트 도구 목록

  Testing in Python 메일링 리스트
     파이썬에서 테스트하기와 테스트 도구에 대해 논의하는 특정-주제-그
     룹(special-interest-group)

  파이썬 소스 배포판에 있는 "Tools/unittestgui/unittestgui.py" 스크립
  트는 테스트 탐색 및 실행을 위한 GUI 도구입니다. 이것은 단위 테스트가
  처음인 사람들이 쉽게 사용할 수 있도록 만들어졌습니다. 라이브 환경에
  서는 Buildbot, Jenkins, GitHub Actions 또는  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'])
           # 구분 기호가 문자열이 아닐 때 s.split이 실패하는지 검사합니다
           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()"은 높은
상세도(verbosity)를 설정하여 그에 따른 출력이 나옵니다:

   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에서 변경: The behavior of returning a value from a test
method (other than the default "None" value), is now deprecated.


명령행 인터페이스
=================

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

이것으로 테스트 모듈을 지정할 때 셸(shell)의 파일 이름 완성 기능을 사
용할 수 있습니다. 지정된 파일은 반드시 모듈로 임포트 가능해야 합니다.
파일 경로는 '.py' 가 빠지면서 모듈 이름으로 변경되고 경로 구분자도 '.'
로 변경됩니다. 만약 당신이 임포트 가능하지 않은 테스트 파일을 모듈로
사용하고 싶으시다면 이 방법 대신에 그 파일을 직접 실행해야 합니다.

-v 옵션을 사용하여 더 자세한 정보(높은 상세도)로 테스트를 실행할 수 있
습니다:

   python -m unittest -v test_module

아무 인자 없이 실행하면 테스트 탐색(Discovery)이 실행됩니다:

   python -m unittest

모든 명령행 옵션 목록을 보기:

   python -m unittest -h

버전 3.2에서 변경: 이전 버전에서는 개별 테스트 메서드만 실행이 가능했
고, 모듈과 클래스는 불가능했습니다.


명령행 옵션
-----------

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

   트레이스백(traceback)에서 지역 변수를 표시합니다.

--durations N

   Show the N slowest test cases (N=0 for all).

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".

명령행은 프로젝트의 모든 테스트 또는 일부분의 테스트 탐색을 위해서도
사용할 수 있습니다.


테스트 탐색(Discovery)
======================

Added in version 3.2.

unittest는 간단한 테스트 탐색을 지원합니다. 테스트 탐색에 호환되기 위
해서는 모든 테스트 파일은 반드시 프로젝트의 가장 상위 디렉터리로부터
모듈 또는 패키지로 임포트 가능해야 합니다(이 말은 파일 이름이 반드시
유효한 식별자이어야 한다는 뜻입니다).

테스트 탐색은 "TestLoader.discover()"로 구현되어 있습니다, 그러나 명령
행으로 사용할 수도 있습니다. 기본적인 명령행 사용법은 다음과 같습니다:

   cd project_directory
   python -m unittest discover

참고:

  단축형인 "python -m unittest"는 "python -m unittest discover"와 같습
  니다. 테스트 탐색에 인자를 전달하고 싶을 때는 "discover" 부속 명령어
  (sub-command)를 명시적으로 사용해야 합니다.

"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"로 임포트될 것입니다.만약 당신이 전
  역적으로 설치된 패키지가 있고 테스트 탐색을 다른 패키지 복사본에 하
  려고 시도한다면 임포트가 잘못된 위치에서 발생할 *수도 있습니다*. 만
  약 이런 일이 발생한다면 테스트 탐색은 경고하고 종료될 것입니다.만약
  당신이 시작 디렉터리로 경로가 아닌 패키지 이름을 전달했다면 테스트
  탐색은 임포트가 어느 경로로부터 되었든 간에 당신이 의도한 경로라고
  간주하여 경고를 발생하지 않을 것입니다.

테스트 모듈과 패키지는 load_tests 프로토콜을 통하여 테스트 로드와 탐색
을 사용자 정의할 수 있습니다.

버전 3.4에서 변경: 테스트 탐색은 시작 디렉터리로 *이름 공간 패키지*를
지원합니다. 최상위 디렉터도 지정해야 함에 유의하십시오 (예를 들어
"python -m unittest discover -s root/namespace -t root").

버전 3.11에서 변경: "unittest" dropped the *namespace packages*
support in Python 3.11. It has been broken since Python 3.7. Start
directory and subdirectories containing tests must be regular package
that have "__init__.py" file.Directories containing start directory
still can be a namespace package. In this case, you need to specify
start directory as dotted package name, and target directory
explicitly. For example:

   # proj/  <-- 현재 디렉터리
   #   namespace/
   #     mypkg/
   #       __init__.py
   #       test_mypkg.py

   python -m unittest discover -s namespace.mypkg -t .


테스트 코드 구조 잡기
=====================

단위 테스트의 기본 구성 블록은 *테스트 케이스(test cases)* --- 정확성
을 위해 설정되고 확인될 하나의 시나리오입니다. "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()"이란 메서드를 작성하여 사전 설정 코드를 밖으로 분리해
낼 수 있습니다. 테스트 프레임워크가 1개의 테스트마다 매번 자동으로 이
것을 호출할 것입니다:

   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)*라고
부릅니다. 개별 테스트 메서드를 실행하기 위해 고유한 테스트 픽스쳐에 해
당하는 새로운 테스트 케이스 인스턴스가 생성됩니다. 따라서 "setUp()",
"tearDown()", "__init__()"는 테스트 당 1번씩 실행됩니다.

테스트하려는 기능에 따라 테스트들을 같이 모아서 테스트 케이스 구현을
사용하는 것을 추천합니다. 이것을 위해 "unittest"는 메커니즘을 제공합니
다: *테스트 묶음(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" 인스
턴스를 자동으로 만들 수 있습니다.


테스트 건너뛰기와 예상된 실패
=============================

Added in version 3.1.

unittest는 테스트 중에서 개별 테스트 메서드나 심지어 전체 클래스를 건
너뛸 수 있는 기능을 제공합니다. 게다가 테스트를 "예상된 실패"로 표시하
는 기능도 지원합니다, 테스트가 망가져서 실패하더라도 그것을
"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):
           # 윈도우 특정 테스트 코드
           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()"을 실행하지 않을 것입니다.


부분 테스트(subtest)를 사용하여 테스트 반복 구별 짓기
=====================================================

Added in version 3.4.

여러분의 테스트들이 아주 작은 부분에서만 다를 때, 예를 들어 몇몇 매개
변수, unittest는 "subTest()" 컨텍스트 관리자를 사용하여 테스트 메서드
의 바디 안에서 그것들은 구별 짓게 해줍니다.

예를 들어, 다음 테스트는:

   class NumbersTest(unittest.TestCase):

       def test_even(self):
           """
           0과 5 사이의 숫자가 모두 짝수인지 테스트합니다.
           """
           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에서 변경: *methodName* 제공 없이도 "TestCase"를 성공적으로
   인스턴스화할 수 있습니다. 이것은 대화형 인터프리터에서 "TestCase"로
   쉽게 실험을 할 수 있게 합니다.

   "TestCase" 인스턴스는 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"은 결과를 반환하지 않았습니
      다. 인스턴스 호출 또한 그렇지 않았습니다.

   skipTest(reason)

      테스트 메서드나 "setUp()"에서 이것을 호출하면 현재 테스트를 건너
      뜁니다. 자세한 정보는 테스트 건너뛰기와 예상된 실패를 보십시오.

      Added in version 3.1.

   subTest(msg=None, **params)

      둘러싼 코드 블록을 부분 테스트로서 실행하는 컨텍스트 관리자를 반
      환합니다. *msg* 및 *params*는 선택 사항이며 부분 테스트가 실패
      할 때마다 표시되는 임의의 값으로 당신이 명확하게 알아보게 해줍니
      다.

      테스트 케이스는 여러 개의 부분 테스트 선언을 포함할 수 있고, 그
      것들은 자유롭게 중첩될 수 있습니다.

      자세한 정보는 부분 테스트(subtest)를 사용하여 테스트 반복 구별
      짓기를 보십시오.

      Added in version 3.4.

   debug()

      결과를 수집하지 않고 테스트를 실행합니다. 이것은 테스트에서 발생
      한 예외가 호출자로 전파될 수 있게 해서, 디버거 환경에서 테스트를
      실행할 때 사용될 수 있습니다.

   "TestCase" 클래스는 값을 검사하고 실패를 보고하기 위해 몇 개의
   assert 메서드를 제공합니다. 다음 표는 보통 많이 사용되는 메서드들입
   니다(더 많은 assert 메서드는 표 아래를 보십시오):

   +-------------------------------------------+-------------------------------+-----------------+
   | 메서드                                    | 검사하는 내용                 | 추가된 버전     |
   |===========================================|===============================|=================|
   | "assertEqual(a, b)"                       | "a == b"                      |                 |
   +-------------------------------------------+-------------------------------+-----------------+
   | "assertNotEqual(a, b)"                    | "a != b"                      |                 |
   +-------------------------------------------+-------------------------------+-----------------+
   | "assertTrue(x)"                           | "bool(x) is True"             |                 |
   +-------------------------------------------+-------------------------------+-----------------+
   | "assertFalse(x)"                          | "bool(x) is False"            |                 |
   +-------------------------------------------+-------------------------------+-----------------+
   | "assertIs(a, b)"                          | "a is b"                      | 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" 도 참고하십
   시오). "assertRaises()", "assertRaisesRegex()", "assertWarns()",
   "assertWarnsRegex()"는 컨텍스트 관리자로서 사용될 때만 그들에게
   *msg* 키워드 인자를 전달할 수 있다는 점을 주의하십시오.

   assertEqual(first, second, msg=None)

      *first*와 *second*가 같은지 테스트합니다. 비교한 값이 같지 않으
      면 테스트는 실패할 것입니다.

      추가로, 만약 *first*와 *second*가 정확히 같은 형(type)이고 list,
      tuple, dict, set, frozenset, str 이거나 "addTypeEqualityFunc()"
      에 등록된 서브 클래스 형 중 하나일 경우 더 유용한 기본 에러 메시
      지를 생성하기 위해 형-특화(type-specific) 동등성 함수가 불릴 것
      입니다(형-특화 메서드 목록을 참고하십시오).

      버전 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*("isinstance()"가 지원하는 것처럼 클래스 또는 클래
      스의 튜플)의 인스턴스인지(아닌지) 테스트합니다. 정확한 형 검사를
      위해서는 "assertIs(type(obj), cls)"를 사용하십시오.

      Added in version 3.2.

   다음의 메서드를 사용하여 예외, 경고, 로그 메시지의 발생을 검사할 수
   있습니다:

   +-----------------------------------------------------------+----------------------------------------+--------------+
   | 메서드                                                    | 검사하는 내용                          | 추가된 버전  |
   |===========================================================|========================================|==============|
   | "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" 블록이 최소 *level*로 *logger*  | 3.4          |
   |                                                           | 에 로그를 남김                         |              |
   +-----------------------------------------------------------+----------------------------------------+--------------+
   | "assertNoLogs(logger, level)"                             | "with" 블록이 최소 *level*로 *logger*  | 3.10         |
   |                                                           | 에 로그를 남기지 않음                  |              |
   +-----------------------------------------------------------+----------------------------------------+--------------+

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

      "assertRaises()"에 전달된 어떤 위치 또는 키워드 인자와 함께
      *callable*이 호출되었을 때 예외가 발생하는지 테스트합니다.
      *exception*이 발생하면 테스트를 통과하고, 다른 예외가 발생하면
      에러이고, 아무 예외도 발생하지 않으면 실패입니다. 여러 예외 모음
      을 잡기 위해서 예외 클래스를 포함한 튜플을 *exception*으로 전달
      해도 좋습니다.

      만약 선택적인 *msg*와 함께 오직 *exception* 인자만 전달된다면,
      테스트할 코드를 함수가 아닌 인라인으로 작성할 수 있도록 컨텍스트
      관리자를 반환합니다:

         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)

      "assertWarns()"에 전달된 어떤 위치 또는 키워드 인자와 함께
      *callable*이 호출되었을 때 경고(warning)가 발생하는지 테스트합니
      다. *warning*이 발생하면 테스트를 통과하고, 그렇지 않으면 실패입
      니다. 예외가 발생하면 에러입니다. 여러 경고 모음을 잡기 위해서
      경고 클래스를 포함한 튜플을 *warnings*로 전달해도 좋습니다.

      만약 선택적인 *msg*와 함께 오직 *warning* 인자만 전달된다면, 테
      스트할 코드를 함수가 아닌 인라인으로 작성할 수 있도록 컨텍스트
      관리자를 반환합니다:

         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)

      이 메서드는 호출될 때 적용될 경고 필터와 관계없이 작동합니다.

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

      Added in version 3.2.

      버전 3.3에서 변경: 컨텍스트 관리자로 사용될 때 *msg* 키워드 인자
      추가.

   assertLogs(logger=None, level=None)

      최소한 *level*로 *logger*나 그 자식들에 최소한 1개의 메시지가 기
      록되는지 테스트하는 컨텍스트 관리자입니다.

      *logger*가 주어졌다면, "logging.Logger" 객체이거나 로거의 이름인
      "str"이어야 합니다. 기본값은 전파하지 않는 하위 로거에 의해 차단
      되지 않은 모든 메시지를 잡을 루트 로거입니다.

      *level*이 주어졌다면, 로그 수준의 숫자 값이거나 그에 대응하는 문
      자열이어야 합니다(예를 들어 ""ERROR""이거나  "logging.ERROR").
      기본값은 "logging.INFO"입니다.

      만약 "with" 블록 안에서 *logger*와 *level* 조건을 만족하는 최소
      한 1개의 메시지가 나왔다면 테스트는 성공하고, 그렇지 않으면 실패
      합니다.

      컨텍스트 관리자에 의해 반환되는 객체는 조건에 일치하는 로그 메시
      지를 추적하기 위한 기록 도우미입니다. 이것은 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.

   assertNoLogs(logger=None, level=None)

      *logger*나 그 자식들에 주어진 *level* 이상으로 메시지가 기록되지
      않았음을 테스트하는 컨텍스트 관리자입니다.

      *logger*가 주어졌다면, "logging.Logger" 객체이거나 로거의 이름인
      "str"이어야 합니다. 기본값은 모든 메시지를 잡을 루트 로거입니다.

      *level*이 주어졌다면, 로그 수준의 숫자 값이거나 그에 대응하는 문
      자열이어야 합니다(예를 들어 ""ERROR""이거나  "logging.ERROR").
      기본값은 "logging.INFO"입니다.

      Unlike "assertLogs()", nothing will be returned by the context
      manager.

      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            |
   |                                         | 개수의 같은 요소를 가졌는지.     |                |
   +-----------------------------------------+----------------------------------+----------------+

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

      *first*와 *second*가 근사하게 같은지(또는 근사하게 같지 않은지)
      테스트합니다. 이는 값 차이를 계산하고, 주어진 소수 *자릿
      (places)*수(기본값 7)로 반올림한 뒤, 0과 비교하는 것으로 이루어
      집니다. 이 메서드는 값을 *유효 숫자 자릿수(significant digits)*
      가 아닌 주어진 *소수 자릿수(decimal places)*(즉, "round()" 함수
      와 같이)로 반올림합니다.

      만약 *places* 대신에 *delta*가 주어진다면 *first*와 *second*의
      값 차이는 반드시 *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)))"와 같
      지만 해시 불가능한(unhashable) 시퀀스에도 작동합니다.

      Added in version 3.2.

   "assertEqual()" 메서드는 같은 형의 객체의 동등성 검사를 다른 형-특
   화 메서드에게로 보냅니다. 이러한 메서드들은 대부분의 내장 형에 대해
   서 이미 구현되어 있지만, "addTypeEqualityFunc()"을 사용하여 새로운
   메서드를 등록하는 것도 가능합니다:

   addTypeEqualityFunc(typeobj, function)

      정확히 같은 (서브 클래스가 아닌) *typeobj* 형의 두 객체가 같은지
      비교 검사하기 위해 "assertEqual()"한테 불리는 형-특화 메서드를
      등록합니다. *function*은 반드시 2개의 위치 인자를 받아야 하고
      "assertEqual()"이 그러한 것처럼 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)"                    | 집합 또는 불변 집합           | 3.1            |
   +-------------------------------------------+-------------------------------+----------------+
   | "assertDictEqual(a, b)"                   | 딕셔너리                      | 3.1            |
   +-------------------------------------------+-------------------------------+----------------+

   assertMultiLineEqual(first, second, msg=None)

      여러 줄 문자열인 *first*와 *second*가 같은지 테스트합니다. 같지
      않을 경우 에러 메시지에 다른 부분이 강조된 두 문자열의 차이가 포
      함됩니다. 이 메서드는 "assertEqual()"에서 문자열을 비교할 때 기
      본적으로 사용됩니다.

      Added in version 3.1.

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

      2개의 시퀀스가 같은지 테스트합니다. *seq_type*이 전달된 경우,
      *first*와 *second* 둘 다 *seq_type*의 인스턴스이어야 하고 그렇지
      않은 경우 실패가 발생합니다. 시퀀스가 다른 경우, 에러 메시지는 2
      개 사이의 차이점을 보여주게 됩니다.

      이 메서드는 "assertEqual()"에서 직접 호출되진 않지만,
      "assertListEqual()"와 "assertTupleEqual()"을 구현할 때 사용됩니
      다.

      Added in version 3.1.

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

      2개의 리스트나 튜플이 같은지 테스트합니다. 만약 같지 않다면 에러
      메시지는 2개 사이의 차이점만 보여주게 됩니다. 매개변수 중 하나가
      잘못된 형인 경우 에러가 발생합니다. 이 메서드는 "assertEqual()"
      에서 리스트와 튜플을 비교할 때 기본적으로 사용됩니다.

      Added in version 3.1.

   assertSetEqual(first, second, msg=None)

      2개의 집합이 같은지 테스트합니다. 같지 않은 경우 에러 메시지는
      집합 사이의 차이를 나열하게 됩니다. 이 메서드는 "assertEqual()"
      에서 집합이나 불변 집합을 비교할 때 기본적으로 사용됩니다.

      *first*와 *second* 중 하나가 "set.difference()" 메서드를 가지고
      있지 않으면 실패합니다.

      Added in version 3.1.

   assertDictEqual(first, second, msg=None)

      2개의 딕셔너리가 같은지 테스트합니다. 같지 않은 경우 에러 메시지
      는 딕셔너리 사이의 차이를 보여주게 됩니다. 이 메서드는
      "assertEqual()"에서 딕셔너리를 비교할 때 기본적으로 사용될 것입
      니다.

      Added in version 3.1.

   마지막으로 "TestCase"가 다음의 메서드와 어트리뷰트를 제공합니다:

   fail(msg=None)

      무조건 테스트 실패 신호를 보냅니다, 에러 메시지를 위해 *msg*나
      "None"을 전달합니다.

   failureException

      이 클래스 어트리뷰트는 테스트 메서드에서 발생한 예외를 줍니다.
      만약 테스트 프레임워크가 추가 정보를 전달하기 위해 특수한 예외를
      사용할 필요가 있다면, 프레임워크와 "공정하게 행동하기" 위해서 이
      예외를 서브 클래스해야 합니다. 이 어트리뷰트의 초깃값은
      "AssertionError" 입니다.

   longMessage

      이 클래스 어트리뷰트는 실패한 assertXYY 호출에 msg 인자로 전달된
      사용자 정의 실패 메시지가 어떻게 동작하는지를 결정합니다. "True"
      가 기본값입니다. 이 경우, 사용자 정의 메시지가 표준 실패 메시지
      끝에 추가됩니다. "False"로 설정할 경우 사용자 정의 메시지가 표준
      메시지를 대체합니다.

      이 클래스 설정은 인스턴스 어트리뷰트를 설정하여 개별 테스트 메서
      드에 의해 재정의될 수 있습니다, assert 메서드를 호출하기 전에
      self.longMessage를 "True" 또는 "False"로 설정하는 것입니다.

      이 클래스 설정은 각 테스트 호출 전에 재설정됩니다.

      Added in version 3.1.

   maxDiff

      이 어트리뷰트는 실패 시 diff를 보고하는 assert 메서드의 최대
      diff 출력 길이를 설정합니다. 기본값은 80*8 문자입니다. 이 어트리
      뷰트에 영향을 받는 assert 메서드는 "assertSequenceEqual()"(이것
      에 위임하는 모든 시퀀스 비교 메서드를 포함),
      "assertDictEqual()", "assertMultiLineEqual()" 입니다.

      "maxDiff"를 "None"으로 설정하면 diff의 최대 길이 제한이 없어지는
      것을 뜻합니다.

      Added in version 3.2.

   테스트 프레임워크는 테스트에 관한 정보를 수집하기 위해 다음의 메서
   드를 사용할 수 있습니다:

   countTestCases()

      이 테스트 객체에 해당하는 테스트 개수를 반환합니다. "TestCase"
      인스턴스에 대해서는 이것은 항상 "1"입니다.

   defaultTestResult()

      이 테스트 케이스 클래스를 위해서 사용되는 테스트 결과 클래스의
      인스턴스를 반환합니다("run()" 메서드에 다른 결과 인스턴스가 전달
      되지 않은 경우에).

      "TestCase" 인스턴스에 대해서는 이것은 항상 "TestResult"의 인스턴
      스입니다; "TestCase"의 서브 클래스는 이것을 필요에 따라 재정의해
      야 합니다.

   id()

      특정 테스트 케이스를 식별하는 문자열을 반환합니다. 이것은 보통
      모듈과 클래스 이름을 포함한 테스트 메서드의 완전한 이름(full
      name)입니다.

   shortDescription()

      테스트의 설명을 반환하거나 설명이 제공되지 않았으면 "None"을 반
      환합니다. 이 메서드의 기본 구현은 가능하다면 테스트 메서드의 독
      스트링의 첫 번째 줄을 반환하고 그렇지 않으면 "None"을 반환합니다
      .

      버전 3.1에서 변경: 3.1 버전에서 docstring이 있는 경우에도 짧은
      설명에 테스트 이름을 추가하도록 변경되었습니다. 이것은 unittest
      확장과 호환성 문제를 일으켰고 테스트 이름 추가는 파이썬 3.2에서
      "TextTestResult"로 옮겨졌습니다.

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

      테스트 중에 사용된 자원을 정리하기 위해 "tearDown()" 이후에 불리
      는 함수를 추가합니다. 함수들은 추가된 순서의 반대 순서대로 불리
      게 됩니다(LIFO (후입 선출법(last-in, first-out))). 함수가 추가될
      때 "addCleanup()"에 같이 전달된 위치 인자나 키워드 인자와 함께
      호출됩니다.

      만약 "setUp()"이 실패한다면, 즉 "tearDown()"이 불리지 않더라도,
      정리 함수들은 여전히 불리게 될 것입니다.

      Added in version 3.1.

   enterContext(cm)

      Enter the supplied *context manager*.  If successful, also add
      its "__exit__()" method as a cleanup function by "addCleanup()"
      and return the result of the "__enter__()" method.

      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)

      Enter the supplied *context manager*.  If successful, also add
      its "__exit__()" method as a cleanup function by
      "addClassCleanup()" and return the result of the "__enter__()"
      method.

      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.

   async asyncSetUp()

      테스트 픽스쳐를 준비하기 위해 호출되는 메서드입니다. 이 메서드는
      "setUp()"이후에 호출됩니다. 이 메서드는 테스트 메서드를 호출하기
      바로 직전에 호출됩니다; "AssertionError" 또는 "SkipTest"이외의
      이 메서드에서 발생한 모든 예외는 테스트 실패가 아닌 오류로 간주
      합니다. 기본 구현은 아무것도 하지 않습니다.

   async asyncTearDown()

      테스트 메서드가 불리고 결과가 기록되고 나서 바로 다음에 호출되는
      메서드입니다. 이 메서드는 "tearDown()"전에 호출됩니다. 테스트 메
      서드가 예외를 발생했더라도 이 메서드는 불립니다, 따라서 서브 클
      래스의 구현은 내부 상태를 확인하는 데 특별히 주의를 기울여야 합
      니다. "AssertionError" 또는 "SkipTest"이외의 이 메서드에서 발생
      하는 모든 예외는 테스트 실패가 아닌 오류로 간주합니다(따라서 보
      고된 오류의 총 숫자가 증가합니다). 이 메서드는 테스트 메서드의
      결과물에 영향받지 않고 "asyncSetUp()"이 성공했을 때만 불립니다.
      기본 구현은 아무것도 하지 않습니다.

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

      이 메서드는 정리 함수로 사용할 수 있는 코루틴을 받아들입니다.

   async enterAsyncContext(cm)

      Enter the supplied *asynchronous context manager*.  If
      successful, also add its "__aexit__()" method as a cleanup
      function by "addAsyncCleanup()" and return the result of the
      "__aenter__()" method.

      Added in version 3.11.

   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"-기반 테스트 프레임워크에 통합
   될 수 있게 해줍니다.


테스트 분류
-----------

class unittest.TestSuite(tests=())

   이 클래스는 개별 테스트 케이스와 테스트 묶음의 집합체를 나타냅니다.
   이 클래스는 테스트 실행자가 이것을 다른 테스트 케이스처럼 실행할 수
   있기 위해 필요한 인터페이스를 제공합니다. "TestSuite" 인스턴스를 실
   행하는 것은 테스트 묶음을 이터레이션하면서 각 테스트를 개별적으로
   실행하는 것과 같습니다.

   *tests*가 주어졌다면, 그것은 초기에 이 테스트 묶음을 만들 때 사용될
   개별 테스트 케이스이거나 다른 테스트 묶음의 이터러블이어야 합니다.
   나중에 컬렉션에 테스트 케이스나 테스트 묶음을 추가할 수 있는 추가
   메서드가 제공됩니다.

   "TestSuite" 객체는 "TestCase" 객체와 흡사하게 행동합니다만, 테스트
   를 실제로 구현하지 않는 것이 다릅니다. 대신에, 이것은 다 같이 실행
   되어야 하는 테스트 그룹에 테스트들을 모으는 데 사용됩니다.
   "TestSuite" 인스턴스에 테스트를 추가하기 위해 몇몇 추가적인 메서드
   를 사용할 수 있습니다.

   addTest(test)

      테스트 묶음에 "TestCase"나 "TestSuite" 추가하기.

   addTests(tests)

      이 테스트 묶음에 "TestCase"와 "TestSuite" 인스턴스의 이터러블에
      서 나온 모든 테스트를 추가하기.

      이것은 *tests*를 이터레이션하면서 각 요소에 대해 "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" 객체의 전형적인 사용법은 최종 사용자 테스트 장치
   (harness)보다는 "TestRunner"에 의해 "run()" 메서드가 호출되는 것입
   니다.


테스트를 로드하고 실행하기
--------------------------

class unittest.TestLoader

   "TestLoader" 클래스는 클래스와 모듈로부터 테스트 묶음을 생성하는 데
   사용됩니다. 보통, 이 클래스의 인스턴스를 생성할 필요는 없습니다;
   "unittest" 모듈은 공유 가능한 "unittest.defaultTestLoader" 인스턴스
   를 제공합니다. 그러나 서브 클래스나 인스턴스를 사용함으로 몇몇 변경
   가능한 속성을 사용자 정의할 수 있습니다.

   "TestLoader" 객체는 다음 어트리뷰트를 가집니다:

   errors

      테스트를 로드하는 동안 발생한 치명적이지 않은(non-fatal) 에러 목
      록입니다. 어떤 시점에도 로더에 의해 재설정되지 않습니다. 치명적
      인 에러는 예외를 발생시키는 관련 메서드에 의해 신호가 발생하여
      호출자에게 전달됩니다. 치명적이지 않은 에러는 실행 시에 원래 에
      러를 발생시킬 합성(synthetic) 테스트가 표시하기도 합니다.

      Added in version 3.5.

   "TestLoader" 객체는 다음 메서드를 가집니다:

   loadTestsFromTestCase(testCaseClass)

      "TestCase"에서 파생된 "testCaseClass"에 포함된 모든 테스트 케이
      스의 묶음을 반환합니다.

      테스트 케이스 인스턴스는 "getTestCaseNames()"에 의해 이름 지어진
      각 메서드를 위해 생성됩니다. 기본값은 "test"로 시작되는 메서드
      이름입니다. 만약 "getTestCaseNames()"가 아무 메서드도 반환하지
      않지만, "runTest()" 메서드가 구현되었다면 이 메서드를 위해서 1개
      의 테스트 케이스가 대신 생성됩니다.

   loadTestsFromModule(module, *, pattern=None)

      주어진 모듈에 포함된 모든 테스트 케이스 묶음을 반환합니다. 이 메
      서드는 "TestCase"에서 파생된 클래스를 찾기 위해 *module*을 검색
      하고 클래스에 정의된 각 테스트 메서드를 위해 클래스의 인스턴스를
      생성합니다.

      참고:

        "TestCase"에서 파생된 클래스의 계층 사용이 픽스쳐와 도우미 함
        수를 공유하는 데 편리할 수 있지만 직접 인스턴스화를 하도록 의
        도되지 않은 베이스 클래스에 테스트 메서드를 정의하는 것은 이
        메서드와 잘 작동하지 않습니다. 그러나 그렇게 하는 것이 픽스처
        들이 다르고 서브 클래스에서 정의될 경우에는 유용할 수 있습니다
        .

      만약 모듈이 "load_tests" 함수를 제공한다면 테스트 로드를 위해 이
      것을 호출할 것입니다. 이것은 모듈이 테스트 로드를 사용자 정의할
      수 있도록 해줍니다. 이것은 load_tests 프로토콜입니다. *pattern*
      인자는 "load_tests"에 세 번째 인자로 전달됩니다.

      버전 3.2에서 변경: "load_tests" 지원이 추가됨.

      버전 3.5에서 변경: Support for a keyword-only argument *pattern*
      has been added.

      버전 3.12에서 변경: The undocumented and unofficial
      *use_load_tests* parameter has been removed.

   loadTestsFromName(name, module=None)

      문자열 지정자에 맞는 모든 테스트 케이스 묶음을 반환합니다.

      지정자 *name*은 모듈, 테스트 케이스 클래스, 테스트 케이스 클래스
      에 있는 테스트 메서드, "TestSuite" 인스턴스, "TestCase"나
      "TestSuite" 인스턴스를 반환하는 콜러블 객체로 해석될 수 있는 "점
      으로 구분된 이름(dotted name)"입니다. 이 검사는 여기에 나열된 순
      서대로 적용됩니다; 즉, 테스트 케이스 클래스에 있는 메서드는 "콜
      러블  객체"보다는 "테스트 케이스 클래스에 있는 테스트 메서드"로
      선택될 것입니다.

      예를 들어, 만약 당신이 "TestCase"에서 파생된 클래스인
      "SampleTestCase"를 포함한 "SampleTests" 모듈을 가지고 있고 그 클
      래스는 3개의 테스트 메서드("test_one()", "test_two()",
      "test_three()")를 가지고 있다면, 지정자
      "'SampleTests.SampleTestCase'" 에 대해서 이 메서드는 모든 3개의
      테스트 메서드를 실행할 테스트 묶음으로 반환할 것입니다. 지정자가
      "'SampleTests.SampleTestCase.test_two'" 라면 이 메서드는 오직
      "test_two()" 테스트 메서드를 실행할 테스트 묶음을 반환할 것입니
      다. 지정자는 아직 임포트되지 않은 모듈이나 패키지를 가리킬 수 있
      습니다; 부작용(side-effect)으로써 그것들이 임포트될 것입니다.

      이 메서드는 주어진 *module*에 상대적인 *name*을 선택적으로 해석
      할 수 있습니다.

      버전 3.5에서 변경: 만약 *name* 순회 중에 "ImportError"나
      "AttributeError"가 발생한다면 실행할 때 그 에러를 일으키는 합성
      테스트가 반환될 것입니다. 이 에러는 self.errors 에러 모임에 포함
      될 것입니다.

   loadTestsFromNames(names, module=None)

      "loadTestsFromName()"와 비슷하지만, 1개의 이름이 아닌 이름의 시
      퀀스를 받습니다. 반환 값은 각 이름에 정의된 모든 테스트를 지원하
      는 테스트 묶음입니다.

   getTestCaseNames(testCaseClass)

      *testCaseClass* 안에서 찾은 메서드 이름을 정렬된 시퀀스로 반환합
      니다; 이 클래스는 "TestCase"의 서브 클래스이어야 합니다.

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

      지정된 시작 디렉터리부터 하위 디렉터리를 재귀적으로 순회하여 모
      든 테스트 모듈을 찾아, 이를 포함하는 TestSuite 객체를 반환합니다
      . *pattern*에 일치하는 테스트 파일만 로드될 것입니다. (셸 방식의
      패턴 일치를 사용합니다.) 임포트 가능한(즉, 유효한 파이썬 식별자
      인) 모듈 이름만 로드될 것입니다.

      모든 테스트 모듈은 반드시 프로젝트의 최상위 수준에서 임포트 가능
      해야 합니다. 만약 시작 디렉터리가 최상위 디렉터리가 아니라면
      *top_level_dir*을 따로 지정해야 합니다.

      만약 모듈 임포트가 실패한다면, 예를 들어 문법 에러로 인해, 이것
      은 1개의 에러로 기록되고 탐색이 계속 진행될 것입니다. 만약
      "SkipTest"가 발생해서 임포트가 실패했다면, 이것은 에러가 아닌 건
      너뛰기로 기록될 것입니다.

      만약 패키지("__init__.py" 라는 이름의 파일을 포함한 디렉터리)를
      찾으면, "load_tests" 함수가 있는지 패키지를 검사할 것입니다. 만
      약 존재한다면 그 패키지에 대해서 "package.load_tests(loader,
      tests, pattern)"가 불릴 것입니다. 만약 load_tests 함수 자체가
      "loader.discover"를 호출할지라도, 테스트 탐색은 실행 중에 패키지
      에 대한 테스트 검사를 한 번만 실행하도록 보장합니다.

      만약 "load_tests"가 존재한다면 탐색은 패키지 안을 재귀 탐색하지
      *않습니다*. "load_tests"가 패키지 안의 모든 테스트를 로드할 책임
      이 있습니다.

      패턴은 의도적으로 로더 어트리뷰트로 저장되지 않아 패키지가 자신
      에 대한 탐색을 계속할 수 있습니다.

      *top_level_dir*은 내부적으로 저장되어, "discover()"의 중첩된 호
      출 시 기본값으로 사용됩니다. 즉, 패키지의 "load_tests"가
      "loader.discover()"를 호출할 경우, 이 인자를 전달할 필요가 없습
      니다.

      *start_dir*는 디렉터리뿐만 아니라 점으로 구분된 모듈 이름이 될
      수 있습니다.

      Added in version 3.2.

      버전 3.4에서 변경: 임포트 할 때 "SkipTest"를 발생시키는 모듈은
      에러가 아니라 건너뛰기로 기록됩니다.

      버전 3.4에서 변경: *start_dir*은 *이름 공간 패키지*일 수 있습니
      다.

      버전 3.4에서 변경: 임포트되기 전에 경로들이 정렬되어 하부 파일
      시스템의 정렬 순서가 파일 이름에 의존하지 않더라도 실행 순서가
      같아지도록 합니다.

      버전 3.5에서 변경: 이제 발견된 패키지는 그것의 경로가 *pattern*
      과 일치하는지 여부와 상관없이 "load_tests"를 검사합니다, 왜냐하
      면 패키지 이름이 기본 패턴과 일치하는 것이 불가능하기 때문입니다
      .

      버전 3.11에서 변경: *start_dir*은 *이름 공간 패키지*일 수 없습니
      다. 파이썬 3.7부터 깨졌고, 파이썬 3.11에서 공식적으로 제거되었습
      니다.

      버전 3.12.4에서 변경: *top_level_dir* is only stored for the
      duration of *discover* call.

   "TestLoader"의 다음 어트리뷰트들은 서브 클래스나 인스턴스에 대입을
   통해 구성할 수 있습니다.

   testMethodPrefix

      테스트 메서드로 해석할 메서드 이름의 접두사에 해당하는 문자열입
      니다. 기본값은 "'test'" 입니다.

      이것은 "getTestCaseNames()" 과 모든 "loadTestsFrom*" 메서드에 영
      향을 미칩니다.

   sortTestMethodsUsing

      "getTestCaseNames()"와 모든 "loadTestsFrom*" 메서드에서 메서드
      이름 정렬 시에 이름 비교하는 데 사용될 함수입니다.

   suiteClass

      테스트 목록에서 테스트 묶음을 생성하는 콜러블 객체입니다. 결과
      객체에 어떤 메서드도 필요하지 않습니다. 기본값은 "TestSuite" 클
      래스입니다.

      이것은 모든 "loadTestsFrom*" 메서드에 영향을 미칩니다.

   testNamePatterns

      테스트 묶음에 포함되기 위해서 테스트 메서드가 일치해야 할 유닉스
      셸-방식의 와일드카드 테스트 이름 패턴 목록입니다("-k" 옵션을 보
      십시오).

      만약 이 어트리뷰트가 "None"(기본값)이 아니라면, 테스트 묶음에 포
      함될 모든 테스트 메서드는 이 목록의 패턴 중 1개와 반드시 일치해
      야 합니다. 이 패턴 일치는 항상 "fnmatch.fnmatchcase()"를 사용하
      여 수행된다는 것을 기억하십시오, 그래서 "-k" 옵션에 패턴을 건네
      주는 것과 달리, 간단한 부분 문자열 패턴은 "*" 와일드카드를 사용
      하도록 변경되어야 할 것입니다.

      이것은 모든 "loadTestsFrom*" 메서드에 영향을 미칩니다.

      Added in version 3.7.

class unittest.TestResult

   어떤 테스트가 성공했고 어떤 테스트가 실패했는지에 관한 정보를 엮는
   데 사용되는 클래스입니다.

   "TestResult" 객체는 여러 테스트의 결과들을 저장합니다. "TestCase"와
   "TestSuite" 클래스는 결과가 올바르게 기록되는 것을 보장합니다; 테스
   트 작성자가 테스트 결과를 기록하는 것에 대해서 걱정할 필요가 없습니
   다.

   "unittest" 위에 만들어진 테스트 프레임워크는 보고 목적으로 여러 테
   스트가 실행하면서 만들어낸 "TestResult" 객체에 접근하고 싶을 수도
   있습니다; "TestRunner.run()" 메서드는 이 목적을 위해 "TestResult"
   인스턴스를 반환합니다.

   "TestResult" 인스턴스는 테스트 실행 결과를 조사할 때 관심이 생길만
   한 다음과 같은 어트리뷰트를 가지고 있습니다.

   errors

      "TestCase" 인스턴스와 포맷된(formatted) 트레이스백 문자열로 구성
      된 2-튜플을 포함하는 목록입니다. 각 튜플은 예기치 못한 예외가 발
      생한 테스트에 해당합니다.

   failures

      "TestCase" 인스턴스와 포맷된(formatted) 트레이스백 문자열로 구성
      된 2-튜플을 포함하는 목록입니다. 각 튜플은 assert* 메서드를 사용
      하여 명시적으로 실패가 발생한 테스트에 해당합니다.

   skipped

      "TestCase" 인스턴스와 테스트 건너뛰기한 이유 문자열로 구성된 2-
      튜플을 포함하는 목록입니다.

      Added in version 3.1.

   expectedFailures

      "TestCase" 인스턴스와 포맷된(formatted) 트레이스백 문자열로 구성
      된 2-튜플을 포함하는 목록입니다. 각 튜플은 테스트 케이스의 예상
      된 실패니 에러에 해당합니다.

   unexpectedSuccesses

      예상된 실패로 표시되었지만 성공한 "TestCase" 인스턴스를 포함하는
      목록입니다.

   collectedDurations

      테스트 케이스 이름과 실행된 각 테스트의 소요 시간을 나타내는 실
      수로 구성된 2-튜플을 포함하는 목록입니다.

      Added in version 3.12.

   shouldStop

      테스트 실행이 "stop()"에 의해 정지되어야 할 때 "True"로 설정합니
      다.

   testsRun

      이제까지 실행된 테스트 총 개수입니다.

   buffer

      참으로 설정하면 "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()

      "shouldStop" 어트리뷰트를 "True"로 설정하여 현재 실행 중인 테스
      트 모음을 중단해야 함을 알리기 위한 용도로 이 메서드를 부를 수
      있습니다. "TestRunner" 객체는 이 신호를 존중하여 어떠한 추가 테
      스트 없이 반환해야 합니다.

      예를 들어, 사용자가 키보드로 중단 신호를 보낼 때 테스트 프레임워
      크를 중단하기 위해 "TextTestRunner"가 이 기능을 사용합니다.
      "TestRunner" 구현을 제공하는 대화형 도구는 비슷한 방법으로 이것
      을 사용할 수 있습니다.

   "TestResult" 클래스의 다음 메서드는 내부 자료 구조를 관리하려고 사
   용되고, 추가적인 보고 요구사항을 지원하기 위해 서브 클래스에서 확장
   할 수도 있습니다. 이것은 테스트가 실행 중에 대화형 보고를 지원하는
   도구를 만들 때 특별히 유용합니다.

   startTest(test)

      테스트 케이스 *test*가 막 실행되려 할 때 호출됩니다.

   stopTest(test)

      결과에 상관없이 테스트 케이스 *test*가 실행되고 나서 호출됩니다.

   startTestRun()

      모든 테스트가 실행되기 전에 1번 호출됩니다.

      Added in version 3.1.

   stopTestRun()

      모든 테스트가 실행되고 나서 1번 호출됩니다.

      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)

      테스트 케이스 *test*가 실패하거나 에러지만, "expectedFailure()"
      데코레이터로 표시된 경우 호출됩니다

      기본 구현은 "(test, formatted_err)" 튜플을 인스턴스의
      "expectedFailures" 어트리뷰트에 추가합니다, 여기서
      *formatted_err*는 *err*에서 파생된 포맷한 트레이스백입니다.

   addUnexpectedSuccess(test)

      테스트 케이스 *test*가 "expectedFailure()" 데코레이터로 표시되었
      지만, 성공한 경우 호출됩니다.

      기본 구현은 테스트를 인스턴스의 "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)

      Called when the test case finishes.  *elapsed* is the time
      represented in seconds, and it includes the execution of cleanup
      functions.

      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"
   를 사용자 정의할 필요가 없다면, 계속 새로운 인스턴스를 생성하는 것
   대신 이 인스턴스를 사용할 수 있습니다.

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"를
   받아들여야 합니다.

   기본적으로 이 실행자는 "DeprecationWarning",
   "PendingDeprecationWarning", "ResourceWarning", "ImportWarning"이
   기본적으로 무시 설정이 되어 있더라도 이것들을 보여줍니다. 파이썬의
   "-Wd"이나 "-Wa" 옵션(경고 제어를 보십시오)을 사용하고 *warnings*를
   "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" 인스턴스를 받습니다.
      "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)

   *module*에서 테스트 모음을 로드하고 실행하는 명령행 프로그램입니다;
   이것은 주로 편리하게 실행 가능한 테스트 모듈을 만들기 위한 것입니다
   . 이 함수의 가장 간단한 사용은 테스트 스크립트 마지막에 다음과 같은
   줄을 포함하는 것입니다:

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

   당신은 상세도 인자를 전달하여 좀 더 자세한 정보와 함께 테스트를 실
   행할 수 있습니다:

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

   *defaultTest* 인자는 *argv*로 테스트 이름이 지정되지 않은 경우 실행
   될 1개의 테스트 이름이거나 테스트 이름의 이터러블입니다. 만약 이 인
   자가 지정되지 않거나 "None"이면서 *argv*로 테스트 이름이 지정되지
   않으면 *module* 안에서 찾은 모든 테스트가 실행됩니다.

   *argv* 인자는 프로그램에 전달된 옵션 목록이 될 수 있습니다, 첫 번째
   요소는 프로그램 이름입니다. 만약 이 인자가 지정되지 않거나 "None"이
   면, "sys.argv" 값이 사용됩니다.

   *testRunner* 인자는 테스트 실행자 클래스나 이미 생성된 테스트 실행
   자 인스턴스일 수 있습니다. 기본적으로 "main"은 실행한 테스트가 성공
   (0)인지 실패(1)인지를 나타내는 종료 코드와 함께 "sys.exit()"을 호출
   합니다. 종료 코드 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"을 호출하면 "result" 어트리뷰트를 가진 객체를 반환합니다. 이
   어트리뷰트는 테스트 실행 결과를 포함하는 "unittest.TestResult"입니
   다.

   버전 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()"로부터, 패키지가 포함된
디렉터리에서 시작된다면, "load_tests"를 위해 패키지 "__init__.py"를 검
사합니다. 만약 함수가 존재하지 않으면, 탐색은 그저 다른 디렉터리인 것
처럼 패키지 안을 재귀 순회할 것입니다. 그렇지 않다면, 패키지의 테스트
를 위한 탐색은 다음 인자와 함께 불리는 "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"(등) 이 클래스와 모듈별로 정확하게 1번씩 호출되게 할 것
입니다. 만약 당신이 무작위로 순서를 정하여, 그래서 다른 모듈과 클래스
의 테스트가 서로 인접한다면, 이 공유 픽스처 함수는 1번의 테스트 실행에
서 여러 번 호출될 수 있습니다.

공유 픽스처는 비표준 정렬 순서를 사용하는 테스트 묶음과 같이 작동하는
것을 의도하지 않습니다. 공유 픽스처를 지원하길 원치 않는 프레임워크를
위해서 "BaseTestSuite"가 여전히 존재합니다.

공유 픽스처 함수 중 1개에서 발생한 예외가 있다면, 테스트를 에러로 보고
합니다. 해당 테스트 인스턴스가 없기 때문에 에러를 나타내기 위해
"_ErrorHolder" 객체("TestCase"와 같은 인터페이스를 가진)가 생성됩니다.
당신이 그저 표준 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.

classmethod unittest.enterModuleContext(cm)

   Enter the supplied *context manager*.  If successful, also add its
   "__exit__()" method as a cleanup function by "addModuleCleanup()"
   and return the result of the "__enter__()" method.

   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 처리기를 설치합니다. "signal.SIGINT"를 받았을 때(보통 사
   용자가 control-c를 눌렀을 때의 응답으로써) 모든 등록된 결과에
   "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):
          ...
