[unit-testing] 단위 테스트 안티 패턴 카탈로그

안티 패턴 : 실제 안티 패턴을 간단한 나쁜 습관, 나쁜 습관 또는 나쁜 생각과 공식적으로 구별하기 위해서는 적어도 두 가지 핵심 요소가 있어야합니다.

  • 처음에는 유익한 것처럼 보이지만 궁극적으로는 유익한 결과보다 더 나쁜 결과를 초래하는 일부 반복 된 행동 패턴, 과정 또는 구조
  • 명확하게 문서화되고 실제 실무에서 입증되고 반복 가능한 리팩토링 솔루션.

“와일드에서”한 번 너무 많이 본 TDD 반 패턴에 투표하십시오.
James Carr의 블로그 게시물testdrivendevelopment yahoogroup 관련 토론

당신이 ‘이름이없는’것을 찾았다면 .. 안티 패턴 당 하나의 게시물로 투표를 통해 무언가를 계산하십시오.

나의 가장 큰 관심은 가까운 장래에 도시락 회의에서 그들을 토론 할 수 있도록 상위 N 개 부분 집합을 찾는 것입니다.



답변

2 급 시민 – 테스트 코드는 프로덕션 코드만큼 리팩터링되지 않아 중복 코드가 많이 포함되어있어 테스트를 유지하기가 어렵습니다.


답변

무료 승차 / 피기 백 -제임스 카 (James Carr), 팀 오 팅거 (Tim Ottinger) 다른 / 특별한 특징 / 기능
을 테스트하기위한 새로운 테스트 케이스 방법을 작성하는 대신 , 새로운 주장 (및 해당 조치, 즉 AAA의 Act step)이 기존 테스트 케이스를 따라 진행됩니다. .


답변

행복한 길

테스트는 경계와 예외를 테스트하지 않고 올바른 경로 (예상 결과)를 유지합니다.

JUnit 반 패턴


답변

지역의 영웅

실행하기 위해 작성된 개발 환경에 특정한 것에 의존하는 테스트 케이스. 결과는 개발 상자에서 테스트를 통과했지만 다른 곳에서 실행하려고하면 실패합니다.

숨겨진 의존성

로컬 히어로와 밀접한 관련이 있으며, 테스트를 실행하기 전에 일부 기존 데이터를 채워야하는 단위 테스트입니다. 해당 데이터가 채워지지 않은 경우 테스트가 실패하고 개발자에게 원하는 것이 무엇인지 또는 왜… 어떻게 사용했는지에 대한 정보를 찾기 위해 몇 에이커의 코드를 파고 들게 할 수 있습니다.


안타깝게도 특정 프로덕션 시스템에서 지속적으로 동기화되지 않는 다양한 .ini 파일에 의존하는 고대 .dll을 사용하여 너무 많은 시간을 슬프게 보았습니다.이 dll을 담당하는 세 명의 개발자와의 광범위한 협의없이 컴퓨터에서 현존하는 것은 아닙니다. 한숨.


답변

체인 갱

특정 순서로 실행해야하는 몇 가지 테스트, 즉 한 테스트는 시스템의 글로벌 상태 (전역 변수, 데이터베이스의 데이터)를 변경하고 다음 테스트는 이에 따라 달라집니다.

당신은 종종 데이터베이스 테스트에서 이것을 볼 수 있습니다. teardown()테스트 는에서 롤백하는 대신 데이터베이스에 변경 사항을 커밋합니다. 또 다른 일반적인 원인은 전역 상태에 대한 변경 사항이 테스트에 실패한 경우 정리할 수있는 try / finally 블록에 포함되지 않기 때문입니다.


답변

조롱
때로는 조롱이 좋고 편리 할 수 ​​있습니다. 그러나 때때로 개발자는 테스트를 거치지 않은 것을 조롱하려는 노력으로 자신을 잃을 수 있습니다. 이 경우, 단위 테스트에는 테스트 대상 시스템이 전혀 테스트되지 않은 모의, 스터브 및 / 또는 가짜가 너무 많이 포함되어 있으며 모의에서 반환 된 데이터가 테스트 대상입니다.

출처 : James Carr의 게시물.


답변

사일런트 캐처 -켈리?
실제로 예외가 발생하더라도 개발자가 의도 한 것과 다른 경우에도 예외가 발생하면 통과하는 테스트입니다.
또한보십시오 : 비밀 캐처

[Test]
[ExpectedException(typeof(Exception))]
public void ItShouldThrowDivideByZeroException()
{
   // some code that throws another exception yet passes the test
}