Развертывание большого теста, замаскированного под программу - PullRequest
0 голосов
/ 19 августа 2009

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

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

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

Ответы [ 4 ]

3 голосов
/ 19 августа 2009

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

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

0 голосов
/ 23 августа 2009

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

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

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

0 голосов
/ 19 августа 2009

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

0 голосов
/ 19 августа 2009

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

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

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

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

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

...