답변:
둘 다 귀중합니다. 나는 doctest와 코 를 모두 unittest 대신 사용합니다 . 테스트에서 실제로 문서로 유용한 사용법의 예를 제공하는 경우 doctest를 사용합니다. 일반적으로 나는 정보 제공만을 목적으로 이러한 테스트를 포괄적으로 만들지 않습니다. doctest를 반대로 사용하는 것이 효과적입니다. 내 doctest를 기반으로 코드를 테스트하는 것이 아니라 코드를 기반으로 문서가 올바른지 확인하는 것입니다.
그 이유는 포괄적 인 doctest가 문서를 너무 복잡하게 만들 수 없기 때문에 사용할 수없는 docstring 또는 불완전한 테스트로 끝날 수 있기 때문입니다.
실제로 코드를 테스트하려면 목표는 예제로 수행하는 작업을 설명하기보다는 모든 사례를 철저히 테스트하는 것입니다. 이는 다른 프레임 워크에서 더 잘 충족되는 다른 목표입니다.
나는 거의 독점적으로 unittest를 사용합니다.
가끔씩, 나는 doctest가 사용할 수있는 docstring에 어떤 것들을 넣을 것입니다.
테스트 사례의 95 %가 unittest입니다.
왜? 나는 docstrings를 약간 더 짧게 유지하는 것을 좋아합니다. 때로는 테스트 사례가 문서 문자열을 명확하게하는 데 도움이됩니다. 대부분의 경우, 애플리케이션의 테스트 케이스는 문서화하기에는 너무 길다.
docstring하는 것과 그렇지 않은 것을 보는 것이 좋을 것입니다 . 실제로 docstring은 인터페이스 사용 방법을 명시 적으로 표시한다는 점에서 docstring을 좋아하지만 해당 테스트와 단위 테스트에 모두 사용하면 적합하지 않을 수 있습니다.
나는 생물 정보 학자로 일하고 있으며, 내가 작성하는 대부분의 코드는 "한 번에 하나의 작업"스크립트이며, 한두 번만 실행되고 하나의 특정 작업을 실행하는 코드입니다.
이 상황에서 큰 단위 테스트를 작성하는 것은 과도 할 수 있으며 doctest는 유용한 타협입니다. 작성이 더 빠르며 일반적으로 코드에 통합되어 있으므로 다른 파일을 열지 않고도 코드의 작동 방식을 항상 주시 할 수 있습니다. 작은 스크립트를 작성할 때 유용합니다.
또한 doctest는 스크립트를 프로그래밍 전문가가 아닌 연구원에게 전달해야 할 때 유용합니다. 어떤 사람들은 단위 테스트가 어떻게 구성되어 있는지 이해하기가 매우 어렵습니다. 다른 한편으로, doctest는 사용의 간단한 예이므로 사람들은 복사하여 붙여 넣기하여 사용법을 볼 수 있습니다.
내 대답을 다시 시작하려면 doctests는 작은 스크립트를 작성해야 할 때와 컴퓨터 과학자가 아닌 연구원에게 스크립트를 전달하거나 보여야 할 때 유용합니다.
단위 테스트에 대한 아이디어를 시작했다면 사용 doctest하기가 간단하기 때문에 시작하겠습니다 . 또한 자연스럽게 어느 정도의 문서를 제공합니다. 보다 포괄적 인 테스트doctest 위해 외부 파일에 테스트를 배치하여 문서를 어지럽히 지 않도록 할 수 있습니다.
내가 제안 unittest당신은 당신이 다른 곳이었다으로 일반적으로 같은 방법으로 쓰기 단위 테스트를 할 수 있도록하려면 사용의 JUnit 또는 이와 유사한를 갖는의 배경에서 오는하는 경우.
doctest받았지만 (최초로) 후회했다. 사소한 테스트 사례의 경우 편집기의 구문 강조 표시 및 자동 완성 기능이 손실되었습니다. 테스트가 별도의 파일에있을 때 더 이상 편집기에서 직접 실행할 수 없었습니다. 매번 컨텍스트를 해당 소스 파일로 다시 변경해야했습니다.
둘 다 사용하는 것은 유효하고 다소 간단한 옵션입니다. 이 doctest모듈은 모듈 또는 파일에서 각각 단위 테스트 호환 테스트 슈트를 작성하는 DoctTestSuite및 DocFileSuite메소드를 제공합니다 .
그래서 나는 둘 다 사용하고 일반적으로 설정이 거의 필요없는 함수 (인수의 간단한 유형)로 간단한 테스트를 위해 doctest를 사용합니다. 실제로 몇 가지 doctest 테스트가 도움이 된다고 생각합니다. 가 기능을 손상시키지 않고 문서화하는 이된다고 생각합니다.
그러나 더 복잡한 경우와보다 포괄적 인 테스트 사례의 경우 더 많은 제어 및 유연성을 제공하는 unittest를 사용합니다.
나는 doctest를 unittest의 대체물로 사용하지 않습니다. 그것들이 약간 겹치지 만 두 모듈은 같은 기능을하지 않습니다 :
unittest단위 테스트 프레임 워크로 사용 하므로 코드의 나머지 부분에 대한 수정의 영향을 신속하게 확인할 수 있습니다.
내가 사용하는 doctest코멘트 (즉 문서화 문자열)이 여전히 코드의 현재 버전과 관련이 있음을 보증한다.
내가 얻은 테스트 주도 개발의 광범위한 문서화 된 이점 unittest. doctest오래된 주석이 코드 유지 관리를 오도하는 훨씬 더 미묘한 위험을 해결합니다.
Doctest때때로 잘못된 결과를 초래할 수 있습니다. 특히 출력에 이스케이프 시퀀스가 포함 된 경우. 예를 들어
def convert():
"""
>>> convert()
'\xe0\xa4\x95'
"""
a = '\xe0\xa4\x95'
return a
import doctest
doctest.testmod()준다
**********************************************************************
File "hindi.py", line 3, in __main__.convert
Failed example:
convert()
Expected:
'क'
Got:
'\xe0\xa4\x95'
**********************************************************************
1 items had failures:
1 of 1 in __main__.convert
***Test Failed*** 1 failures. 또한 출력 유형을 확인하지 않습니다. 출력 문자열을 비교합니다. 예를 들어 정수이면 정수처럼 인쇄하는 합리적인 유형을 만들었습니다. 그런 다음 합리적인 반환 기능을 가지고 있다고 가정하십시오. 따라서 출력이 합리적인 정수 또는 정수이면 doctest는 차별화되지 않습니다.
r""" ... """)를 사용하여 첫 번째 문제를 해결할 수 있습니다 .
'\\xe0\\xa4\\x95'docstring에서 사용 하십시오.
검색 기반 시스템을 선호합니다 (현재 전자를 사용하는 "nose"및 "py.test").
doctest는 테스트가 문서로도 좋을 때 좋습니다. 그렇지 않으면 코드가 너무 복잡해집니다.