보이드 방법의 단위 테스트

15

응용 프로그램의 버그를 수정하기 위해라는 postLogin기존 메서드에 호출을 추가하여 이름이 지정된 메서드를 수정했습니다 getShoppingCart.

암호

protected void postLogin() {
  getShoppingCart();
}

그러나 단위 테스트를 작성하는 가장 좋은 방법은 무엇인지 잘 모르겠습니다 postLogin.

접근법 1

Mockito의 verify를 사용하여 메소드가 호출되었는지 간단히 확인하십시오.

verify(mock).getShoppingCart();

접근법 2

사용자 장바구니 값을 가져 와서 메소드 호출의 부작용을 테스트하십시오.

AssertNotNull(user.getShoppingCart());

하나의 접근법이 다른 접근법보다 낫습니까?

— A_B
소스

1

테스트를 이해하기 쉽고 코드를 깨끗하게 유지합니다. 당신이 시험 디자인의 확실하지 않은 경우, 그 수 또한 코드 디자인이 꺼져 있다는 신호합니다. " 이 메소드 호출을 추가하면 버그가 수정되는 이유 는 무엇입니까? 이것이 버그를 수정 하는 올바른 방법입니까?"

— Caleb

8

당신하지 않는 getShoppingCart()방법은 부작용을 가지고, 당신은이 호출하는지 테스트 할 필요가 없습니다. 부작용이있는 경우, getXXX()기존에는 메소드가 dem 등원이어야 하기 때문에 실제로 이름을 변경 해야합니다.

— Jules

@ 줄 getNextValue? 아마도 누군가는 "게터라고 부르지 말고 이름을 nextValue"으로 바꾸십시오. 그러나 나는 getNext이전에 사용 된 것을 보았습니다 . 아마도 더 좋은 예는 전자를 나타내는 물체 일 것입니다. 전화하면 getPosition어떻게 되나요? 더 나쁘다getPosition(); getVelocity();

— Aaron

18

나는 보통 방법 2를 선호합니다.

왜? postLogin시스템의 일부 상태를 변경 하고 싶지만이 를 달성하는 방법 (및이를 위해 내부적으로 호출하는 방법)은 구현 세부 사항 일 뿐이므로 단위 테스트는 가정하지 않아도됩니다. 따라서 최종 상태를 확인하는 것만으로 테스트를 수행하는 것이 좋습니다.

— 닥 브라운
소스

4

getShoppingCart를 initializeShoppingCart와 같은 것으로 변경하려고합니다. 메서드의 기능을 확인하지 않고도 메소드를 읽는 사람에게는 메소드의 목적이 분명해야합니다. 이와 같은 부작용으로 인해 메소드 사용자에게 놀라운 동작이 발생할 수 있습니다.

getShoppingCart가 다른 클래스에 있고 이미 단위 테스트 된 경우 접근법 1을 사용합니다. 이미 테스트 한 것을 다시 테스트 할 필요가 없습니다. 이 경우 getShoppingCart가 올바르게 작동하고 postLogin에서 호출되도록 보장하기 위해 나중에 누군가가이 호출을 제거하면 테스트가 실패합니다.

getShoppingCart가 자체적으로 테스트 할 수없는 개인 메소드 인 경우 postLogin이 호출 될 때 getShoppingCart의 원하는 기능이 예상대로 수행되는지 확인하기 위해 접근법 2를 사용합니다.

— 나스티아 S
소스

1

부작용이있는 함수 호출 (void 또는 not)을 테스트 할 때 부작용이 발생하는지 테스트하고 부작용 (시스템 출력 또는 상태 변경)이 원하는 것인지 확인하는 것이 가장 완벽합니다.

— hotpaw2
소스

1

이것이 사실이지만, 발생하는 부작용에 대한 세부 사항 은 다른 모듈의 내부 상태의 일부가 될 수 있으며 이러한 세부 사항을 확인하면 테스트를 모듈뿐만 아니라 그것은 세부 사항이 변경 될 경우 취성 테스트로 이어질 수있는 다른 모듈입니다. 모듈 간 인터페이스를 조롱하면이 문제를 방지 할 수 있습니다.

— Jules

0

디자인에 대해서는 이야기하지 않겠지 만, 단위 테스트는 도메인에서 작업에 관계없이 기술적으로 어떤 방법, 즉 분석법이 무엇인지 테스트하기위한 첫 번째 방법입니다 postLogin. 기술적으로 호출 getShoppingCard하므로 실제로 호출하는 테스트를 수행해야하며 getShoppingCard, 수행중인 작업 getShoppingCard을 테스트 하기위한 또 다른 테스트를 작성 하고 부작용이있는 경우 새 테스트 내부에서 확인합니다.

— 라블 로즈 메릴
소스

0

postLogin에 버그가 있습니다. 따라서 가장 먼저해야 할 일은 postLogin을 호출 할 때 예상되는 정보 세트없이 "실패"하는 단위 테스트를 만드는 것입니다.

위의 아이디어로부터, 제안 된 2의 다른 대안은 쇼핑 카트에 관한 정보를 파라미터로서 주입하는 것이다. 올바른 정보가 없으면 확인되지 않은 예외가 발생합니다. 이것은 정확한 세부 사항이 없다면 당신의 방법이 끝났다는 것을 분명히 할 것입니다.

이를 위해 지금 바로 postLogin을 호출하는 클라이언트가 장바구니 정보를 전달해야하는 경우 약간의 변경이 필요합니다. 나에게 이것은 여전히 결합되어 있습니다. 이 연결은 발신자가 수행합니다.

테스트 할 실제 메소드가 postLogin이기 때문에 postLogin 내부에서 getShoppingCart를 테스트 할 필요조차 없습니다. 버그가있는 유일한 버그이며 올바른 수정 및 유효성 검사가 필요한 유일한 버그입니다. 주입 된 종속성을 사용하면 다른 조건에서 쉽게 테스트하고 오류가 발생하지 않는지 확인할 수 있습니다.

— 구골
소스