환경 (비주얼 스튜디오 프로페셔널 2008 C#의 윈폼 응용 프로그램)NUnit과 모범 사례
내가 NUnit과 모범 사례에 대한 지침에 대한 약간의 주위에 파고했습니다. 상대적으로 고립 된 환경에서 일하는 솔로 프로그래머로서 집단적 지혜가 나를 도울 수 있기를 바라고 있습니다.
Scott White는 몇 가지 좋은 시작점이 있습니다. here하지만 그가 말한 모든 것에 완전히 동의합니다. 특히 2 번 지점입니다. 내 직감은 테스트되는 코드에 대한 테스트가 가까울수록 당신은 완전한 테스트 커버리지를 얻으려고합니다. Scott의 블로그 게시물에 게시 된 내용은 공개 인터페이스 테스트가 모범 사례로 간주되는 경우가 많았지 만 테스트 프레임 워크가 일반적인 클래스 소비자가 아니라고 주장합니다.
NUnit에 대한 모범 사례로 추천 할 수있는 것은 무엇입니까?
저는 비슷한 상황에 있으며,이 질문은 내가하는 일을 설명합니다 keep-your-source-close-and-your-unit-tests-closer. 너무 많은 다른 사람들이 내 접근 방식에 매혹되지 않았지만 완벽하게 작동합니다.
포인트 2로 "솔루션 별 bin 폴더"를 의미하는 경우 - 귀하의 요점을 볼 수 있습니다. 개인적으로, 각 테스트 프로젝트에 참조를 추가하기 만하면됩니다. 반면에, 당신이 정말로 "(1b)"당신의 코드와 같은 어셈블리에 테스트를하지 않는다면 나는 그와 진심으로 동의하고 당신과 의견을 달리한다. 코드 명확성과 조직을 향상시키기 위해 테스트는 프로덕션 코드와 구별되어야합니다. 테스트 클래스를 별도로 유지하면 다음 프로그래머가 더 쉽게 이해할 수 있습니다. 테스트에서 내부에 액세스해야하는 경우 - 내부 메서드가 어셈블리에 "public"이므로 Assembly.cs 파일에서 InternalsVisibleTo 구문을 사용할 수 있습니다.
저는 일반적으로 코드의 공용 인터페이스 만 테스트하는 것으로 충분하다고 권장합니다. TDD을 올바르게 사용하면 코드의 개인 메소드가 이전 공용 코드의 리팩토링이 될 것이고 공용 메소드를 통해 충분한 테스트 커버리지를 갖게 될 것입니다. 물론 이것은 법이 아닌 지침이므로 개인적인 방법을 테스트하고 싶을 수도 있습니다. 이 경우 접근자를 만들고 리플렉션을 사용하여 private 메서드를 호출 할 수 있습니다.
단위 테스트와 코드 범위를 나란히 사용하는 것이 좋습니다. 코드 커버리지는 더 많은 테스트가 필요할 때를 식별하는 유용한 경험적 방법 일 수 있습니다. 커버리지가 부족하면 더 많은 테스트가 필요한 곳을 나타내는 지침으로 사용되어야합니다. 이것은 당신이 100 % 적용 범위를 필요로한다고 말하는 것이 아닙니다. - 일부 코드는 단위 테스트 (예 : 자동 속성)를 보증 할만큼 충분히 간단 할 수도 있고 기존 테스트에 의해 영향을받지 않을 수도 있습니다.
기사와 관련하여 몇 가지 문제점이있었습니다. 아마도 가장 큰 것은 단위 테스트를 위해 데이터베이스에서 벗어난 추상화가 없다는 것입니다. 아마도 DB에 대해 수행해야하는 통합 테스트가있을 수 있습니다. 그렇지 않으면 자신의 정확성을 확신 할 수없는 경우 트리거 또는 제약 기능을 테스트 할 때가 있습니다. 그렇지만 일반적으로 데이터 액세스를 인터페이스로 구현해야한다고 생각합니다. 그런 다음 실제로 단위 테스트에 실제 구현을 조롱하여 실제로 데이터베이스에 연결할 필요가 없도록하십시오. 나는 나의 시험이 더 빨리 달리는 것을 발견한다. 그래서 나는 이것을 할 때 더 자주 시험한다. "가짜"데이터베이스 인터페이스를 구축하는 데 약간의 시간이 걸릴 수 있지만 데이터 액세스에 동일한 디자인 패턴을 고수하는 한 재사용 할 수 있습니다.
마지막으로 nUnit을 사용하든 MSTest를 사용하든 매우 유용한 플러그인 인 TestDriven.Net과 함께 nUnit을 사용하는 것이 좋습니다. 오른쪽 클릭 컨텍스트 메뉴를 사용하여 테스트를 실행하거나 디버그하는 것이 매우 편리합니다.
내 본능은 가까이 테스트는 코드에 당신이 완료 테스트 커버리지를 얻을 수있는 가능성이 테스트중인 말해. 댓글에서 Scott의 블로그 게시는 공용 인터페이스를 테스트하는 것만으로도 은 우수 사례로 간주되지만, 은 테스트 프레임 워크가 일반적인 클래스 소비자가 아닌 이라고 주장합니다.
공개 진입 점만 사용하여 코드를 테스트 할 수없는 경우 디자인 문제가 발생합니다. TDD 및 SOLID principles에 대한 자세한 내용 (특히 단일 책임 원칙 및 종속성 반전)을 읽어야합니다. 그런 다음 TDD 방식을 사용하면 클래스의 전용 파트를 테스트 할 때 "해킹"을 사용할 필요없이 테스트 할 수 있고 유연하며 유지 관리가 쉬운 코드를 작성할 수 있습니다.
또한 Google's guide to testability by Miško Hevery을 읽기를 적극 권장합니다.이 주제를 다루는 많은 코드 샘플이 있습니다.
해당 링크는 404입니다. http://misko.hevery.com/code-reviewers-guide/를 의미합니까? – Andrew
예, 링크가 수정되었습니다. –