2012-10-03 3 views
2

저는 Mockito를 사용하여 비즈니스 객체를 단위 테스트하고 있습니다. Business Object는 일] 적으로 DB에서 데이터를 가져 오는 DAO를 사용합니다. 비즈니스 오브젝트를 테스트하기 위해, 나는 모든부분 조롱은 나쁜 습관으로 간주됩니까? (Mockito)

when(...).thenReturn(...) 

문을 작성하는 것보다 (는 HashMap의 데이터를 유지하는) 별도의 메모리 DAO를 사용하는 것이 더 쉽습니다 것을 깨달았다. 이러한 DAO를 만들려면, 나는 시작 부분 조롱과 같이 내 DAO 인터페이스 :

when(daoMock.getById(anyInt())).then(new Answer() { 
    @Override 
    public Object answer(InvocationOnMock invocation) throws Throwable { 
     int id = (Integer) invocation.getArguments()[0]; 
     return map.get(id); 
    } 
}); 

하지만 그냥 완전히 새로운 DAO 구현 자신을 구현하기 쉽게했다 그것은 나에게 발생 (사용하는 메모리의 HashMap) Mockito (InvocationOnMock 객체에서 인수를 얻을 필요가 없음)를 사용하지 않고 테스트 된 비즈니스 객체가이 새로운 DAO를 사용하도록 만들지 않아도됩니다.

또한 부분적 조롱은 나쁜 습관이라고 생각했습니다. 내 질문은 : 내 경우에 내가 나쁜 행동을하는거야? 단점은 무엇인가? 나에게 이것은 괜찮은 것처럼 보이고 나는 잠재적 인 문제가 무엇인지 궁금해하고있다.

답변

1

수업을 테스트 할 때 종종 모의이트로 만든 가짜와 가짜의 조합을 사용합니다. 이는 매우 묘사하는 내용입니다. 귀하의 상황에서 가짜 구현이 더 좋은 것으로 동의합니다.

부분적인 조롱은 특히 잘못된 것은 아니지만 실제 객체를 호출 할 때와 조롱 된 메소드를 호출 할 때를 결정하는 것이 조금 더 어려워집니다. 특히 Mockito가 자동으로 최종 메소드를 모의하지 못하기 때문입니다. 원래 클래스에 대한 순진한 변경으로 인해 부분 모의 구현이 변경되어 테스트가 중단됩니다.

유연성이 있다면 호출해야하는 메서드를 제공하는 인터페이스를 추출하여 모의 또는 가짜를 선택하는 것이 더 쉽습니다.

가짜를 작성하려면 간단한 클래스 (원하는 경우 테스트에 중첩 됨)를 사용하여 Mockito없이 작은 인터페이스를 구현하십시오. 이렇게하면 무슨 일이 일어나는지 쉽게 알 수 있습니다. 단점은 매우 복잡한 가짜를 작성하면 가짜를 테스트해야한다는 것을 알 수 있습니다. 좋은 가짜 구현을 사용할 수있는 많은 테스트가 있다면, 이것은 추가 코드의 가치가있을 것입니다.

마틴 파울러 (그의 책 리팩토링으로 유명)의 기사 인 "Mocks aren't Stubs"을 적극 권장합니다. 그는 여러 유형의 테스트 복식의 이름과 그 차이점을 살펴 봤습니다.

+0

감사합니다. 이것은 나에게 유용한 조언이었습니다. 나는이 기사를 읽고 다른 대답을 기다렸다가 이것을 이것을 허용 된 것으로 표시했습니다. – machinery

2

가짜 DAO가 HashMap에 의해 백업되어야하는 이유가 궁금합니다. 당신의 검사가 너무 복잡한 지 궁금합니다. 저는 각자가 SUT의 행동 중 한 측면을 테스트하는 매우 간단한 테스트 방법을 사용하는 것을 좋아합니다. 원칙적으로 이것은 "테스트 당 하나의 주장"이지만, 때로는 소수의 실제 assert 또는 verify 행으로 끝나기도하지만, 예를 들어 복잡한 객체의 정확성을 주장하는 경우가 있습니다. 이 원칙에 대해 자세히 알아 보려면 http://blog.astrumfutura.com/2009/02/unit-testing-one-test-one-assertion-why-it-works/ 또는 http://blog.jayfields.com/2007/06/testing-one-assertion-per-test.html을 읽어보십시오.

각 테스트 방법에 대해 위조 된 DAO를 반복해서 사용하지 않아야합니다. 아마 단 한 번 또는 두 번 정도. 따라서 데이터가 가득한 큰 HashMap을 가지고있는 것은 나에게 중복 된 것으로 보일 것입니다. 또는 귀하의 테스트가해야 할 일보다 더 많이 수행되고 있다는 표시 일 수 있습니다. 각 테스트 방법에 대해 하나 또는 두 개의 데이터 항목 만 필요합니다.DAO 인터페이스의 Mockito 모의를 사용하여 이들을 설정하고 when ... thenReturn을 테스트 메소드 자체에 넣으면 각 테스트는 간단하고 읽기 쉽습니다. 특정 테스트에서 사용하는 데이터가 바로 표시되기 때문입니다.

"arrange, act, assert"패턴 (http://www.arrangeactassert.com/why-and-what-is-arrange-act-assert/http://www.telerik.com/help/justmock/basic-usage-arrange-act-assert.html)을 읽고 테스트 패턴에 다른 부분을 흩어지게하는 대신 각 테스트 방법에이 패턴을 구현하는 데주의해야 할 수도 있습니다 수업.

실제 테스트 코드를 더 이상 보지 않아도 다른 조언이 무엇인지 알기가 어렵습니다. 모키토 (Mockito)는 조롱하는 것을 더 어렵지 않게 만든다. 그래서 당신을 위해 그런 일이 일어나지 않는 곳에서 시험을 치른다면 비표준 일을하고 있는지 물을만한 가치가 있습니다. 당신이하고있는 일은 "부분적 조롱"이 아니지만 확실히 저에게 시험 냄새 같아 보입니다. 많은 테스트 방법을 함께 연결하기 때문에 적어도 - HashMap의 일부 데이터를 변경해야한다면 어떤 일이 일어날 지 스스로에게 물어보십시오.

https://softwareengineering.stackexchange.com/questions/158397/do-large-test-methods-indicate-a-code-smell도 유용 할 수 있습니다.