Лучшая практика для автоматизированного тестирования - PullRequest
1 голос
/ 16 ноября 2009

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

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

Возможно, это звучит долго, но я вас уверяю - пока мне кажется, что мне проще всего работать с EF в моей ситуации.

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

Существует ли какой-либо подход модульного тестирования или автоматизированная методология для проверки такого рода требований. Это ускорило бы развертывание пакетов, сократив мое собственное ручное тестирование.

Любые советы или ссылки на симлары приветствуются.

Ответы [ 3 ]

3 голосов
/ 16 ноября 2009

Я думаю, что есть две части этой проблемы, которую вы описываете:

  1. Сначала вам нужно создать несколько модульных тестов, которые будут соответствовать техническим требованиям системы. Думайте о модульных тестах как о правилах, которые вы установили, чтобы технически достичь цели, которую желает конечный пользователь. Таким образом, я бы разработал модульные тесты, которые, как вы можете быть уверены, сломаются, если сделанное вами техническое предположение о системе не будет выполнено из-за изменения кода. Не забудьте сохранить модульные тесты на уровне модулей, чтобы у вас не было большого количества зависимостей, взаимодействующих для провала теста. Модульный тест должен проверить ровно одну вещь. Если вы сделаете это, когда вы внесете изменения в код, вы сможете запустить все свои модульные тесты и сразу узнать, какие предположения вы сделали относительно системы, которые сейчас не выполняются.

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

3 голосов
/ 16 ноября 2009

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

1 голос
/ 16 ноября 2009

Лучшая практика для юнит-тестов - просто сделай это! Кроме того, я хотел бы рекомендовать xUnit Test Patterns: рефакторинг тестового кода от Gerard Meszaros.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...