테스트 패키지의 명명 규칙

실제로 테스트 패키지와 마찬가지로 테스트 패키지의 이름을 지정합니다. 그래서 우리는이 구조로 끝납니다 :

src/main/java
    com.hello.world
        helloWorld.java
src/test/java
    com.hello.world
        helloWorldTest.java

패키지 이름 만 제공하면 "test"와 "to-test"를 구분할 수 없기 때문에 항상 이것이 현명하지 않다고 생각했습니다. 반면에 나는 이것이 어떻게 든 중요한 사건을 실제로 찾지 못했습니다. 패키지와 테스트 클래스 및 소스 클래스 모두에 대해 동일한 명명 규칙을 사용하는 것이 좋습니다. 그렇지 않다면 더 나은 방법은 무엇입니까?

naming packages

— 홀 데브
소스

좋은 습관인지 잘 모르겠지만 인기가 있습니다. 패키지 이름, 메소드 이름 등에 "Test"를 넣는 다른 옵션은 "Smurf naming"을 너무 많이 사용합니다. "패키지 이름 만 제공하는 경우"테스트 "와"테스트 할 "을 구별 할 수없는 문제가 발생하는 경우를 생각하기가 어렵습니다.

— David Arno

@DavidArno 입력 해 주셔서 감사합니다 :) 스머프 이름을 피하는 방법? 우리는 com.hello.world.test.helloWorld.java로 끝날 것입니다.

— OddDev

당신이 방법이 때 "스머프"문제는 더 XXXTest()의를 com.hello.world.test.helloWorldTest.java. 일반적인 조언은 경로에 "Test"가 한 번만 나타나도록하는 것입니다. 따라서 (a) 패키지 이름으로 테스트를 사용하고 (테스트 파일 이름을 테스트중인 파일과 동일하게) 또는 (b) 패키지 이름을 파일 / 클래스 이름에 "test"를 추가하십시오.

— David Arno

@DavidArno 아, 설명해 주셔서 감사합니다! 첫 번째 의견이 잘못되었습니다. 이제 알겠습니다.

— OddDev

글쎄, 그것이 확실하지 않다면, 나는 나의 첫 번째 의견이 잘못 되었다고 주장 할 것이다 :)

— David Arno

좋은 컨벤션입니다.

때로는 패키지 전용 클래스 및 메서드에 대한 단위 테스트를 작성하려고합니다. 다른 패키지에 배치 된 단위 테스트 클래스에서는 호출 할 수 없습니다.

프로덕션 코드를 컴파일하거나 실행할 때 클래스 경로에 없어야하는 것과 동일한 네임 스페이스에서 단위 테스트 클래스를 사용하는 것에 대해 혼동해서는 안됩니다.

다음은 공용 인터페이스, 공용 팩토리 클래스 및 두 개의 패키지 전용 구현 클래스가있는 소형 모듈의 예입니다.

src/main/java:
    com.hello.transmogrifier
        public interface Transmogrifier
        public class TransmogrifierFactory
        class MapTransmogrifier implements Transmogrifier
        class ListTransmogrifier implements Transmogrifier

scr/test/java:
    com.hello.transmogrifier
        public class TransmogrifierFactoryTest
        public class MapTransmogrifierTest
        public class ListTransmogrifierTest

Transmogrifier 인터페이스의 구현을 숨기는 것이 올바른 설계 선택이 될 수 있습니다. 아마도 구현을 선택하는 것은 팩토리 클래스의 책임 일 것입니다.

구현은 패키지 전용이므로 단위 테스트 클래스를 직접 테스트하려면 동일한 패키지에 배치해야합니다. 다른 패키지에 단위 테스트 클래스가있는 경우 테스트에서 공용 인터페이스 및 팩토리 클래스에만 직접 액세스 할 수 있습니다.

— 온다
소스

"보통 패키지-개인 클래스 및 메소드에 대한 단위 테스트를 작성하려고합니다." 아니! 이것은 실제로 나쁜 습관입니다. 패키지 개인 유형은 구현 세부 사항이며 직접 테스트해서는 안됩니다. 퍼블릭 API 만 테스트하십시오.

— David Arno

@DavidArno 동의하지 않습니다. 그러나 특정 토론을 피하기 위해 "보통"이라는 단어를 "때때로"라는 단어로 바꿨습니다.

— 에서 오는

당신이 원하는 모든 것에 동의하지 않을 수도 있지만, 코드 조각의 내부 작업을 테스트하면 내부 작업과 테스트 사이의 긴밀한 연결과 간단한 리팩토링 중에 쉽게 깨지는 테스트를 수행 할 수 있습니다. 매우 나쁜 연습입니다.

— David Arno

공장에서 무엇을 하든지 모든 Transmogrifier 구현이 작동하는지 확인하려면 각 구현을 테스트하는 단위 테스트를 작성합니다. 클래스가 패키지 전용 인 경우에도 구현에 공유 공용 API가 있습니다. 공개 API를 변경하지 않으면 이러한 테스트가 중단되지 않습니다. 실제로, 나는 Transmogrifier에 대한 일반적인 테스트를 작성한 다음 각 구현에 대해 실행할 것입니다. 팩토리를 사용하여 각 구현을 얻을 수는 있지만 Transmogrifiers를 테스트 할 때 이러한 종속성이없는 것이 좋습니다.

— 에서 오는

그러던 어느 날, 당신은 볼 MapTransmogrifier과 ListTransmogrifier당신이 만드는, 그래서 그들은 하나 개의 클래스로 만들 수있는 결정 ListMapTransmogrifier, 사용하는 두 클래스를 삭제할 수있는 공장을 수정합니다. 둘 다의 모든 테스트를 수정해야하므로 이제 코드, 컴파일되지 않습니다 MapTransmogrifierTest및 ListTransmogrifierTest그것을 컴파일 얻을. 테스트가 실패합니다. 테스트를 변경하거나 생성했기 때문 ListMapTransmogrifier입니까? 밖으로는 디버거가 알아낼 수 있습니다 ... 또는 테스트가 팩토리를 사용할 때 리팩터링을 수행하고 모든 컴파일을 계속합니다 ...

— David Arno