Moq 내부 방법을 어떻게 테스트합니까?

Question

내 상사가 Moq를 사용한다고 말하면 그게 전부입니다. 내가 좋아하지만 MSTest 나 mbunit 등과 달리 ... 내부 메서드를 테스트 할 수 없다.

그래서 나는 테스트 할 수 있도록 내 인터페이스에서 일부 내부 구현을 공개해야한다.

내가 누락 된 항목이 있습니까?

Moq를 사용하여 내부 방법을 테스트 할 수 있습니까?

덕분에 많은

Answer 1

당신은 MOQ에 대한 방법을 볼 수 있도록하기 위해 InternalsVisibleTo 속성을 사용할 수 있습니다. 공용 방법으로 테스트되지 않은 많은 코드가있는 경우

http://geekswithblogs.net/MattRobertsBlog/archive/2008/12/16/how-to-make-a-quotprotectedquot-method-available-for-quotpartialquot-mocking-and-again.aspx

Answer 2

, 당신은 아마 다른 클래스로 이동해야 코드가 있습니다.

다른 대답에서 말했듯이, 당신은 그것에 대해 InternalsVisibleTo 속성을 사용할 수 있습니다. 그러나 그것이 당신이해야한다는 것을 의미하지는 않습니다.

Answer 3

내부 테스트 방법이 필요하다는 초기 추정은 단위 테스트에 대한 일반적인 초보자의 오해입니다.

개인 메서드를 독립적으로 테스트해야하는 경우가 있지만 99 %의 일반적인 경우는 공용 메서드가 테스트를 통과하기 때문에 개인 메서드가 암시 적으로 테스트되는 경우가있을 수 있습니다. public 메서드는 private 메서드를 호출합니다.

이유 때문에 개인적인 방법이 있습니다. 외부 테스트 가능한 동작이 발생하지 않으면 필요하지 않습니다.

공개 테스트를 완료하면 공개 테스트가 실패합니까? 그렇다면 이미 테스트를 마친 상태입니다. 그렇지 않다면 왜 그걸 필요로합니까? 필요한 항목을 찾아 공용 인터페이스 테스트를 통해 표현하십시오.

TDD의 주된 이점은 코드를 변경하기가 쉽다는 것입니다. 내부 테스트를 시작하면 코드가 변경되고 변경하기가 어려워집니다.

Answer 4

테스트를 위해 내부를 다른 클래스에서 볼 수있게 만드는 데는 아무런 문제가 없습니다. 당신이 수업의 내부를 시험 할 필요가 있다면, 꼭 그렇게하십시오. 메서드가 public이 아니기 때문에 당신이 그들을 무시하고 공개 된 메서드 만 테스트해야한다는 것을 의미하지는 않습니다. 잘 디자인 된 응용 프로그램은 실제로 공개되지 않는 방식으로 클래스 내에 캡슐화 된 코드의 대부분을 갖게됩니다. 따라서 테스트에서 비공개 방법을 무시하는 것은 IMHO의 큰 실수입니다. 단위 테스트의 아름다움 중 하나는 코드의 모든 부분을 테스트하는 것입니다. 테스트가 아무리 작아도 테스트가 모두 실행되고 100 % 실행되는 경우,이 모든 부분을 조합 할 때 매우 합리적인 가정입니다. 응용 프로그램이 최종 사용자에게 올바르게 작동합니다. 물론 후자의 부분이 통합 수준 테스트가 나오는 부분임을 확인하는 것은 다른 논의입니다. 그래서 떨어져 테스트!

Answer 5

InternalsVisibleTo는 내부 테스트 용 친구입니다. 어셈블리에 서명해야하며 안전해야합니다.

Answer 6

내 관점에서 보면 조롱은 우리가 의존하지만 테스트를 시작하지 않는 행동을 조롱하는 데 사용해야합니다. 따라서 :

Q : 빠진 것이 있습니까? - 아무 것도 놓치지 않았습니다. MOQ는 개인 행동을 조롱하는 기능이 없습니다.

Q : Moq?를 사용하여 내부 메소드를 테스트 할 수 있습니까? - 비공개 동작의 결과가 공개적으로 표시 될 수 있다면 그렇습니다. 내부 메서드를 테스트 할 수는 있지만 테스트 할 수있는 Moq 때문이 아닙니다. 여기서 한 가지 지적하고자하는 것은 모의는 테스트 할 능력이 아니라 오히려 우리가 테스트하지는 않지만 의존하는 유사한 행동에 대한 능력이라는 것입니다.

C : TDD의 주요 이점은 코드를 변경하기가 쉽다는 것입니다. 내부 테스트를 시작하면 코드가 딱딱 해지고 변경하기가 어려워집니다. - 2 가지 주된 이유에 대해이 의견에 동의하지 않습니다. 1 : TDD는 코딩 능력에 관한 것만이 아니라 초급 오해가 아닙니다. 빠르지 만 더 나은 품질의 코드입니다. 따라서 더 많은 테스트를 통해 우리는 더 잘할 수 있습니다. 2 : 어떻게 든 내부 메서드를 테스트 할 수 있다면 코드를 더 이상 변경하기가 어렵지 않습니다.