В тестировании плохо ли делать утверждения при очистке?

В тестировании плохо ли делать утверждения при очистке?
В тестировании плохо ли делать утверждения при очистке? - adriajbove @ Unsplash

В качестве учебного упражнения я решил попробовать себя в Test Driven Development.

Теперь я решил, что есть тест, который я хочу сделать; проверить, не оставляет ли подключение к базе данных несохраненных изменений. Два варианта, которые я могу легко увидеть:

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

Сначала я думал поместить тест в конец каждого метода тестирования, но это оставляет много дублирования кода и может быть пропущено. С другой стороны, помещение assertion в cleanup гарантирует, что в базе данных никогда не будет несохраненных изменений, однако это как будто нарушает Single-Responsibility функции cleanup (которая должна очищать ресурсы).

        [TestCleanup]
        public void Cleanup()
        {
            Assert.IsFalse(dbContext.ChangeTracker.HasChanges(), "unsaved database changes detected.");

            authContext.Dispose();
            dbConn.Dispose();
        }

Это заставляет меня задуматься, является ли тестирование утверждений в очистке плохой идеей?

Я меньше беспокоюсь о СУХОМ коде в модульных тестах и ​​больше беспокоюсь о тесте, четко определяющем предполагаемое поведение. У доктора Брауна есть разумный совет, но я бы предпочел утверждать в каждом тесте.

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

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

Размещение утверждений в тестовой очистке может показаться безопасным и может не мешать удалению ресурсов, но я всегда опасаюсь целенаправленно создавать исключения в коде очистки. Изменение какого-либо другого расположения приложения или теста может помешать правильному удалению ресурсов. Это может вызвать каскад сбоев, не связанных с первоначальным сбоем, что усложняет процесс устранения неполадок. Только по этой причине мне нравится разделять утверждения и код очистки, чтобы одно не влияло на другое.

Думайте об этом как о соблюдении Принципа единой ответственности в вашем тестовом коде. Тестируемая система и очистка — это разные задачи, и они изменяются по разным причинам. У них разные обязанности, и поэтому они заслуживают разного отношения к вашему тестовому коду.


LetsCodeIt, 27 декабря 2022 г., 10:27