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

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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