MSTest / VS2008을 사용하여 TDD를 완화하는 방법

https://stackoverflow.com/questions/29557

09-06-2019
|

문제

NUnit, MBUnit 등과 같은 다른 테스트 프레임 워크보다 MSTest에서 TDD / 테스트 우선이 더 어렵다는 것을 여러 번 읽었습니다. 몇 가지 제안 된 수동 해결 방법 및 / 또는 타사 비트는 무엇입니까?인프라 정책으로 인해 MSTest가 유일한 옵션 일 때 제안 하시겠습니까?저는 주로 VS 2008 Team Suite에 대해 궁금해하지만, 일부 MSTest 기능이 이제 해당 버전에도 포함되어 있으므로 VS 2008 Pro에 대한 팁도 적합 할 것이라고 생각합니다.

해결책

MSTest는 확실히 일부 오픈 소스 프레임 워크만큼 효율적이거나 확장 가능하지는 않지만 실행 가능합니다. 질문은 대안이 아닌 MSTest로 삶을 더 쉽게 만드는 것에 대해 묻기 때문에 여기에 제 MSTest 팁이 있습니다.

바로 가기 . Haacked가 말했듯이 바로 가기를 배우는 데 몇 초 정도 걸립니다.
현재 상황 . MSTest는 너무 느리기 때문에 가능한 한 현재 컨텍스트에서만 테스트를 실행하십시오. ( CTRL + R , CTRL + T ). 커서가 테스트 메서드에 있으면 메서드 만 실행됩니다. 커서가 메서드 외부에 있지만 테스트 클래스에 있으면 테스트 만 실행됩니다. 그리고 네임 스페이스 등
효율적인 테스트 및 구성 . 개 천천히. 효율적인 테스트를 작성하여 가능한 한 최선을 다하십시오. 느린 테스트를 다른 테스트 클래스 또는 프로젝트로 이동하여 빠른 테스트를 더 자주 실행할 수 있습니다.
WCF로 테스트 . 서비스를 테스트하는 경우 Visual Studio가 ASP.NET 개발 웹 서버를 시작할 수 있도록 테스트를 실행하는 대신 디버그 테스트를 수행해야합니다. 이 작업이 끝나면 다시 RUN으로 돌아갈 수 있지만 항상 DEBUG를 수행하는 것이 더 쉬울 수 있으므로 생각할 필요가 없습니다.
구성 파일 . 테스트 실행 구성을 편집하여 .config 파일을 테스트 실행 폴더로 이동합니다.
소스 세이프와 통합 . MSTest는 SourceSafe를 싫어하고 그 느낌은 상호 적이라는 것을 알아야합니다. MSTest는 테스트 파일을 소스 제어 아래에두고 솔루션에 추가하기를 원하기 때문에 테스트를 실행할 때마다 솔루션을 확인해야합니다. 따라서 SourceSafe는 동료 개발자를 죽이지 않도록 멀티 체크 아웃 모드로 실행되어야합니다.
보풀을 무시 MSTest를 사용하면 12 개의 다른 창과보기를 얻을 수 있습니다. 테스트 실행, 테스트보기, 테스트 목록 ... 모두 도움이되지 않습니다. 테스트 결과에 충실하면 훨씬 더 행복해질 것입니다.
'단위 테스트'를 고수합니다 . 새 테스트를 추가 할 때 정렬 된 테스트, 단위 테스트를 추가하거나 마법사를 통해 실행할 수 있습니다. 단순하고 단순한 단위 테스트를 고수하십시오.

다른 팁

MSTest를 사용할 수밖에 없다면 단축키에 대해 알아보세요.당신의 삶을 조금 더 쉽게 만들어 줄 것입니다.

현재 컨텍스트에서 테스트 : CTRL + R , T 솔루션의 모든 테스트 : CTRL + R , A

현재 컨텍스트의 디버그 테스트 : CTRL + R , CTRL + T 솔루션의 모든 테스트 디버그 : CTRL + R , CTRL + A

여기서 궁금합니다.내가 이해하지 못하는 것은 사람들이 MSTest와 함께 사용할 수있는 모든 오픈 소스 도구를 비교하기 시작하고 그것을 강타하기 시작한다는 것입니다.그것이 얼마나 다루기 힘든지, 얼마나 unintiuitve 등 IMHO인지에 대한 언급은 xUnit 프레임 워크와 근본적으로 다르기 때문입니다.병렬 실행에 최적화되어 있습니다.

정적 ClassInitialze 및 Cleanup을 사용하고 각 테스트에 대해 고유 한 TestContext를 갖는 퀴릭조차도 다음 세대 (적어도 MS 언어의 Windows 비즈니스 프로그래머에게는 병렬 프로그래밍 개념) 때문입니다.

수만 개의 단위 테스트가있는 프로젝트에서 작업하는 것이 불행했습니다.거의 대부분의 빌드 시간이 소요되었습니다!MSTest를 통해 우리는이를 매우 관리 가능한 타임 라인으로 줄였습니다.

제 동료 인 Mike Hadlow는 우리가 MSTest 여기 .

그는 그의 프로젝트에서 그것을 제거 할 수 있었지만, 저는 현재 더 많은 정치와 관련된 더 큰 프로젝트를 진행 중이므로 우리는 여전히 그것을 사용하고 있습니다.

결론은 MSTest를 구현 한 사람이 TDD를 이해하지 못한다는 것입니다.M $ basher처럼 들려서 미안합니다-정말 아니에요.하지만 매우 형편없는 도구를 참 아야한다는 사실에 짜증이납니다.

MSTest에서 심각한 문제를 본 적이 없습니다.구체적으로 무엇에 대해 이야기하고 있습니까?사실 우리는 NUnit에서 MSTest로 이동하고 있습니다.하지만 그 이유는 모르겠습니다.

mstest를 사용하는 구성 파일이 많기 때문에 일관성이 떨어집니다.
내가 mbunit을 선택한 또 다른 이유는 mbunit의 "롤백"기능입니다.이를 통해이 테스트에서 수행 된 모든 데이터베이스 작업을 롤백 할 수 있으므로 실제로 전체 회로 테스트를 수행 할 수 있으며 테스트 후 연못이 오염 될 염려가 없습니다.
또한 mstest에 RowTest 기능이 없습니다.

빌드 프로세스 내에서 mbunit을 종속성으로 실행하는 것이 좋습니다. 설치가 필요하지 않고 bin과 참조 할 수있을 정도로 쉽습니다.

MSTest는 "높은 마찰"이 있습니다. NAant 및 MbUnit을 사용한 빌드 스크립트 MStest 및 MSBuild와 비교됩니다.아니 비교.
MSTest는 느린 MbUnit입니다. 그리고 NUnit은 내 경험에 더 빠릅니다. (gallio가 여기에서 도움이 될 수 있음)
MStest는 내가 필요하지 않은 물건 유선 구성 파일 등
MSTest에는 다른 OS 테스트 프레임 워크의 기능 세트가 없습니다.xUnit 및 MbUnit 확인
사용하기가 너무 어려우며 더 나은 옵션이 많이 있습니다.

언급했듯이 oyu는 다른 컴퓨터에서 MSTest를 사용하려면 전체 IDE를 설치해야합니다.단위 테스트가 고급 비주얼 스튜디오에서만 작동하고 다른 방식으로 실행할 수 있는지 확인하기를 원하기 때문이라고 생각합니다. 따라서 MSTest는 매우 느립니다. 이는 각 테스트 사이에 각 테스트에 대한 전체 컨텍스트를 다시 작성하기 때문에 이전 테스트가 실패했거나 현재 테스트에 영향을주지 않지만 속도가 느려지기 때문입니다.그러나 MSTest 프로세스 내에서 모든 테스트를 실행하는 / noisolation 플래그를 사용할 수 있습니다. IDE에서 속도를 높이려면 : VS ide에서 도구-옵션으로 이동 한 다음 테스트 도구를 선택합니다.테스트 실행이라는 하위 항목을 선택하고 오른쪽의 다이얼로그에서 '테스트 실행 사이에 테스트 실행 엔진 실행 유지'확인란이 선택되어 있는지 확인합니다.

지명 적이 지 않은 질문에 대한 대답은 "아마도 NUnit은 당신의 얼굴에서 벗어나 있습니다."

면책 조항 : MS 버전의 xUnit에 대한 실제 경험은 없지만 '별도의 컴퓨터에서 테스트를 실행하려면 거대한 아이디어를 설치해야합니다'와 같은 문제가 발생합니다.완전한 No-No. 그 외에 MS는 전체 아이디어에 반하는 일종의 IDE 벨 / 휘파람을 통해 초보자에게 올바른 경로를 왜곡하는 방법을 가지고 있습니다.수업에서 테스트를 생성하는 것이 1 년 전쯤에 기억 나는 것과 같이 테스트 운전 의 전체 요점을 무너 뜨리는 것입니다. 디자인은 RGR의 작은 단계에서 나타나야합니다. 테스트 작성-패스 리팩터링하십시오.이 도구를 사용하면 전체 경험을 잃게됩니다.

이제 설교로 멈출 게요 .. 지금 :)

몇 년 동안 NUnit을 사용하여 TDD 개발을 해왔고 역할 변경으로 인해 약 4 개월 동안 MSTest를 사용하고 있습니다.

MSTest가 누군가가 TDD를하는 것을 막는다 고 생각하지 않습니다. 기본 어설 션 및 모의 프레임 워크 (저는 Rhino Mocks를 사용합니다)와 같이 TDD에 필요한 모든 핵심 요소를 여전히 가지고 있습니다.

MSTest는 Visual Studio와 긴밀하게 통합됩니다.이 통합의 가장 좋은 구성 요소는 기본 제공되는 코드 커버리지 도구입니다.

하지만 MSTest를 사용하지 않는 많은 이유가 있습니다. 제 생각에 가장 큰 두 가지 문제는 다음과 같습니다.

(NUnit에 비해) assert 옵션 부족
느린 테스트 실행기 (NUnit에 비해 느림) 이것은 어설 션을 작성하는 데 느린 테스트 실행기와 함께 더 많은 코드가 필요하다는 것은 전체 프로세스가 NUnit보다 느리다는 것을 의미합니다. 오픈 소스 옵션은 커뮤니티에서 더 많은 지원을 제공합니다.
CI에 TFS를 사용하는 경우 NUnit이 테스트 결과를 게시하도록하려면 몇 가지 문제를 해결해야합니다. MSTest를 사용하여 TFS에서 테스트를 실행하는 것은 매우 쉽고 간단합니다. 내가 NUnit으로가는 것보다 TFS를 건드리지 않으면 더 좋을 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow