2014-01-20 3 views
4

내 프로젝트에서 TDD를 연습하기 시작했습니다. 백그라운드로 레거시 코드도 포함되어 있습니다. Mockito를 조롱 프레임 워크로 사용하고 Spring MVC 접근법을 따른다.단위 테스트 및 너무 많은 모델 번호

많은 다른 DAO 개체로 구현 된 Service 클래스가 @Autowired 속성으로 구현되는 경우가 있습니다. 이러한 서비스에는 간단한 방법이 있습니다 (예 : completeTransaction).

completeTransaction는 책임

  • 업데이트를 완료 DAO 객체의 많은 사용에

그러나 다른 보류중인 작업 닫기 거래

  • 사전에게 비즈니스 프로세스
  • 을 절약 할 수 이러한 작업을 수행 할 때 메서드는 다른 DAO에 대한 호출을 통해 t를 가져오고 업데이트해야합니다. 비즈니스 프로세스 ID를 가져오고, 보류중인 트랜잭션을 가져오고 (해당 업데이트를 저장합니다). 이것은이 메소드를 테스트하는 단위가 많은 @Mock 속성을 추가하게 함을 의미합니다. 그리고 테스트가 실제로 어떤 조건을 테스트하기 전에 끝나기 전에 mock 객체를 설정해야합니다.

    이것은 코드 냄새와 같아서 테스트는 계약서 대신 코드의 구현을 보장하는 것처럼 느껴집니다. 다시 말하지만, 종속성을 조롱하지 않고도 테스트 케이스가 실행되지 않습니다 (NPE 및 다른 이유로 인해).

    내가 이와 같이 코드를 정리할 수있는 전략은 무엇인가? (나는 정말로 질문에 실제 소스 코드를 제공 할 수 없다). 나는 하나의 가능성이 ("getPendingOperations"와 "advanceBusinessProcess"와 같은) 메소드로 facade 클래스를 설정하는 것이라고 생각하고있다. 그런 다음 하나의 의존성을 조롱 할 수 있습니다. 그러나 다음과 같은 상황을 가지고있는 다른 모든 수업에서는 똑같이해야한다고 생각합니다. 그런 다음 더 깨끗한 시험을 위해서 많은 "도우미"수업을 마치는 것이 두려워요.

    고맙습니다.

  • +0

    이 코드를 본 개발자가 없다고 생각합니다. 레거시 코드에서는 전체 흐름을 테스트하기 위해 테스트를 작성하므로 DAO를 모의하고 서비스 및 구성 요소를 허용하는 컨트롤러 수준에서 테스트를 작성합니다. 그들이하는 것을 의미하는 것을하기 위해서 ... –

    답변

    1

    너무 많은 mock을 발견하면 일반적으로 두 가지 일을하고 싶습니다. 필요한 것은 쉽지 않지만 도움이 될 수 있습니다.

    1) 메소드와 클래스를 더 작게 만드십시오.클린 코드는 클래스가 작아야한다는 두 가지 규칙이 있다고 말합니다. 그리고 그 수업은 그때보다 작아야합니다. 이는 테스트하는 단위 (메소드 및 클래스)가 작아지면 종속성도 줄어들 기 때문에 의미가 있습니다. 물론 더 많은 테스트가 끝나지만 각 테스트마다 설정이 적습니다.

    2) Demeter의 법칙 (https://en.wikipedia.org/wiki/Law_of_Demeter)을보십시오. 일련의 규칙이 있지만 기본적으로 속성/메소드 호출의 긴 문자열을 피하기를 원합니다. objA = objB.propertyA.SomeMethod().propertyC; objA를 얻기 위해 이러한 모든 객체를 조롱해야하는 경우 많은 설정이 필요합니다. 하지만 이것을 objA = objB.newProperty;으로 대체 할 수 있다면 objB 만 조롱하면됩니다.

    이 두 가지 모두 은색 글 머리 기호는 아니지만이 아이디어 중 일부를 프로젝트에 사용할 수 있기를 바랍니다.

    +0

    Demeter의 법칙은 실제로 메소드 연쇄에 관한 것이 아니라 속성에 관한 것입니다. http://www.yegor256.com/2016/07/18/law-of-demeter.html을 참조하십시오. – yegor256

    0

    단위 테스트가 completeTransaction 방법을 테스트하는 경우, 해당하는 모든 것을 조롱해야합니다. Mockito를 사용하고 있으므로 verify을 사용하여 올바른 조롱 된 메서드가 호출되었고 올바른 순서로 호출되는지 확인할 수 있습니다.

    단위 테스트가 completeTransaction 메서드를 호출하는 것을 테스트하는 경우 completeTransaction 메서드를 조롱하십시오.

    이 클래스 계층 구조 인 경우 :

     
        class A -> class B -> class C 
    

    (여기서 -> "에 따라"입니다) 클래스 A에 대한 단위 테스트에서

    단위에서 모의에만 클래스 B.

    클래스 B 테스트, 클래스 C 모의.

    +0

    의존성을 조롱 할 필요가 있음을 이해합니다. 그러나 내가 얻으려고하는 것은 때로는 종속성이 손에 들지 않는 것 같습니다. 테스트 코드가 끝나는 곳에서 많은 양의'when () .thenReturn()'테스트를 설정합니다. 설정 코드가 커지면 테스트를 유지하기가 어렵습니다. –

    +0

    "의존성이 사라지면"문제의 근본 원인은 단위 테스트가 아니라 단위 테스트를 거친 클래스입니다. 많은 양의 설정이있는 경우 모의 객체를 초기화하는 비 테스트 메소드를 고려하십시오. 단위 테스트의 결과를 확인하기 위해 비 테스트 방법을 사용하지 말 것을 권장하지만 설정을 위해 기꺼이 권장합니다. – DwB

    +0

    나는 @DwB에 동의한다; 설치를위한 몇 가지 사적인 방법으로 눈을 쉽게 뜰 수 있습니다. –

    관련 문제