Go 언어로 테스트하기위한 적절한 패키지 이름 지정

Go 언어로 테스트하기위한 적절한 패키지 이름 지정

---

Go 내에서 몇 가지 다른 테스트 패키지 명명 전략을 보았고 각각의 장단점과 사용해야하는 것을 알고 싶었습니다.

전략 1 :

파일 이름 : github.com/user/myfunc.go

package myfunc

테스트 파일 이름 : github.com/user/myfunc_test.go

package myfunc

예제는 bzip2 를 참조하십시오 .

전략 2 :

파일 이름 : github.com/user/myfunc.go

package myfunc

테스트 파일 이름 : github.com/user/myfunc_test.go

package myfunc_test

import (
    "github.com/user/myfunc"
)

예는 와이어 를 참조하십시오 .

전략 3 :

파일 이름 : github.com/user/myfunc.go

package myfunc

테스트 파일 이름 : github.com/user/myfunc_test.go

package myfunc_test

import (
    . "myfunc"
)

예는 문자열 을 참조하십시오 .

Go 표준 라이브러리는 전략 1과 2를 혼합하여 사용하는 것 같습니다. 세 가지 중 어느 것을 사용해야합니까? package *_test내 패키지 비공개 메서드를 테스트 할 수 없다는 의미로 내 테스트 패키지에 추가하는 것은 고통 스럽지만 내가 알지 못하는 숨겨진 이점이있을 수 있습니까?

---

나열한 세 가지 전략의 근본적인 차이점은 테스트 코드가 테스트중인 코드와 동일한 패키지에 있는지 여부입니다. 사용에 대한 결정 package myfunc또는 package myfunc_test테스트 파일을 수행할지 여부에 따라 화이트 박스 또는 블랙 박스 테스트를.

프로젝트에서 두 가지 방법을 모두 사용하는 것은 잘못된 것이 아닙니다. 예를 들어 myfunc_whitebox_test.go및 myfunx_blackbox_test.go.

테스트 코드 패키지 비교

• 블랙 박스 테스트 :를 사용 package myfunc_test하면 내 보낸 식별자 만 사용 됩니다 .
• 화이트 박스 테스트 :package myfunc 내 보내지 않은 식별자에 액세스 할 수 있도록 사용 합니다. 내 보내지 않은 변수, 함수 및 메서드에 액세스해야하는 단위 테스트에 적합합니다.

문제에 나열된 전략 비교

• 전략 1 : 파일에서 myfunc_test.go사용 package myfunc—이 경우의 테스트 코드 는이 예제에 있는 myfunc_test.go에서 테스트중인 코드와 동일한 패키지에 있습니다.myfunc.gomyfunc
• 전략 2 : 파일이 myfunc_test.go사용합니다 package myfunc_test.이 경우의 테스트 코드는 myfunc_test.go"별도의 패키지로 컴파일 된 다음 메인 테스트 바이너리와 연결 및 실행됩니다." [출처 : test.go 소스 코드의 58 ~ 59 행 ]
• 전략 3 : 파일 에서 점 표기법을 myfunc_test.go사용 package myfunc_test하지만 가져 오기 myfunc— 전략 2의 변형이지만 점 표기법을 사용하여 myfunc.

---

테스트 범위에 따라 다릅니다. 내 보낸 API를 통해 패키지를 사용하고 있는지 확인하려면 고급 테스트 (통합, 승인 등)를 별도의 패키지에 배치해야합니다.

테스트해야하는 내부가 많은 대형 패키지가있는 경우 테스트에 동일한 패키지를 사용하십시오. 그러나 이는 테스트가 비공개 상태에 액세스하도록 초대하는 것이 아닙니다. 그것은 리팩토링을 악몽으로 만들 것입니다. 이동 중에 구조체를 작성할 때 종종 인터페이스를 구현합니다. 모든 도우미 메서드 / 함수를 개별적으로 호출하는 것이 아니라 테스트에서 호출하는 인터페이스 메서드입니다.

---

You should use strategy 1 whenever possible. You can use the special foo_test package name to avoid import cycles, but that's mostly there so the standard library can be tested with the same mechanism. For example, strings cannot be tested with strategy 1 since the testing package depends on strings. As you said, with strategy 2 or 3 you don't have access to the package's private identifiers, so it's usually better to not use it unless you have to.

참고URL : https://stackoverflow.com/questions/19998250/proper-package-naming-for-testing-with-the-go-language