Как запустить юнит-тест старого и нового кода?

Question

Я признаю, что у меня почти нет опыта юнит-тестирования. Я пытался с DUnit некоторое время назад, но сдался, потому что в моем приложении было так много зависимостей между классами. Это довольно большое (около 1,5 миллиона строк исходного кода) приложение Delphi, и мы являемся командой, которая его поддерживает.

На данный момент тестирование выполняется одним человеком, который использует его перед выпуском и сообщает об ошибках. Я также настроил некоторые GUI-тесты в TestComplete 6, но он часто дает сбой из-за изменений в приложении.

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

Я просто не знаю, с чего начать юнит-тестирование ... Какие-нибудь хорошие книги, URL, лучшие практики и т.д.?

Answer 1

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

В любом случае, если вы можете выполнить рефакторинг, сделайте рефакторинг, чтобы сделать его тестируемым. Не смешивайте создание объектов с логикой, когда это возможно (я не знаю delphi, но может быть какая-то инфраструктура внедрения зависимостей, чтобы помочь в этом).

В этом блоге есть много хорошего о тестировании. Например, проверьте эту статью (мое первое предложение было основано на ней).

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

Answer 2

Написание модульных тестов для унаследованного кода обычно требует большого количества рефакторинга. Отличная книга, которая освещает это, - Майкл Фезер " Эффективно работает с устаревшим кодом "

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

Эффективная работа с устаревшим кодом

Answer 3

Когда вы работаете с унаследованным кодом, фиктивные объекты действительно полезны для создания модульных тестов.

Взгляните на этот вопрос, касающийся Delphi и макетов: Какая ваша любимая библиотека Moph для Delphi?

Answer 4

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

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

Альтернативный подход, который я использовал, заключается в разработке моих модульных тестов с помощью Co-Ops:)

Answer 5

Для модульного тестирования .Net читайте: « Искусство модульного тестирования: с примерами в .NET »

О лучших примерах:
То, что вы сказали, правильно: иногда трудно писать модульные тесты из-за зависимости между классами ... Так что пишите модульные тесты сразу после или непосредственно перед ;-) реализацией классов. Например, если у вас возникли трудности с написанием тестов, возможно, это означает, что у вас проблемы с дизайном!