Pojos에 대한 주니트 테스트

StackOverflow https://stackoverflow.com/questions/674408

  •  21-08-2019
  •  | 
  •  

문제

나는 모든 간단한 콩 (pojos)에 대한 단위 테스트를 만들어야하는 프로젝트를 진행합니다. 그들이 구성된 모든 것이 게터와 세터로 구성된 경우 Pojos에 대한 단위 테스트를 만들 수 있습니까? Pojos가 시간의 약 100% 효과가 있다고 가정하는 것이 안전한 가정입니까?

복제 - @entity pojos를 테스트해야합니까?

또한보십시오

가짜 리포지토리 대신 DB에서 테스트를 실행하는 것이 좋지 않습니까?

Getters and Setters를 자동 테스트하는 Java 장치 테스트 프레임 워크가 있습니까?

도움이 되었습니까?

해결책

TDD의 규칙은입니다 "파손될 수있는 모든 것을 테스트하십시오" 게터가 깨질 수 있습니까? 일반적으로 그렇지 않으므로 테스트하지 않습니다. 게다가, 코드 i 하다 테스트는 확실히 Getter라고 부릅니다 ~ 할 것이다 테스트됩니다.

내 개인적인 규칙은 결정을 내리거나 사소한 계산 이상을 만드는 기능에 대한 테스트를 작성하는 것입니다. 나는 시험을 쓰지 않을 것이다 i+1, 그러나 나는 아마도 할 것입니다 if (i<0)... 그리고 확실히 할 것입니다 (-b + Math.sqrt(b*b - 4*a*c))/(2*a).

BTW, Pojo에 대한 강조는 그 뒤에 다른 이유가 있습니다. 우리는 Pojos에 쓰여진 방대한 양의 코드를 원합니다. 그들이 운영하는 환경에 의존하지 마십시오. 예를 들어, 컨테이너 내에서 실행할 때 서블릿을 테스트하기가 어렵습니다. 따라서 우리는 서블릿이 환경에 의존하지 않기 때문에 테스트하기 쉽습니다.

다른 팁

pojos에는 equals (), hashcode (), compareto () 및 기타 다양한 함수와 같은 다른 함수가 포함될 수 있습니다. 이러한 기능이 올바르게 작동한다는 것을 아는 것이 유용 할 수 있습니다.

간단한 속성 게터와 세터를 테스트 할 포인트가 없다고 생각합니다. 단위 테스트의 점은 컴파일러가 작동하는지 확인하지 않습니다.

그러나 조건부, 널 체크 또는 기타 사소한 행동을 getters and setters (또는 기타 방법)에 추가하자마자 단위 테스트를 추가하는 것이 적절하다고 생각합니다.

나는 다음과 같은 일 때문에 두 시간을 보냈습니다.

int getX()
{
    return (x);
}

int getY()
{
    return (x); // oops
}

간단한 게터에 대한 테스트를 작성하는 데 거의 시간이 걸리지 않기 때문에 지금은 습관에서 벗어납니다.

나는 Intellij를 IDE로 사용하고, 그것은 저를 위해 사소한 pojo를 씁니다 - 확실히 생성자와 getters/settors. 버그가 내가 쓴 테스트 코드에있을 가능성이 높기 때문에 단위 테스트의 어느 정도가 보이지 않습니다.

내 대답은 사소한 게터와 세터가 자신의 테스트를 가치가 없다는 것입니다. 간단한 읽기 또는 쓰기 이외의 코드를 추가하면 테스트를 추가합니다.

물론, 이것은 모두 보일러 플레이트이므로, 값이 있다고 생각되면 게터와 세터에 대한 단위 테스트를 생성하는 스크립트를 쉽게 작성할 수 있습니다. 특정 IDE는이 보일러 플레이트 코드에 채워진 테스트 방법으로 테스트 케이스를 생성하는 템플릿을 정의 할 수 있습니다 (여기서 Intellij를 생각하고 있지만 Eclipse도 처리 할 수는 있지만 둘 중 하나를 처리하지는 않았지만 아마도 이와 같은 작업을 수행하지는 않았습니다. IDE).

내 경험상, getters and setter만으로 Pojos에 대한 단위 테스트를 만드는 것은 과잉입니다. 물론 널 확인하고 특별한 일을하는 것과 같은 게터/세터에 추가 논리가 있다면 단위 테스트를 만드는 것보다 몇 가지 예외가 있습니다.

또한 Pojo에 버그가 있으면 단위 테스트를 만들어 다시 발생하지 않도록 할 수 있습니다.

당신이 작성하지 않았는지 확인하는 것은 간단한 테스트의 가치가있을 것입니다.

public void setX(int x) {
   x = x;
}

그것을 피하기 위해 코딩해야하지만 ( final 메소드 파라미터 또는 유사한 수정 자. 또한 액세서를 생성하는 방법과 복사/페이스트 오류 등으로 고통받을 수있는 경우 (이는 사용법을 시행하려는 환경에서도 발생합니다.

그러나 많은 세터/게터가 포함 된 수업에 대한 나의 주요 관심사는 수업은 무엇을하고 있습니까? ? 객체는 단순히 데이터를 보유하고 반환하기보다는 자신을 위해 작업을 수행해야합니다. 이것들이 데이터 엔티티 객체라면 세터/게터 패턴이 정확할 수 있습니다. 그러나 더 나은 패턴은 객체에 데이터를 설정하고 객체에 데이터를 반환하는 대신 작업을 수행하도록 요청하는 것입니다 (은행 잔액을 계산하고 로켓을 시작하십시오).

단위 테스트는 코드가 올바르게 작동하는 것을 검증 할뿐만 아니라 예상 행동을 문서화합니다. 나는 길을 따라 내려 가기 때문에 몇 번이나 물건이 깨는 것을 보았는지 모르겠다. 누군가는 포조에서 getter 또는 setter의 행동을 바꾸고 예기치 않게 다른 것을 깨뜨린다 (예를 들어, 누군가가 세터에 논리를 추가한다. 누군가가 문자열에서 널 값을 설정하면 세터가 빈 문자열로 변경하여 NPE가 발생하지 않도록합니다).

나는 데이터 저장소의 단위 테스트를 시간 낭비로 보지 않고 향후 유지 보수를위한 안전망으로 본다. 즉, 이러한 물체를 검증하기 위해 수동으로 테스트를 작성하고 있다면 어려운 방법으로 수행하고 있습니다. 같은 것을 살펴보십시오 http://gtcgroup.com/testutil.html

오픈 소스 유틸리티가 있습니다 http://meanbean.sourceforge.net/ 이를 통해 Pojo 's를 테스트 할 수 있습니다. 이 유틸리티가 제공하는 내용과 사용 이유에 대한 장점/질문을 설명하는 페이지도 있습니다.

나는 결코 그것을 피곤하지 않았지만 (아직), 그것은 나에게 추천되었다.

IMHO Pojos는 기능 테스트에 대한 논리가 테스트 될 때 자동으로 테스트됩니다.

그러나 특정 사용 사례가 단위 테스트를위한 Pojos를 제거하려면 두 가지 방법에 따라 달성 할 수 있습니다.

  1. 라이브러리 사용 : Pojos를 테스트하는 데 도움이되는 기존 라이브러리를 사용하십시오. 내가 겪은 그러한 도서관 중 하나는 Meanbean입니다.

    심판: http://meanbean.sourceforge.net/

    Maven: http://mvnrepository.com/artifact/org.meanbean/meanbean (현재 버전 : 2.0.3)

  2. Pojos를 무시하십시오 : Sonar는 단위 테스트 범위 보고서에서 제외 할 Pojos 또는 특정 패키지를 제외하도록 구성 할 수 있습니다. 아래 몇 가지 예 :

    <properties>
    <sonar.coverage.exclusions>
        **/domain/**/*,
        **/pojos/*
    </sonar.coverage.exclusions>
</properties>

코드 커버리지를 위해 Cobatura를 실험하고 있으며 같은 문제를 발견했습니다.

코드 커버리지 에이 클래스를 포함하지 않는 클래스에 추가 할 주석이 있으면 좋을 것입니다. 그러나 Pojo를 별도의 패키지에 넣은 다음 해당 패키지를 분석에서 제외 할 수 있습니다.

도구에 따라 문서를보고 ANT, Maven 또는 Command Line에서 작동합니다.

방금이 작업을 수행하는 프로젝트를 시작했습니다. 지금은 알파 이전 단계에 있습니다. Eclipse 플러그인입니다.

일반적으로 Pojo Setter/Getter가 반드시 테스트가 필요하지 않다는 데 동의하지만 시간이 지남에 따라 상황이 바뀌면 Pojo의 테스트에 대한 더 많은 테스트를 더 쉽게 추가 할 수 있기 때문에 간단한 테스트를하는 것이 좋습니다. . 단위 테스트가 설정되어 있고 세터/getter를 테스트하는 방법이 있습니다. 새로운 복잡성을 처리하기 만하면됩니다.

이것은 또한 코드 커버리지 보고서에 도움이되며 관리자를 행복하게 유지하는 데 도움이됩니다. (우리 회사는 Emma를 사용합니다).

https://sourceforge.net/projects/unittestgplugin/

이 문제는 Lombok 라이브러리를 사용하여 해결할 수 있습니다. Lombok 라이브러리는이 보일러 플레이트 코드와 Equals 및 Hashcode를 제거합니다.

따라서 평등 및 해시 코드에 대한 특정 요구 사항이 없으면 테스트 할 필요가 없습니다.

https://projectlombok.org/

원하는 단위 테스트 코드 알다 작동합니다 (물론 테스트 된 상황). 테스트 코드를 단위하지 마십시오.

나는 내가 확실히 확실히하고 싶다고 생각할 수 없다.

Getters와 Setter가 IDE를 사용하여 만들어 졌다면 괜찮을 것이라고 생각합니다. 코드를 넣을 다른 것들이 있습니다. 분명히, 당신은 직렬화/de-serialization을 위해 pojo를 테스트 할 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top