Повышение тестируемости при кодировании с помощью 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 позже?

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

Answer 1

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

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

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

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

Answer 2

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

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

Твердый пункт 2.

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

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

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

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

Answer 3

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

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

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