Лучшие практики для рефакторинга тестового кода - PullRequest
2 голосов
/ 15 апреля 2011

В настоящее время у меня есть работа в QA, и в моей компании все в QA пишут автоматизированные тесты.Недавно я читал Рефакторинг: улучшение дизайна существующего кода Мартина Фаулера.Я пришел к выводу, что многие наши тестовые классы и тестовые утилиты очень грязные, избыточные и нуждаются в рефакторинге.

Тем более, что я читаю эту тему, мне не терпится погрузиться и почистить вещи, но есть одна проблема.В своей книге Фаулер подчеркивает, что модульное тестирование кода под рефакторингом необходимо для предотвращения появления ошибок.Поскольку код, который я пытаюсь реорганизовать, является тестовым кодом, кажется глупым его юнит-тестирование.Ребята, есть ли у вас какие-либо предложения о том, как реорганизовать или даже разработать тестовый код?Кроме того, если это помогает, используемая нами тестовая среда построена поверх JUnit, и поэтому классы тестов, на которые я ссылаюсь, являются потомками TestCase.

Спасибо!

Ответы [ 2 ]

1 голос
/ 15 апреля 2011

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

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

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

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

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

0 голосов
/ 16 апреля 2011

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

...