Повышение тестируемости при кодировании с помощью Bold для платформы Delphi

Question

Фон Я работаю в команде из 7 разработчиков и 2 тестировщиков, которые работают над системой логистики. Мы используем Delphi 2007 и modeldriven development с Bold для Delphi в качестве фреймворка. Система работает уже около 7 лет и насчитывает около 1,7 миллиона строк кода. Мы выпускаем в производство через 4-5 недель, и после почти каждого релиза нам приходится делать исправления для ошибок, которых мы не нашли. Это, конечно, раздражает и нас, и клиентов.

Текущее тестирование Решение, конечно, более автоматическое тестирование. В настоящее время у нас есть ручное тестирование. Testdbgenerator, который запускается с пустой базы данных и добавляет данные из смоделированных методов. У нас также есть Testcomplete, который запускает несколько очень простых скриптов для тестирования GUI. Отсутствие времени не позволяет нам добавлять дополнительные тесты, но сценарии также чувствительны к изменениям в приложении. Несколько лет назад я действительно пробовал юнит-тестирование с помощью DUnit, но через несколько дней сдался. У единиц есть слишком сильные связи.

Предварительные условия для модульного тестирования Я думаю, что я знаю некоторые предварительные условия для модульного тестирования:

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

Платформа для использования Мы можем перейти на Delphi XE2, в основном из-за 64-битного компилятора. Я немного посмотрел на Spring, но для этого нужно обновить D2007, а сейчас этого не произойдет. Может быть, в следующем году.

Вопрос Большая часть кода по-прежнему не проверяется автоматически. Итак, каков наилучший путь для повышения тестируемости старого кода? Или, может быть, лучше начать писать тесты только для новых методов? Я не уверен, что это лучший способ увеличить автоматическое тестирование, и комментарии по этому поводу приветствуются. Можем ли мы использовать D2007 + DUnit сейчас и потом легко сменить на Delphi XE2 + Spring позже?

РЕДАКТИРОВАТЬ: О текущей методологии тестирования для ручного тестирования просто "набить его и попытаться сломать его", как Chris Thornton называет это.

Answer 1

Вам нужна книга Майкла Фезерса " Эффективная работа с устаревшим кодом". Он показывает, как ввести (модульные) тесты в код, который не был написан с учетом тестируемости.

Некоторые главы названы в качестве оправданий, которые может дать разработчик из-за того, что тестировать старый код сложно, и они содержат примеры из практики и предложенные способы решения каждой проблемы:

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

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

Answer 2

Требования к автоматическому модульному тестированию именно такие:

1. используйте каркас модульного тестирования (например, DUnit).
2. использовать какие-то насмешливые рамки.

Пункт 2 является сложным.

СУХОЙ, маленькие методы, начните с теста, и DI - все сахар. Сначала нужно начать юнит-тестирование. Добавляйте СУХОЙ и т. Д. По мере продвижения. Уменьшенное связывание помогает упростить модульное тестирование, но без огромных усилий по рефакторингу вы никогда не уменьшите связывание в существующей кодовой базе.

Подумайте о написании тестов для новых вещей и вещей, которые были изменены в выпуске. Со временем вы получите разумную базу модульных тестов. Новые и измененные вещи также могут быть реорганизованы (или написаны красиво).

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

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

Answer 3

Ваша команда тестирования слишком мала, ИМО. Я работал в командах, где отдел контроля качества превосходил разработчиков. Подумайте о работе в "спринтах" управляемых фрагментов (функций, исправлений), которые вписываются в меньшие циклы. "Agile" будет стимулировать 2-недельные спринты, но это может быть слишком жестким. Во всяком случае, это будет держать QA постоянно занятым, работая дальше перед окном выпуска. Прямо сейчас, я подозреваю, что они бездействуют, пока вы не дадите им огромное количество кода, а затем они затоплены. С более короткими циклами выпуска вы можете занять больше тестеров.

Кроме того, вы не сказали много об их методологии тестирования. Есть ли у них стандартные сценарии, которые они запускают, где они проверяют внешний вид и поведение в отношении ожидаемого внешнего вида и поведения? Или они просто "стучат по нему и пытаются его сломать"?

IMO, тестирование Dunit сложно провести с множеством зависимостей, таких как базы данных, связь и т. Д. Но это выполнимо. Я создал классы DUnit, которые автоматически запускают сценарии установки базы данных (ищите файл.sql с тем же именем, что и у тестируемого класса, запускайте sql, затем тест продолжается), и это было очень эффективно. Для обмена сообщениями SOAP у меня запущен mockservice SoapUI, который возвращает ожидаемые результаты, поэтому я могу проверить свои сообщения.
Это требует работы, но оно того стоит.