Делает Поблочное тестирование, делают Отладку. Утверждать () ненужный?

Question

Делает Поблочное тестирование, делают Отладку. Утверждать () ненужный?

Попробуйте добавить функцию wait() с задержкой в 2 секунды.

private drawTracing(tracingArray: Tracing[]) {

    for (let i=0; i < length; i++) {
          //2 Sec delay
          if (i===5) {
            wait(2000)
          }
         this.creatTracing(tracingArray[i]);
    }

}

. Или вы можете использовать setTimeOut

private drawTracing(tracingArray: Tracing[]) {

    for (let i=0; i < length; i++) {
          //2 Sec delay 
         if (i === 5) {
           setTimeout(() => { console.log('2 sec delay'); }, 2000)
         }

         this.creatTracing(tracingArray[i]);
    }

}

.

10

c# unit-testing

задан Community 23 May 2017 в 12:34

5 ответов

Если вы проводите исчерпывающее модульное тестирование, которое охватывает все странные случаи, с которыми вы можете столкнуться, то я не думаю, что вы найдете утверждения очень полезными. Большинство людей, которые не проводят модульное тестирование, ставят утверждения, чтобы установить подобные ограничения, как вы ловите с помощью своих тестов.

2

ответ дан 3 December 2019 в 22:39

Я думаю, что идея модульного тестирования в этом случае состоит в том, чтобы перенести эти утверждения в тестовые наборы, чтобы убедиться, что вместо Debug.Assert (...) ваш код в тестовых дескрипторах это не вырвет (или гарантирует, что это вырвет правильно).

1

ответ дан 3 December 2019 в 22:39

Я использую как модульное тестирование, так и утверждения для различных целей.

Модульное тестирование - это автоматический эксперимент, показывающий, что ваша программа (и ее части) функционируют, как указано. Как и в математике, экспериментирование не является доказательством, если вы не можете попробовать все возможные комбинации входных данных. Ничто не демонстрирует это лучше, чем тот факт, что даже при модульном тестировании ваш код будет содержать ошибки. Не много, но оно будет иметь их.

Утверждения для ловли хитрых ситуаций во время выполнения, которые обычно не должны происходить. Может быть, вы слышали о предварительных условиях, постусловия, неизменяемые циклы и тому подобное. В реальном мире мы не часто проходим формальный процесс фактического доказательства (формальной логикой) того, что фрагмент кода выдает указанные постусловия, если они выполняются. Это было бы реальным математическим доказательством, но у нас часто нет времени делать это для каждого метода. Однако, проверяя, выполняются ли предварительные и постусловия, мы можем обнаружить проблемы на гораздо более ранней стадии.

3

ответ дан 3 December 2019 в 22:39

Я обычно вижу утверждения, используемые для проверки работоспособности внутреннего состояния, а не такие вещи, как проверка аргументов.

IMO входные данные для надежного API должны быть защищены проверками, которые остаются на месте независимо от типа сборки. Например, если открытый метод ожидает аргумент, представляющий собой число в диапазоне от 5 до 500, он должен быть защищен с помощью ArgumentOutOfRangeException. Сбой быстро и часто сбои, используя исключения, насколько я понимаю, особенно когда аргумент куда-то выдвигается и используется гораздо позже.

Однако, в местах, где внутренние, переходное состояние проверяется на работоспособность (например, проверяется, что какое-то промежуточное состояние находится в разумных пределах во время цикла), кажется, что Debug.Assert больше дома. Что еще вы должны делать, если ваш алгоритм работает неправильно, несмотря на то, что ему были переданы действительные аргументы? Бросить EpicFailException? :) Я думаю, что именно здесь Debug.Assert все еще полезен.

Я все еще не определился с лучшим балансом между ними. Я перестал использовать Debug.Asserts в C # с тех пор, как начал модульное тестирование, но для них все еще есть место для IMO. Я, конечно, не буду использовать их для проверки правильности использования API, но проверка работоспособности в труднодоступных местах? Конечно.