2012-03-21 6 views
3

DataIn(int InputID, string CSVValue)이라는 메서드가있는 클래스가 있는데,이 클래스의 기본 진입 점입니다.다른 메서드에서 호출 된 테스트 메서드

InputID에 기반한이 방법은 CSV 값 매개 변수를 관련 List<string>'s에 저장합니다. InputIDNoOfRows이라는 속성과 동일하면 다른 모든 항목으로 구성된 List<string>을 하나 만듭니다. 그런 다음이 최종 List<string>의 유효성을 검사합니다. 모두 정상이면 중복 확인을위한 빠른 방법으로 HashSet<int>에 결과를 추가합니다.

DataIn = NoOfRows의 InputID가 ValidateData를 호출하는 MergeData를 호출 할 때 DataIn이 StoreData를 호출하도록이 논리를 3 가지 방법으로 분해했습니다.

내 질문에 개별적으로 테스트하기 위해이 메서드를 public으로 만들어야하며 그렇지 않으면 데이터를 개인용으로 유지하고 DataIn에 데이터를 전달하고 병합 된 데이터 List<string>HashSet<int>에 대한 assert를 전달해야합니까? DataIn은 클래스 외부에서 호출되는 메서드가되어 다른 메서드는 public으로 만 unit 테스트를 수행합니다.

다른 방법을 공개하고 테스트해도 괜찮습니까? 그렇다면 예상대로 DataIn을 테스트하지 않거나 둘 다 수행하면 중복 테스트가 끝납니다.

당신의 조언은 무엇입니까?

답변

1

항상 principle of least privilege을 고수하십시오. private 메소드를 public으로 드러내기만하면 단위를 테스트 할 수있는 좋은 디자인이 아닙니다. 대신 public interfaces 만 테스트하면됩니다. 메서드가 여러 입력 방식으로 여러 가지 방식으로 작동하는 경우 예상대로 동작 당 테스트를 작성하고 잘 테스트 한 상태에서 깔끔하고 깨끗한 디자인을 제공해야합니다. 생각의 두 경쟁 학교는 개인 방법을 테스트 할 필요성이있다

+0

내가 내가 테스트를 할 거라고 수행하여 비슷한 논리 http://stackoverflow.com/questions/29354729/how-to-test-2-methods-with-common-logic 2 개 public 메소드가있는 경우 같은 논리가 두 번. 이 경우 어떻게해야합니까? –

1

- 하나는 구현 세부 사항이기 때문에 당신이 이 그들을 테스트 안된다고 말한다; 다른 하나는 이어야 함을 말합니다. 모든 것을 테스트해야하기 때문입니다.

둘 사이의 논쟁의 중간에 들지 않고, 나는 양측 모두 그들의 접근법에 대해 유효한 포인트를 가지고 있다고 언급해야한다. 그러나 분명히 피해야 할 한 가지는 테스트 할 유일한 목적으로 개인용 메서드를 공개하는 것입니다. "개인 메서드 테스트"방법을 사용하기로 결정한 경우이 메서드를 이 아닌 공용으로 설정하고 테스트 어셈블리에 대상 어셈블리의 InternalsVisibleTo 특성을 사용하는 내부 메서드를 표시하게합니다.

관련 문제