좋은 단위 테스트는 무엇입니까? [닫은]


97

저는 여러분 대부분이 자동화 된 테스트를 많이 작성하고 있으며 단위 테스트시 일반적인 함정에 부딪혔다 고 확신합니다.

내 질문은 미래의 문제를 피하기 위해 테스트 작성에 대한 행동 규칙을 따르나요? 더 구체적으로 말하면 , 좋은 단위 테스트속성은 무엇입니까 ? 아니면 테스트를 어떻게 작성합니까?

언어에 구애받지 않는 제안이 권장됩니다.

답변:


93

소스를 연결하는 것으로 시작하겠습니다 -JUnit을 사용하는 Java의 Pragmatic Unit Testing (C # -Nunit도 포함 된 버전도 있지만이 버전도 있습니다. 대부분의 경우 불가지론 적입니다. 권장 됨)

Good Tests는 A TRIP 이어야합니다 (약어가 충분히 끈적 거리지 않습니다. 책에 치트 시트가 인쇄되어있어이 문제가 올바른지 확인해야했습니다 ..)

  • 자동 : 테스트 호출 및 PASS / FAIL 결과 확인이 자동으로 수행되어야합니다.
  • 철저한 : 범위; 버그는 코드의 특정 지역을 중심으로 클러스터되는 경향이 있지만 모든 주요 경로와 시나리오를 테스트해야합니다. 테스트되지 않은 지역을 알아야하는 경우 도구를 사용합니다.
  • 반복 : 시험은 동일한 결과 때마다 .. 모든 시간을 생산한다. 테스트는 제어 할 수없는 매개 변수에 의존해서는 안됩니다.
  • 독립 : 매우 중요합니다.
    • 테스트는 한 번에 한 가지만 테스트해야합니다 . 여러 주장은 모두 하나의 기능 / 동작을 테스트하는 한 괜찮습니다. 테스트가 실패하면 문제의 위치를 ​​정확히 찾아 내야합니다.
    • 테스트 는 서로 의존해서는 안됩니다 .-격리 됨. 테스트 실행 순서에 대한 가정이 없습니다. 설정 / 해체를 적절하게 사용하여 각 테스트 전에 '클린 슬레이트'를 확인하십시오.
  • 전문가가 : 장기적으로 당신은 그러므로 테스트 코드에 대한 좋은 디자인의 동일한 표준에 따라 생산 한 많은 테스트 코드 (안 많은 경우)로해야합니다. 의도를 드러내는 이름, 중복 없음, 좋은 이름의 테스트 등을 가진 잘 팩터링 된 메서드 클래스

  • 좋은 테스트도 빠르게 실행 됩니다. 실행하는 데 0.5 초 이상 걸리는 모든 테스트를 수행해야합니다. 테스트 스위트를 실행하는 데 시간이 오래 걸릴수록 실행 빈도가 줄어 듭니다. 더 많은 변경 사항이있을수록 개발자는 실행 사이에 몰래 들어 가려고합니다. 어떤 것이 깨지면 .. 어떤 변경이 원인인지 알아내는 데 시간이 더 오래 걸립니다.

2010-08 업데이트 :

  • 가독성 : 이것은 Professional의 일부로 간주 될 수 있지만 충분히 강조 할 수는 없습니다. 산성 테스트는 팀의 일원이 아닌 사람을 찾아서 몇 분 안에 테스트중인 행동을 파악하도록 요청하는 것입니다. 테스트는 프로덕션 코드처럼 유지되어야하므로 더 많은 노력이 필요하더라도 쉽게 읽을 수 있도록해야합니다. 테스트는 대칭이어야하며 (패턴을 따름) 간결해야합니다 (한 번에 하나의 동작을 테스트). 일관된 명명 규칙 (예 : TestDox 스타일)을 사용합니다. "부수적 인 세부 사항"으로 테스트를 복잡하게 만들지 마십시오. 미니멀리스트가 되십시오.

이 외에도 대부분의 다른 것들은 저수익 작업을 줄이는 지침입니다. 예 : '소유하지 않는 코드는 테스트하지 마십시오'(예 : 타사 DLL). 게터와 세터를 테스트하지 마십시오. 비용 대 이익 비율 또는 결함 가능성을 주시하십시오.


우리는 Mocks의 사용에 동의하지 않을 수 있지만 이것은 단위 테스트 모범 사례에 대한 아주 멋진 글이었습니다.
Justin Standard

"A TRIP"두문자어가 유용하다는 것을 알기 때문에이 질문을 대답으로 올릴 것입니다.
Spoike

3
대부분 동의하지만 소유하지 않은 코드를 테스트하면 이점이 있다는 점을 지적하고 싶습니다. 요구 사항을 충족하는지 테스트하고 있습니다. 업그레이드로 인해 시스템이 손상되지 않는다는 것을 어떻게 확신 할 수 있습니까? (물론 비용 대비 이익 비율을 염두에 두십시오.)
Disillusioned

@Craig-나는 당신이 의존하는 행동을 문서화하는 (인터페이스 수준) 회귀 테스트 (또는 경우에 따라 학습자 테스트)를 언급하고 있다고 생각합니다. 제 3 자 코드에 대한 '단위'테스트를 작성하지 않습니다. 공급 업체가 저보다 해당 코드에 대해 더 많이 알고 있습니다. b. 공급 업체는 특정 구현을 보존 할 의무가 없습니다. 나는 해당 코드베이스에 대한 변경을 제어하지 않으며 업그레이드로 손상된 테스트를 수정하는 데 시간을 소비하고 싶지 않습니다. 그래서 차라리 내가 사용하는 행동에 대해 몇 가지 높은 수준의 회귀 테스트를 코딩하고 싶습니다 (그리고 고장 났을 때 알림을 받고 싶습니다)
Gishu

@Gishu : 네, 물론입니다! 테스트는 인터페이스 수준에서만 수행해야합니다. 실제로 실제로 사용하는 기능은 최대한 테스트해야합니다. 또한,이 테스트를 작성할 대상을 선택할 때; 저는 간단하고 직관적 인 '단위'테스트 프레임 워크가 일반적으로 법안에 완벽하게 맞는다는 것을 발견했습니다.
환멸

42
  1. 엄청난 테스트를 작성하지 마십시오. '단위 테스트'의 '단위'에서 알 수 있듯이 각 단위 를 가능한 한 원자 적 으로 분리 하십시오. 필요한 경우 일반적인 사용자 환경을 너무 많이 수동으로 다시 만드는 대신 모의 개체를 사용하여 전제 조건을 만듭니다.
  2. 분명히 작동하는 것을 테스트하지 마십시오. 타사 공급 업체의 클래스, 특히 코딩 한 프레임 워크의 핵심 API를 제공하는 공급 업체의 클래스를 테스트하지 마십시오. 예를 들어 공급 업체의 Hashtable 클래스에 항목을 추가하는 것을 테스트하지 마십시오.
  3. NCover와 같은 코드 커버리지 도구를 사용하여 아직 테스트하지 않은 엣지 케이스를 찾는 것을 고려하십시오 .
  4. 구현 하기 전에 테스트 작성하십시오 . 테스트를 구현이 준수 할 사양으로 생각하십시오. Cf. 또한 행동 중심 개발, 테스트 중심 개발의보다 구체적인 분기입니다.
  5. 일관성을 유지하십시오. 일부 코드에 대한 테스트 만 작성한다면 거의 유용하지 않습니다. 팀에서 일하고 다른 일부 또는 모두가 테스트를 작성하지 않으면 그다지 유용하지 않습니다. 자신과 다른 모든 사람에게 테스트 의 중요성 (및 시간 절약 속성)을 설득 하거나 귀찮게하지 마십시오.

1
좋은 대답입니다. 그러나 배달의 모든 항목에 대해 단위 테스트를 수행하지 않으면 그렇게 나쁘지 않습니다. 물론 바람직하지만 균형과 실용주의가 필요합니다. Re : 동료를 참여 시키십시오. 때로는 가치를 입증하고 참조 포인트로 사용하기 만하면됩니다.
Martin Clarke

1
나는 동의한다. 그러나 장기적으로는 거기에있는 테스트에 의존 할 수 있어야합니다. 즉, 일반적인 함정이 잡힐 것이라고 가정 할 수 있어야합니다. 그렇지 않으면 이점이 크게 감소합니다.
Sören Kuklau

2
"일부 코드에 대한 테스트 만 작성하면 거의 유용하지 않습니다." 이것이 정말로 사실입니까? 20 % 코드 커버리지 (중요한 / 실패하기 쉬운 영역)를 가진 프로젝트가 있고 그들은 저를 크게 도왔고 프로젝트도 괜찮습니다.
박사. 악

1
나는 Slough에 동의합니다. 테스트가 몇 개만 있어도 잘 작성되고 충분히 격리되어 있다면 엄청난 도움이 될 것입니다.
Spoike

41

여기에있는 대부분의 답변은 실제로 테스트 자체 (어떻게)를 작성하는 것이 아니라 일반적으로 (언제, 어디서, 왜, 무엇을) 단위 테스트 모범 사례를 다루는 것 같습니다. 질문이 "어떻게"부분에 대해 매우 구체적으로 보였기 때문에, 나는 회사에서 실시한 "갈색 가방"프레젠테이션에서 가져온 이것을 게시 할 것이라고 생각했습니다.

Womp의 5 가지 작문 시험 법칙 :


1. 길고 설명적인 테스트 방법 이름을 사용합니다.

   - Map_DefaultConstructorShouldCreateEmptyGisMap()
   - ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers()
   - Dog_Object_Should_Eat_Homework_Object_When_Hungry()

2. Arrange / Act / Assert 스타일로 테스트를 작성합니다 .

  • 이 조직 전략은 한동안 존재했고 많은 것을 불렀지 만, 최근에 "AAA"두문자어의 도입은이를 전달하는 좋은 방법이었습니다. 모든 테스트를 AAA 스타일과 일치 시키면 읽기 및 유지 관리가 쉽습니다.

3. 항상 어설 션과 함께 실패 메시지를 제공하십시오.

Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element 
processing events was raised by the XElementSerializer");
  • 러너 애플리케이션에서 무엇이 실패했는지를 분명하게하는 간단하면서도 보람있는 연습입니다. 메시지를 제공하지 않으면 일반적으로 실패 출력에 "Expected true, was false"와 같은 메시지가 표시되므로 실제로 테스트를 읽어서 무엇이 잘못되었는지 확인해야합니다.

4. 테스트 이유를 설명하십시오 . 비즈니스 가정은 무엇입니까?

  /// A layer cannot be constructed with a null gisLayer, as every function 
  /// in the Layer class assumes that a valid gisLayer is present.
  [Test]
  public void ShouldNotAllowConstructionWithANullGisLayer()
  {
  }
  • 이것은 당연한 것처럼 보일 수 있지만이 방법은 처음에 테스트의 이유를 이해하지 못하는 사람들로부터 테스트의 무결성을 보호합니다. 나는 그 사람이 테스트가 검증하고 있다는 가정을 이해하지 못했기 때문에 완벽하게 괜찮은 많은 테스트가 제거되거나 수정되는 것을 보았습니다.
  • 테스트가 사소하거나 메서드 이름이 충분히 설명적인 경우 주석을 생략 할 수 있습니다.

5. 모든 테스트는 항상 접촉하는 리소스의 상태를 되돌려 야합니다.

  • 실제 자원을 다루지 않도록 가능한 경우 모의를 사용하십시오.
  • 테스트 수준에서 정리를 수행해야합니다. 테스트는 실행 순서에 의존하지 않아야합니다.

2
포인트 1, 2, 5 때문에 +1이 중요합니다. 설명 테스트 방법 이름을 이미 사용하고 있다면 3과 4는 단위 테스트에 다소 과도하게 보이지만 범위가 큰 경우 (기능 또는 승인 테스트) 테스트 문서화를 권장합니다.
Spoike

철저하게 실용적인 지식과 예는 한

17

이러한 목표를 염두에 두십시오 (Meszaros의 xUnit Test Patterns 책에서 수정 됨).

  • 테스트는 위험을 도입하는 것이 아니라 감소시켜야합니다.
  • 테스트는 실행하기 쉬워야합니다.
  • 테스트는 시스템이 주변에서 진화함에 따라 유지 관리가 쉬워야합니다.

더 쉽게 할 수있는 몇 가지 사항 :

  • 테스트는 한 가지 이유 때문에 실패해야합니다.
  • 테스트는 한 가지만 테스트해야합니다.
  • 테스트 종속성 최소화 (데이터베이스, 파일, UI 등에 대한 종속성 없음)

당신도 당신의 xUnit의 프레임 워크 intergration 테스트를 할 수 있다는 것을 잊지 마세요 하지만 intergration 테스트 및 단위 테스트를 별도로 보관


Gerard Meszaros의 "xUnit Test Patterns"라는 책에서 각색 한 것 같습니다. xunitpatterns.com
Spoike

네, 맞아요. 나는 포스트에서 그것을 정리할 것이다
Mendelt

훌륭한 포인트. 단위 테스트는 매우 유용 할 수 있지만 시스템을 변경하려는 시도에 막대한 세금을 부과하는 복잡하고 상호 의존적 인 단위 테스트를 갖는 함정에 빠지지 않는 것이 매우 중요합니다.
Wedge

9

테스트는 격리되어야합니다. 한 테스트가 다른 테스트에 의존해서는 안됩니다. 더욱이 테스트는 외부 시스템에 의존해서는 안됩니다. 즉, 테스트 당신의 코드가 아닌 코드 코드는 on.You이 통합 또는 기능 테스트의 일환으로 그 상호 작용을 테스트 할 수 있습니다 따라 달라집니다.


9

훌륭한 단위 테스트의 몇 가지 속성 :

  • 테스트가 실패하면 문제가 어디에 있는지 즉시 알 수 있어야합니다. 디버거를 사용하여 문제를 추적해야하는 경우 테스트가 충분히 세분화되지 않은 것입니다. 테스트 당 단 하나의 주장 만 있으면 도움이됩니다.

  • 리팩터링 할 때 테스트가 실패해서는 안됩니다.

  • 테스트는 너무 빨리 실행되어 주저하지 않아야합니다.

  • 모든 테스트는 항상 통과해야합니다. 비 결정적 결과가 없습니다.

  • 단위 테스트는 프로덕션 코드와 마찬가지로 잘 구성되어야합니다.

@Alotor : 라이브러리에 외부 API에서만 단위 테스트가 있어야한다고 제안하는 경우 동의하지 않습니다. 외부 호출자에게 노출하지 않는 클래스를 포함하여 각 클래스에 대한 단위 테스트를 원합니다. (그러나 프라이빗 메서드에 대한 테스트를 작성해야한다고 생각되면 리팩토링해야합니다. )


편집 : "테스트 당 하나의 주장"으로 인한 중복에 대한 의견이있었습니다. 특히 시나리오를 설정하기위한 코드가 있고 이에 대해 여러 개의 어설 션을 만들고 싶지만 테스트 당 하나의 어설 션 만있는 경우 여러 테스트에서 설정을 복제 할 수 있습니다.

나는 그 접근 방식을 취하지 않습니다. 대신 시나리오별로 테스트 픽스처를 사용 합니다. 다음은 대략적인 예입니다.

[TestFixture]
public class StackTests
{
    [TestFixture]
    public class EmptyTests
    {
        Stack<int> _stack;

        [TestSetup]
        public void TestSetup()
        {
            _stack = new Stack<int>();
        }

        [TestMethod]
        [ExpectedException (typeof(Exception))]
        public void PopFails()
        {
            _stack.Pop();
        }

        [TestMethod]
        public void IsEmpty()
        {
            Assert(_stack.IsEmpty());
        }
    }

    [TestFixture]
    public class PushedOneTests
    {
        Stack<int> _stack;

        [TestSetup]
        public void TestSetup()
        {
            _stack = new Stack<int>();
            _stack.Push(7);
        }

        // Tests for one item on the stack...
    }
}

테스트 당 단 하나의 주장에 동의하지 않습니다. 테스트에 더 많은 어설 션이있을수록 잘라내어 붙여 넣는 테스트 케이스가 줄어 듭니다. 나는 테스트 케이스가 시나리오 나 코드 경로에 초점을 맞추어야한다고 믿으며, 주장은 해당 시나리오를 충족하기위한 모든 가정과 요구 사항에서 비롯되어야합니다.
Lucas B

DRY가 단위 테스트에 적용된다는 데 동의한다고 생각합니다. 내가 말했듯이 "단위 테스트는 잘 구성되어야한다". 그러나 중복을 해결하는 방법에는 여러 가지가 있습니다. 하나는 언급했듯이 먼저 테스트중인 코드를 호출 한 다음 여러 번 어설 션하는 단위 테스트를 갖는 것입니다. 대안은 시나리오에 대한 새로운 "테스트 픽스처"를 만드는 것입니다.이 시나리오는 초기화 / 설정 단계에서 테스트중인 코드를 호출 한 다음 단순히 주장하는 일련의 단위 테스트를 포함합니다.
Jay Bazuzi

내 경험 법칙은 복사-붙여 넣기를 사용하는 경우 뭔가 잘못하고 있다는 것입니다. 제가 가장 좋아하는 말 중 하나는 "복사-붙여 넣기는 디자인 패턴이 아닙니다."입니다. 나는 또한 단위 테스트 당 하나의 주장이 일반적으로 좋은 생각이라는 데 동의하지만 항상 그것을 주장하지는 않습니다. 나는보다 일반적인 "단위 테스트 당 한 가지 테스트"를 좋아합니다. 일반적으로 단위 테스트 당 하나의 어설 션으로 변환됩니다.
Jon Turner

7

당신이 추구하는 것은 테스트중인 클래스의 행동을 묘사하는 것입니다.

  1. 예상되는 동작의 확인.
  2. 오류 사례 확인.
  3. 클래스 내의 모든 코드 경로를 포함합니다.
  4. 클래스 내의 모든 멤버 함수를 실행합니다.

기본적인 의도는 수업의 행동에 대한 자신감을 높이는 것입니다.

이는 코드를 리팩토링 할 때 특히 유용합니다. Martin Fowler는 그의 웹 사이트에서 테스트에 관한 흥미로운 기사 를 가지고 있습니다.

HTH.

건배,

Rob


Rob-기계적 이것은 좋지만 의도를 놓칩니다. 왜 이걸 다 했어? 이런 식으로 생각하면 다른 사람들이 TDD의 길을가는 데 도움이 될 수 있습니다.
Mark Levison

7

테스트는 원래 실패해야합니다. 그런 다음 통과하는 코드를 작성해야합니다. 그렇지 않으면 버그가 발생하고 항상 통과하는 테스트를 작성할 위험이 있습니다.


@Rismo 그 자체로 배타적이지 않습니다. Quarrelsome이 여기에 쓴 내용은 TDD의 일부인 "Test First"방법론에만 적용됩니다. TDD는 리팩토링도 고려합니다. 내가 읽은 가장 "똑똑한 바지"정의는 TDD = Test First + Refactor입니다.
Spoike

예, TDD 일 필요는 없습니다. 먼저 테스트가 실패했는지 확인하십시오. 그런 다음 나머지를 연결하십시오. 이것은 TDD를 할 때 가장 일반적으로 발생하지만 TDD를 사용하지 않을 때도 적용 할 수 있습니다.
Quibblesome

6

앞서 언급 한 Pragmatic Unit Testing 책 의 Right BICEP 약어를 좋아합니다 .

  • Right : 결과가 습니까?
  • B : 모두가 있습니까 B oundary 조건이 수정?
  • 나는 우리가 확인할 수 있습니다 내가 관계를 nverse?
  • C는 : 우리가 할 수 c는 로스 검사 결과는 다른 방법을 사용하고 계십니까?
  • E : 우리가 강제로 전자 일어날 rror 조건을?
  • P : 있습니까 P의 범위 내에서 erformance 특성은?

개인적으로 나는 당신이 올바른 결과를 얻었는지 확인하고 (1 + 1은 덧셈 함수에서 2를 반환해야 함), 당신이 생각할 수있는 모든 경계 조건을 시도함으로써 꽤 멀리 갈 수 있다고 생각합니다. 더하기 함수의 정수 최대 값보다 큽니다) 네트워크 장애와 같은 오류 조건을 강제합니다.


6

좋은 테스트는 유지 관리가 가능해야합니다.

복잡한 환경에서이 작업을 수행하는 방법을 알지 못했습니다.

코드베이스가 수백 천 또는 수백만 줄의 코드에 도달하기 시작하면 모든 교과서가 풀리기 시작합니다.

  • 폭발하는 팀 상호 작용
  • 폭발적인 테스트 케이스 수
  • 구성 요소 간의 상호 작용이 폭발합니다.
  • 모든 unittest를 빌드하는 시간이 빌드 시간의 중요한 부분이됩니다.
  • API 변경은 수백 개의 테스트 케이스에 파급 될 수 있습니다. 프로덕션 코드 변경은 쉬웠지만.
  • 프로세스를 올바른 상태로 시퀀스하는 데 필요한 이벤트 수가 증가하여 테스트 실행 시간이 증가합니다.

좋은 아키텍처는 상호 작용 폭발의 일부를 제어 할 수 있지만 시스템이 더욱 복잡 해짐에 따라 자동화 된 테스트 시스템도 함께 성장합니다.

여기서 트레이드 오프를 처리해야합니다.

  • 외부 API 만 테스트하십시오. 그렇지 않으면 내부를 리팩토링하면 상당한 테스트 케이스가 재 작업됩니다.
  • 캡슐화 된 하위 시스템이 더 많은 상태를 유지하므로 각 테스트의 설정 및 해체가 더 복잡해집니다.
  • 야간 컴파일 및 자동화 된 테스트 실행이 몇 시간으로 늘어납니다.
  • 증가 된 컴파일 및 실행 시간은 디자이너가 모든 테스트를 실행하지 않거나 실행하지 않음을 의미합니다.
  • 테스트 실행 시간을 줄이려면 설정 및 해체를 줄이기 위해 테스트 시퀀싱을 고려합니다.

다음 사항도 결정해야합니다.

코드베이스에서 테스트 케이스를 어디에 저장합니까?

  • 테스트 케이스를 어떻게 문서화합니까?
  • 테스트 케이스 유지 보수를 절약하기 위해 테스트 픽스처를 재사용 할 수 있습니까?
  • 야간 테스트 케이스 실행이 실패하면 어떻게됩니까? 누가 분류합니까?
  • 모의 객체를 어떻게 유지합니까? 모의 로깅 API의 고유 한 특징을 모두 사용하는 20 개의 모듈이있는 경우 API 변경은 빠르게 파급됩니다. 테스트 케이스가 변경 될뿐만 아니라 20 개의 모의 객체가 변경됩니다. 이 20 개의 모듈은 여러 팀에서 수년에 걸쳐 작성되었습니다. 고전적인 재사용 문제입니다.
  • 개인과 팀은 자동화 된 테스트의 가치를 이해하며 다른 팀이 수행하는 방식을 좋아하지 않습니다. :-)

나는 영원히 계속할 수 있지만 내 요점은 다음과 같습니다.

테스트는 유지 보수가 가능해야합니다.


5

저는 이 MSDN Magazine 기사 에서 이러한 원칙을 다루었습니다.이 기사 는 모든 개발자에게 중요하다고 생각합니다.

"좋은"단위 테스트를 정의하는 방법은 다음과 같은 세 가지 속성을 가지고 있는지 여부입니다.

  • 읽을 수 있습니다 (이름 지정, 어설 션, 변수, 길이, 복잡성 ..)
  • 그들은 유지 가능합니다 (논리 없음, 과도하게 지정되지 않음, 상태 기반, 리팩토링 됨 ..)
  • 신뢰할 수 있습니다 (통합 테스트가 아닌 격리 된 상태에서 올바른 것을 테스트합니다 ..)

로이, 전적으로 동의합니다. 이러한 것들은 엣지 케이스 커버리지보다 훨씬 더 중요합니다.
Matt Hinze

신뢰할 수있는-훌륭한 포인트!
ratkok 2011-06-26

4
  • 단위 테스트는 단위의 외부 API 만 테스트하므로 내부 동작을 테스트하면 안됩니다.
  • TestCase의 각 테스트는이 API 내에서 하나의 메서드 만 테스트해야합니다.
    • 실패 사례에 대한 추가 테스트 사례가 포함되어야합니다.
  • 테스트 범위 테스트 : 유닛이 테스트되면이 유닛 내부의 라인이 100 % 실행되어야합니다.

2

Jay Fields는 단위 테스트 작성에 대한 좋은 조언을 많이 가지고 있으며 그가 가장 중요한 조언을 요약 한 게시물이 있습니다. 거기에서 당신은 당신의 맥락에 대해 비판적으로 생각하고 조언이 당신에게 가치가 있는지 판단해야한다는 것을 읽을 것입니다. 여기에서 놀라운 답변을 얻을 수 있지만 상황에 가장 적합한 것은 사용자가 결정해야합니다. 시도해보고 나쁜 냄새가 나면 리팩토링하십시오.

감사합니다


1

사소한 2 줄 방법이 작동 할 것이라고 가정하지 마십시오. 빠른 단위 테스트를 작성하는 것은 누락 된 null 테스트, 잘못 배치 된 마이너스 기호 및 / 또는 미묘한 범위 지정 오류가 지금보다 처리 할 시간이 더 적을 때 불가피하게 사용자를 물리 치는 것을 방지하는 유일한 방법입니다.


1

나는 두 번째로 "A TRIP"대답을했는데, 테스트는 서로 의존해야 한다는 점을 제외하면 !!!

왜?

DRY-반복하지 마십시오-테스트에도 적용됩니다! 테스트 종속성은 1) 설정 시간을 절약하고, 2) 픽스처 리소스를 절약하고, 3) 오류를 정확히 파악하는 데 도움이 될 수 있습니다. 물론 테스트 프레임 워크가 최고 수준의 종속성을 지원하는 경우에만 가능합니다. 그렇지 않으면 나쁘다는 것을 인정합니다.

후속 조치 http://www.iam.unibe.ch/~scg/Research/JExample/


나는 당신과 동의합니다. TestNG는 종속성이 쉽게 허용되는 또 다른 프레임 워크입니다.
Davide

0

종종 단위 테스트는 모의 객체 또는 모의 데이터를 기반으로합니다. 세 종류의 단위 테스트를 작성하고 싶습니다.

  • "일시적인"단위 테스트 : 그들은 자신의 모의 객체 / 데이터를 만들고 그것으로 기능을 테스트하지만 모든 것을 파괴하고 흔적을 남기지 않습니다 (테스트 데이터베이스에 데이터가없는 것처럼)
  • "영구"단위 테스트 : 나중에 자체 단위 테스트를 위해 고급 기능에 필요한 객체 / 데이터를 생성하는 코드 내에서 기능을 테스트합니다 (고급 기능이 자신의 모의 객체 / 데이터 세트를 매번 재생성하는 것을 피함).
  • "영구 기반"단위 테스트 : 영구 단위 테스트에 의해 이미 존재하는 (다른 단위 테스트 세션에서 생성 되었기 때문에) 모의 객체 / 데이터를 사용하는 단위 테스트입니다.

요점은 모든 기능을 테스트 할 수 있도록 모든 것을 재생하지 않는 입니다.

  • 모든 모의 객체 / 데이터가 이미 있기 때문에 세 번째 종류를 자주 실행합니다.
  • 모델이 변경 될 때마다 두 번째 종류를 실행합니다.
  • 나는 기본 회귀를 확인하기 위해 때때로 매우 기본적인 기능을 확인하기 위해 첫 번째를 실행합니다.

0

기능 테스트와 성능 테스트라는 두 가지 유형의 테스트에 대해 생각하고 다르게 처리합니다.

각각에 대해 다른 입력 및 메트릭을 사용하십시오. 각 테스트 유형에 대해 다른 소프트웨어를 사용해야 할 수도 있습니다.


그렇다면 단위 테스트는 어떻습니까?
Spoike

0

저는 Roy Osherove의 단위 테스트 명명 표준에 설명 된 일관된 테스트 명명 규칙을 사용합니다 . 주어진 테스트 케이스 클래스의 각 메서드에는 다음과 같은 명명 스타일 MethodUnderTest_Scenario_ExpectedResult가 있습니다.

    첫 번째 테스트 이름 섹션은 테스트중인 시스템의 메서드 이름입니다.
    다음은 테스트중인 특정 시나리오입니다.
    마지막으로 그 시나리오의 결과입니다.

각 섹션은 Upper Camel Case를 사용하며 언더 스코어로 구분됩니다.

테스트를 실행할 때 이것이 유용하다는 것을 알았습니다. 테스트는 테스트중인 메소드의 이름으로 그룹화됩니다. 그리고 규칙을 통해 다른 개발자가 테스트 의도를 이해할 수 있습니다.

또한 테스트중인 메서드가 오버로드 된 경우 메서드 이름에 매개 변수를 추가합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.