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

Question

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

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

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

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

Answer 1

1 Как узнать, не соответствует ли мой тест или сопоставление?

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

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

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

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

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

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

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

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

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

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

Единичное тестирование - это не серебряная пуля, но она неоценима в развитии.

Answer 2

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

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