단위 테스트는 저장소에 저장해야합니까?

50

저는 GitHub에 저장하고있는 라이브러리에 대해 단위 테스트를 실제로 실시하고있는 프로그래머입니다.

레포지토리에 테스트 스위트를 포함시킬 수도 있었지만 다른 프로젝트를 살펴보면 테스트가 포함 된 것 같습니다.

이것이 잘못된 형태로 간주됩니까? 사용자가 작업 코드에만 관심이 있고 어쨌든 자신의 프레임 워크에서 테스트 할 것이라는 아이디어가 있습니까?

version-control unit-testing

— 파리 민턴
소스

13

왜 안돼? 테스트는 프로젝트와 함께 제공되거나 거의 쓸모가 없습니다.

61

일부 프로젝트가 저장소에 단위 테스트를 포함하지 않는다는 사실은 이러한 테스트가 처음에 없기 때문에 더 가능성이 높습니다.

— prasopes

4

그것들은 개별적으로 빌드되지만, 그렇지 않으면 u 테스트는 코드와 밀접하게 결합됩니다. 일관성을 유지하려면 일종의 종속성 관리가 있어야합니다. 저장소 등을 테스트하기 위해 동일한 저장소,

— 하위

2

@stoupa는 꽤 옳습니다. 최고의 것으로 생각하면 어딘가에 숨겨진 훌륭한 테스트 캐시가 있지만 실제로는 프로그래머가 게으르다는 것입니다.

— Cascabel

2

빌드 스크립트에서 테스트 클래스 컴파일을 비활성화하는 것이 좋습니다.

— user606723

119

테스트는 반드시 저장소에 넣어야합니다. 테스트는 내 의견으로는 코드의 일부이며 다른 사람들이 코드를 이해하는 데 도움이 될 수 있습니다 (잘 작성된 경우). 또한 코드베이스를 변경하거나 기여할 때 다른 사람들을 도울 수 있습니다. 테스트를 잘하면 변경 사항이 실수로 아무 것도 손상되지 않는다는 확신을 줄 수 있습니다.

그러나 테스트 코드는 프로덕션 코드와 잘 구분되어야합니다. 예를 들어 Maven은 프로덕션 및 테스트 코드를 다른 폴더에 저장하여이를 달성합니다. "이 파일은 프로덕션 또는 테스트 코드의 일부입니까?"라는 질문은 절대 발생하지 않아야합니다.

개인적으로 사용 된 라이브러리에 대한 단위 테스트를 내 코드로 작성하지 않습니다. 나는 그들이 작동 할 것으로 예상한다 (적어도 릴리스 버전을 사용할 때 버그가 나타날 수 있음). 통합 테스트에서 일부 테스트 범위를 얻지 만 충분하지 않습니다.

— ftr
소스

1

다른 예로, ipython의 testing 폴더를 살펴보십시오 . 누군가가 그것을 체크 아웃하더라도, 어디에 놓아도 테스트에 대한 상대 링크는 여전히 참입니다. 테스트하기가 쉽지 않으므로 새 개발 시스템이 올바르게 구성되어 있는지 확인해야합니다.

— 스펜서 Rathbun

테스트는 코드의 일부일뿐만 아니라 설명서 및 사양의 일부이기도합니다. 테스트 (실행 및 통과)는 "살아있는 문서"입니다.

— Michael Easter

54

체크인 된 소스 코드에 단위 테스트를 포함 하지 않으면 다음 을 수행 하십시오.

해당 코드의 사본을 다운로드하여 작성하는 사람이 의도 한 방식으로 작동하는지 어떻게 확인할 수 있습니까? 컴파일러 및 라이브러리 버그는 드물고 데이터 오류 (특히 소스 코드를 컴파일 할 수없는 오류)는 훨씬 더 드물지만 특히 빌드 환경을 어느 정도까지 지시 할 수없는 경우 에는 확실히 오류가 발생할 수 있습니다 . 고용주는 어떤 도구를 사용할 것인지 지시 할 수 있습니다.
소스 코드의 로컬 사본에 문제가 발생하면 어떻게 테스트를 다시 받습니까?
새로운 개발자는 변경 사항이 기존 코드 기반에서 아무런 변화가 없는지 어떻게 확인합니까?

결론적 으로 공식 소스 코드 저장소에 작성된 단위 테스트는 포함하지 않는 것이 좋습니다.

— CVn
소스

7

물론 몇 가지 이유로 저장소에 단위 테스트를 넣어야합니다.

이전 버전으로 쉽게 되돌릴 수 있습니다
프로젝트를 진행하는 다른 사람들도 단위 테스트에 액세스 할 수 있습니다
어떤 사람들은 문서 (TDD 및 BDD)의 일부로 단위 테스트를 고려합니다

— Јовић
소스

6

다른 컴퓨터에서 실행할 수있는 기회가 있다면 반드시 포함 시키십시오. 그것들은 별도로 구축되어야하므로 사용자는 필요하지 않으며 추가 종속성이있을 수 있지만 확실히 포함되어야합니다.

리포지토리에 테스트를 포함하지 않는 대부분의 프로젝트에는 단순히 아무것도없는 것으로 의심됩니다.

테스트를 별도의 모듈로 만들어야하는 이유가있을 수 있으므로 이전 코드에 대해 새 테스트를 쉽게 실행할 수 있습니다. 명령 행을 통한 API 안정 라이브러리 또는 블랙 박스 테스트에 유용합니다. 새로운 테스트가 이전 코드로 컴파일되지 않는 컴파일 된 언어의 유용성은 제한적입니다.

— 얀 후덱
소스

5

물론. 여기에 추가 보너스 포인트는 소스 파일의 버전 X를 테스트하는 버전 Y를 추적하는 기능에 있습니다. 다시 말해, 이전 버전으로 돌아가서 해당 버전에 맞게 설계된 적절한 테스트를 수행 할 수 있어야합니다 (API 변경 등의 경우).

— 곧
소스

3

방금 ".Brownfield Application Development in .Net"을 읽었으며 소스 제어 및 단위 테스트를 포함하는 위치 / 방법 / 왜 (특히 연속 통합 영역)를 포함하여 애플리케이션 구조에 대한 훌륭한 조언을 제공합니다. . .Net 개발자 인 경우 권장합니다.

— Seanfitzg
소스