단일 단위 테스트에서 여러 개의 어설 션을 갖는 것이 괜찮습니까?

이 위대한 게시물에 대한 의견 에서 Roy Osherove 는 각 테스트를 단일 테스트로 실행하도록 설계된 OAPT 프로젝트를 언급했습니다 .

다음은 프로젝트 홈페이지에 작성되었습니다.

적절한 단위 테스트는 정확히 한 가지 이유로 실패 해야하므로 단위 테스트 당 하나의 어설 션을 사용해야합니다.

또한 Roy는 다음과 같이 논평했습니다.

내 지침은 일반적으로 테스트 당 하나의 논리적 개념을 테스트하는 것입니다. 동일한 객체 에 대해 여러 개의 어설 션을 가질 수 있습니다 . 그것들은 보통 테스트되는 것과 같은 개념 일 것입니다.

나는 여러 가지 주장이 필요한 경우가 있다고 생각 하지만 (예 : Guard Assertion ) 일반적으로 이것을 피하려고합니다. 당신의 의견 것입니다? 여러 개의 어설 션이 실제로 필요한 실제 예제를 제공하십시오 .

필자는 이것이 반드시 나쁜 것이라고 생각하지는 않지만 테스트에서 단 한 번의 주장 만하도록 노력해야 한다고 생각 합니다. 즉, 더 많은 테스트를 작성하면 테스트에서 한 번에 한 가지만 테스트하게됩니다.

내가 말했듯이, 내 테스트의 절반은 실제로 단 하나의 주장 만 가지고 있다고 말할 것입니다. 나는 그것이 단지하게 생각 (? 시험) 코드 냄새 는 약 5 개 이상이 테스트에서 주장이있을 때.

여러 개의 어설 션을 어떻게 해결합니까?

테스트가 한 가지 이유로 만 실패해야한다고해서 항상 하나의 Assert명령문 만 있어야한다는 것은 아닙니다 . IMHO " 배열, 행위, 주장 "패턴 을 유지하는 것이 더 중요합니다 .

핵심은 작업이 하나 뿐인 다음 어설 션을 사용하여 해당 작업의 결과를 검사하는 것입니다. 그러나 "배열, 행위, 주장, 시험 종료 "입니다. 다른 조치를 수행하여 테스트를 계속하려는 경향이 있고 나중에 더 많은 주장을한다면 대신 별도의 테스트를 수행하십시오.

동일한 동작을 테스트하는 부분을 구성하는 여러 가지 주장을 보게되어 기쁩니다. 예 :

[Test]
public void ValueIsInRange()
{
  int value = GetValueToTest();

  Assert.That(value, Is.GreaterThan(10), "value is too small");
  Assert.That(value, Is.LessThan(100), "value is too large");
} 

또는

[Test]
public void ListContainsOneValue()
{
  var list = GetListOf(1);

  Assert.That(list, Is.Not.Null, "List is null");
  Assert.That(list.Count, Is.EqualTo(1), "Should have one item in list");
  Assert.That(list[0], Is.Not.Null, "Item is null");
} 

당신은 수 일 어설으로 이러한 결합,하지만 당신이 주장과는 다른 일이 해야 또는 필수 . 그것들을 결합하여 개선이 없습니다.

예를 들어 첫 번째 수 있을

Assert.IsTrue((10 < value) && (value < 100), "Value out of range"); 

그러나 이것은 더 좋지 않습니다. 오류 메시지는 덜 구체적이며 다른 장점은 없습니다. 두 개 또는 세 개 이상의 어설 션을 하나의 큰 부울 조건으로 결합하면 읽기가 어려워지고 변경하기가 어려워지고 실패한 이유를 해결하기가 더 어려워지는 다른 예제를 생각할 수 있습니다. 왜 규칙을 위해서만 하는가?

NB : 여기서 작성하는 코드는 NUnit의 C #이지만 원칙은 다른 언어 및 프레임 워크와 함께 유지됩니다. 구문도 매우 유사 할 수 있습니다.

나는 하나 이상의 주장이 나쁜 것이라고 생각한 적이 없다.

나는 항상 그것을한다 :

public void ToPredicateTest()
{
    ResultField rf = new ResultField(ResultFieldType.Measurement, "name", 100);
    Predicate<ResultField> p = (new ConditionBuilder()).LessThanConst(400)
                                                       .Or()
                                                       .OpenParenthesis()
                                                       .GreaterThanConst(500)
                                                       .And()
                                                       .LessThanConst(1000)
                                                       .And().Not()
                                                       .EqualsConst(666)
                                                       .CloseParenthesis()
                                                       .ToPredicate();
    Assert.IsTrue(p(ResultField.FillResult(rf, 399)));
    Assert.IsTrue(p(ResultField.FillResult(rf, 567)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 400)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 666)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 1001)));

    Predicate<ResultField> p2 = (new ConditionBuilder()).EqualsConst(true).ToPredicate();

    Assert.IsTrue(p2(new ResultField(ResultFieldType.Confirmation, "Is True", true)));
    Assert.IsFalse(p2(new ResultField(ResultFieldType.Confirmation, "Is False", false)));
}

여기서는 여러 조건을 사용하여 복잡한 조건을 예상 조건 자로 바꿀 수 있습니다.

나는 한 단위 ( ToPredicate방법) 만 테스트 하고 있지만 테스트에서 생각할 수있는 모든 것을 다루고 있습니다.

높은 수준의 동작을 확인하기 위해 단위 테스트를 사용하는 경우 단일 테스트에 여러 어설 션을 절대적으로 넣습니다. 비상 알림 코드에 실제로 사용하는 테스트가 있습니다. 테스트 전에 실행되는 코드는 시스템을 메인 프로세서가 실행되면 알람이 전송되는 상태로 만듭니다.

@Test
public void testAlarmSent() {
    assertAllUnitsAvailable();
    assertNewAlarmMessages(0);

    pulseMainProcessor();

    assertAllUnitsAlerting();
    assertAllNotificationsSent();
    assertAllNotificationsUnclosed();
    assertNewAlarmMessages(1);
}

그것은 코드가 내가 기대하는 방식으로 작동하고 있음을 확신하기 위해 프로세스의 모든 단계에서 존재 해야하는 조건을 나타냅니다. 단일 어설 션이 실패하면 나머지 어설 션도 실행되지 않을 것입니다. 시스템의 상태가 더 이상 유효하기 때문에, 그 이후의 주장은. 나에게 소중한 아무것도 말하지 않을 경우 * assertAllUnitsAlerting()실패, 그때의 만들기 위해 무엇을할지 모르겠다 assertAllNotificationSent()'의 성공 또는 실패 나는 이전에 오류를 일으키는 것을 결정까지를 그것을 수정했습니다.

(*-문제를 디버깅하는 데 유용 할 수 있지만 테스트에 실패한 가장 중요한 정보는 이미 수신되었습니다.)

내가 생각하는 또 다른 이유는 한 가지 방법으로 여러 가지 주장이 나쁜 것이 아니라는 것입니다. 다음 코드에서 설명합니다.

class Service {
    Result process();
}

class Result {
    Inner inner;
}

class Inner {
    int number;
}

내 테스트에서 단순히 클래스 인스턴스 service.process()에서 올바른 숫자 를 반환 하는지 테스트하고 싶습니다 Inner.

테스트 대신 ...

@Test
public void test() {
    Result res = service.process();
    if ( res != null && res.getInner() != null ) Assert.assertEquals( ..., res.getInner() );
}

나는 일을 해요

@Test
public void test() {
    Result res = service.process();
    Assert.notNull(res);
    Assert.notNull(res.getInner());
    Assert.assertEquals( ..., res.getInner() );
}

한 가지 이유로 테스트가 실패해야한다는 규칙 내에서 여러 개의 어설 션을 쓰는 것이 유효한 경우가 많이 있다고 생각합니다.

예를 들어, 날짜 문자열을 구문 분석하는 함수를 상상해보십시오.

function testParseValidDateYMD() {
    var date = Date.parse("2016-01-02");

    Assert.That(date.Year).Equals(2016);
    Assert.That(date.Month).Equals(1);
    Assert.That(date.Day).Equals(0);
}

테스트가 실패하면 한 가지 이유 때문이므로 구문 분석이 올바르지 않습니다. 이 테스트가 세 가지 이유로 실패 할 수 있다고 주장 할 경우 IMHO는 "한 가지 이유"에 대한 정의에서 너무 세분화 될 수 있습니다.

[Test] 메서드 자체 내에 여러 개의 어설 션이있는 것이 좋은 상황에 대해서는 모르겠습니다. 사람들이 여러 가지 어설 션을 사용하는 주된 이유는 테스트중인 각 클래스에 대해 하나의 [TestFixture] 클래스를 사용하려고하기 때문입니다. 대신 테스트를 더 많은 [TestFixture] 클래스로 나눌 수 있습니다. 이를 통해 첫 번째 어설 션이 실패한 방식 대신 예상 한 방식으로 코드가 반응하지 않은 여러 가지 방법을 볼 수 있습니다. 이를 달성하는 방법은 많은 [TestFixture] 클래스를 테스트하여 클래스 당 하나 이상의 디렉토리를 테스트하는 것입니다. 각 [TestFixture] 클래스는 테스트 할 개체의 특정 상태에 따라 이름이 지정됩니다. [SetUp] 메서드는 객체를 클래스 이름으로 설명 된 상태로 만듭니다. 그런 다음 객체의 현재 상태를 고려할 때 각각 서로 다른 사실을 주장하는 여러 개의 [Test] 메서드가 있습니다. 각 [Test] 메소드는 코드를 영어로 읽는 대신 개념의 이름을 따서 명명 한 경우를 제외하고는 주장하는 이름을 따서 명명됩니다. 그런 다음 각 [Test] 메소드 구현에는 무언가를 주장하는 단일 코드 행만 필요합니다. 이 접근 방식의 또 다른 장점은 테스트 대상과 클래스 및 메서드 이름을보고 예상 한 내용이 명확 해짐에 따라 테스트를 읽기 쉽게 만드는 것입니다. 테스트하려는 모든 작은 경우를 실현하기 시작하고 버그를 발견하면 확장 성이 향상됩니다. 아마도 코드를 영어로 읽는 대신 개념의 이름을 따서 명명했을 수도 있습니다. 그런 다음 각 [Test] 메소드 구현에는 무언가를 주장하는 단일 코드 행만 필요합니다. 이 접근 방식의 또 다른 장점은 테스트 대상과 클래스 및 메서드 이름을보고 예상 한 내용이 명확 해짐에 따라 테스트를 읽기 쉽게 만드는 것입니다. 테스트하려는 모든 작은 경우를 실현하기 시작하고 버그를 발견하면 확장 성이 향상됩니다. 아마도 코드를 영어로 읽는 대신 개념의 이름을 따서 명명했을 수도 있습니다. 그런 다음 각 [Test] 메소드 구현에는 무언가를 주장하는 단일 코드 행만 필요합니다. 이 접근 방식의 또 다른 장점은 테스트 대상과 클래스 및 메서드 이름을보고 예상 한 내용이 명확 해짐에 따라 테스트를 읽기 쉽게 만드는 것입니다. 테스트하려는 모든 작은 경우를 실현하기 시작하고 버그를 발견하면 확장 성이 향상됩니다. 클래스와 메소드 이름을보고 기대하는 것. 테스트하려는 모든 작은 경우를 실현하기 시작하고 버그를 발견하면 확장 성이 향상됩니다. 클래스와 메소드 이름을보고 기대하는 것. 테스트하려는 모든 작은 경우를 실현하기 시작하고 버그를 발견하면 확장 성이 향상됩니다.

일반적으로 이는 [SetUp] 메서드 내의 마지막 코드 줄이 [TestFixture]의 전용 인스턴스 변수에 속성 ​​값 또는 반환 값을 저장해야 함을 의미합니다. 그런 다음 다른 [Test] 메소드에서이 인스턴스 변수에 대해 여러 가지 다른 것을 주장 할 수 있습니다. 또한 테스트중인 오브젝트의 다른 특성이 원하는 상태로 설정되어 있는지에 대한 어설 션을 작성할 수도 있습니다.

때로는 객체를 원하는 상태로 만들기 전에 엉망이되지 않도록 테스트중인 객체를 원하는 상태로 가져 오는 동안 어설 션을 작성해야합니다. 이 경우 해당 추가 어설 션이 [SetUp] 메서드 안에 나타납니다. [SetUp] 방법으로 문제가 발생하면 테스트하려는 대상 상태에 도달하기 전에 테스트에 문제가있는 것이 분명합니다.

발생할 수있는 또 다른 문제는 발생했을 것으로 예상되는 예외를 테스트하고 있다는 것입니다. 위의 모델을 따르지 않도록 유혹 할 수 있습니다. 그러나 [SetUp] 메서드 내에서 예외를 잡아서 인스턴스 변수에 저장하면 여전히 달성 할 수 있습니다. 이를 통해 예외에 대해 각각 고유 한 [Test] 방법으로 여러 가지를 주장 할 수 있습니다. 그런 다음 테스트중인 오브젝트에 대해 다른 사항을 주장하여 예외가 발생하여 의도하지 않은 부작용이 없는지 확인할 수 있습니다.

예 (여러 파일로 나 into) :

namespace Tests.AcctTests
{
    [TestFixture]
    public class no_events
    {
        private Acct _acct;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
        }

        [Test]
        public void balance_0() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }

    [TestFixture]
    public class try_withdraw_0
    {
        private Acct _acct;
        private List<string> _problems;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
            Assert.That(_acct.Balance, Is.EqualTo(0));
            _problems = _acct.Withdraw(0m);
        }

        [Test]
        public void has_problem() {
            Assert.That(_problems, Is.EquivalentTo(new string[] { "Withdraw amount must be greater than zero." }));
        }

        [Test]
        public void balance_not_changed() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }

    [TestFixture]
    public class try_withdraw_negative
    {
        private Acct _acct;
        private List<string> _problems;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
            Assert.That(_acct.Balance, Is.EqualTo(0));
            _problems = _acct.Withdraw(-0.01m);
        }

        [Test]
        public void has_problem() {
            Assert.That(_problems, Is.EquivalentTo(new string[] { "Withdraw amount must be greater than zero." }));
        }

        [Test]
        public void balance_not_changed() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }
}

동일한 테스트에서 여러 어설 션이있는 것은 테스트가 실패한 경우에만 문제가됩니다. 그런 다음 테스트를 디버그하거나 예외를 분석하여 실패한 어설 션을 찾아야 할 수 있습니다. 각 테스트마다 한 번의 주장으로 일반적으로 무엇이 잘못되었는지 파악하는 것이 더 쉽습니다.

동일한 어설 션에서 항상 여러 조건으로 다시 작성할 수 있으므로 여러 어설 션이 실제로 필요한 시나리오는 생각할 수 없습니다 . 그러나 예를 들어 입력이 잘못되어 이후 단계가 중단 될 위험이있는 대신 단계 사이의 중간 데이터를 확인하는 여러 단계가있는 것이 바람직 할 수 있습니다.

테스트에 실패하면 다음 어설 션도 중단되는지 알 수 없습니다. 종종 문제의 원인을 파악하기 위해 귀중한 정보가 누락 될 수 있습니다. 내 해결책은 하나의 assert를 사용하지만 여러 값을 사용하는 것입니다.

String actual = "val1="+val1+"\nval2="+val2;
assertEquals(
    "val1=5\n" +
    "val2=hello"
    , actual
);

그러면 한 번에 모든 실패한 어설 션을 볼 수 있습니다. 대부분의 IDE가 비교 대화 상자에서 문자열 차이를 나란히 표시하기 때문에 여러 줄을 사용합니다.

단일 테스트 기능에 여러 개의 어설 션이있는 경우 수행중인 테스트와 직접 관련이있을 것으로 예상됩니다. 예를 들어

@Test
test_Is_Date_segments_correct {

   // It is okay if you have multiple asserts checking dd, mm, yyyy, hh, mm, ss, etc. 
   // But you would not have any assert statement checking if it is string or number,
   // that is a different test and may be with multiple or single assert statement.
}

많은 테스트를하는 것 (아마도 과잉이라고 생각 될 때도)은 나쁘지 않습니다. 가장 중요하고 필수적인 테스트를받는 것이 더 중요하다고 주장 할 수 있습니다. 따라서 어설 션 할 때 여러 어설 션에 대해 너무 걱정하지 말고 어설 션을 올바르게 배치하십시오. 둘 이상이 필요한 경우 둘 이상을 사용하십시오.

단위 테스트의 목표는 실패한 부분에 대해 가능한 많은 정보를 제공하는 동시에 가장 근본적인 문제를 정확하게 정확히 찾아내는 것입니다. 다른 어설 션이 실패했거나 다른 말로 테스트간에 종속성 관계가있는 경우 한 어설 션이 실패한다는 것을 논리적으로 알면 단일 테스트 내에서 여러 어설 션으로 롤링하는 것이 좋습니다. 이는 단일 테스트 내에서 첫 번째 어설 션에 대해 실패한 경우 제거 할 수있는 명백한 실패로 테스트 결과를 버리지 않는 이점이 있습니다. 이 관계가 존재하지 않는 경우에는 이러한 어설 션을 개별 테스트로 분리하는 것이 기본적으로 선호됩니다. 그렇지 않으면 이러한 실패를 찾으려면 모든 문제를 해결하기 위해 여러 번의 테스트 실행을 반복해야하기 때문입니다.

그런 다음 지나치게 복잡한 테스트를 작성해야하는 방식으로 단위 / 클래스를 디자인하면 테스트 중에 부담이 줄어들고 더 나은 디자인을 촉진 할 수 있습니다.

네, 여러 주장을 가지고 괜찮 만큼 실패하는 테스트가 실패를 진단 할 수 있도록 당신에게 충분한 정보를 제공합니다. 이것은 테스트 대상과 실패 모드에 따라 다릅니다.

적절한 단위 테스트는 정확히 한 가지 이유로 실패해야하므로 단위 테스트 당 하나의 어설 션을 사용해야합니다.

나는 그러한 공식이 도움이되는 것을 결코 발견하지 못했습니다. 두 문자열이 같다는 주장을 고려하십시오. 이는 두 문자열의 길이가 동일하고 해당 색인의 각 문자가 같다는 것을 의미하는 것과 의미가 같습니다.

다중 어설 션 시스템을 단일 어설 션으로 다시 작성할 수 있고 단일 어설 션을 더 작은 어설 션 세트로 분해 할 수 있다고 일반화하고 말할 수 있습니다.

따라서 코드의 명확성과 테스트 결과의 명확성에 중점을 두어 그 반대가 아니라 사용하는 어설 션 수를 안내하십시오.

답은 매우 간단합니다. 둘 이상의 속성, 동일한 객체 또는 두 개의 다른 객체를 변경하는 함수를 테스트하고 함수의 정확성이 모든 변경 결과에 따라 결정되면 주장하고 싶습니다. 이러한 모든 변경 사항이 올바르게 수행되었습니다!

나는 논리적 인 개념에 대한 아이디어를 얻었지만 그 반대의 결론은 함수가 둘 이상의 객체를 변경해서는 안된다는 것을 말할 것입니다. 그러나 그것은 내 경험으로 모든 경우에 구현하는 것이 불가능합니다.

은행 거래의 논리적 개념을 취하십시오. 대부분의 경우 한 은행 계좌에서 금액을 인출하는 것이 해당 금액을 다른 계좌에 추가하는 것을 포함해야합니다. 이 두 가지를 분리하고 싶지 않으며 원자 단위를 형성합니다. 두 가지 기능 (withdraw / addMoney)을 만들어 두 가지 다른 단위 테스트를 작성할 수도 있습니다. 그러나이 두 가지 조치는 한 트랜잭션 내에서 발생해야하며 트랜잭션이 작동하는지 확인하려고합니다. 이 경우 개별 단계를 성공적으로 수행하는 것만으로는 충분하지 않습니다. 테스트에서 두 은행 계좌를 모두 확인해야합니다.

단위 테스트에서 테스트하지 않고 통합 또는 수락 테스트에서 테스트하는 더 복잡한 예제가있을 수 있습니다. 그러나 그 경계는 유창합니다. IMHO! 결정하기가 쉽지 않고 상황과 개인적 취향의 문제입니다. 하나에서 돈을 인출하고 다른 계정에 추가하는 것은 여전히 ​​매우 간단한 기능이며 확실히 단위 테스트 후보입니다.

이 질문은 스파게티와 라자냐 코드 문제 간의 균형을 맞추는 고전적인 문제와 관련이 있습니다.

여러 가지 어설 션을 사용하면 테스트에 대한 아이디어가없는 스파게티 문제에 쉽게 도달 할 수 있지만 테스트 당 단일 어설 션을 사용하면 큰 라자냐에서 여러 테스트를 수행하여 테스트를 읽을 수 없게 만들 수 있습니다. .

몇 가지 예외가 있지만이 경우 진자를 중간에 유지하는 것이 답입니다.

나는 일반적으로 "한 가지 이유로 만 실패"에 동의하지 않습니다. 더 중요한 것은 테스트가 짧고 명확하게 읽는다는 것입니다.

이것은 항상 달성 가능한 것은 아니며 테스트가 복잡 할 때 (긴) 설명적인 이름과 적은 수의 테스트는 더 의미가 있습니다.