Как мне реагировать на оправдания не преобразования данных модульного тестирования?

Question

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

Существует набор правил, которые документируют сопоставления, которые должны быть выполнены. Сегодня не существует автоматизированного способа проверки того, что сопоставления являются «правильными». Мы предложили группе протестировать отдельные сопоставления, создав простую среду тестирования и затем проверяя правила преобразования по одному перед каждым развертыванием, но у них есть типичные проблемы:

1. Как узнать, что мой тест или мэппинг неверны?
2. Что произойдет, если кто-то изменит отображение и мои тестовые перерывы будут сделаны?
3. Как я должен оправдывать все время, которое мне нужно потратить, чтобы составить контрольные примеры?
4. Что если тест дает ложный отрицательный результат (то есть, проходит, когда не должен)?

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

Answer 1

1 - Как я могу узнать, что мой тест или отображение неверны?

На сегодняшний день, откуда вы знаете, что отображение верно?Кто-то должен будет исследовать, если это проблема.Лучше, чтобы модульный тест не прошел, и теперь кто-то может исследовать его, вместо того, чтобы передавать его в QA или даже клиенту.

2 - Что произойдет, если кто-то изменит отображение и мой тест прервется?

Это не ваши модульные тесты, это модульные тесты.Тот, кто ломает сборку, исправляет сборку.Каждый должен выполнить все модульные тесты перед регистрацией, и они должны запускаться автоматически при каждой регистрации по Гудзону или подобному.

3 - Как я должен обосноватьсколько времени мне нужно потратить, чтобы сделать тестовые случаи?

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

Не тратьте время на написание модульных тестов, чтобы убедиться, что работакод работает.Добавляйте / обновляйте юнит-тест только в том случае, если вы: 1) изменили функциональность, 2) добавили новую функциональность, 3) исправили ошибку.

Плюс позже, когда вы вернетесь и выполните рефакторинг, вы будете знать, что у вас естьне сильно нарушен код.

4 - Что делать, если тест дает ложный отрицательный результат (т.е. проходит, когда не должен)?

Это фактжизнь.Ошибки будут пропущены.Тот факт, что модульное тестирование может пропустить ошибки, не делает недействительным юнит-тестирование.Я имею в виду, если QA пропустил ошибку, вы бы уволили отдел QA?Цель модульного тестирования состоит в том, чтобы уменьшить количество ошибок, которые не попадают в группу разработчиков.Таким образом, QA может сконцентрироваться на более серьезных проблемах.

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

Модульное тестирование нене серебряная пуля, но она бесценна в развитии.

Answer 2

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

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