Развертывание большого теста, замаскированного под программу

Question

Если кто-то создал небольшое диагностическое внутреннее веб-приложение, в котором в качестве логики используются (модульные) тесты, есть ли для этого веская причина?Имейте в виду, что Nunit также должен быть развернут везде, где бы ни находился этот веб-сайт.

Я придерживаюсь мнения, что программы должны содержать свою собственную логику и, возможно, повторно используемые части (если таковые имеются), но не должны содержать тесты-обертки для своей логики.Тесты служат для проверки логики кода.Если вы говорите, что тесты будут представлять собой логику кода, разве вам не нужно писать тесты для проверки тестов?Почему это в корне неправильно?

Намекать:Потому что теперь вы связываете все эти тесты вместе и связываете их между собой, а это значит, что они больше не зависят(?).

Answer 1

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

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

Answer 2

Я почти уверен, если вы посмотрите на этот вопрос Каталог антипаттернов TDD, вы обнаружите, что совершаете серьезные антишаблоны.

Answer 3

Код есть код.Тот факт, что оно помечено как тест, не означает, что это бесполезное приложение.

Предположим, нам нужно написать множество проверок поведения.Почему использование тестовой среды — плохая идея?Должны ли мы вместо этого написать новый фреймворк с идентичной функцией и назвать его как-то по-другому?

Взгляните на внешний вид.Это приложение утверждает, что делает определенные вещи.Правильно ли он их делает?надежно?Можно ли его сохранить, улучшить?Понял?

Если да, то почему вас волнует, что при его реализации используется тестовая среда?Если его поведение или структура дефектны затем мы критикуем.

В великих технологиях есть одна замечательная черта: у них есть неожиданные применения.

Answer 4

Цель модульного тестирования — убедиться, что ваш класс работает так, как должен, и в соответствии с интерфейсом.Итак, если вы используете модульные тесты для какого-либо приложения для тестирования, это похоже на использование утверждения в логике программы.

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

Еще одна причина, которую я вижу — юнит-тесты пишутся исходя из предположений о том, как все работает.Если ваше предположение верно, тесты должны пройти.При добавлении юнит-тестов функциональности вы можете быть уверены, что все предположения остаются в силе.Поэтому каждый тест должен быть максимально простым.вот почему нет необходимости тестировать тестовый код и нет необходимости использовать тестовый код в каких-либо тестовых приложениях.