exam06 4
Реферат к лекции 6 (22). Управление конфигурацией
Выполнил: Метленкин В.Е. [ИДБ-18-08]
Проверил: Щербаков М.С. [ИДБ-18-07]
Рефакторинг — это процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. Цель рефакторинга — сделать код программы более легким для понимания; без этого рефакторинг нельзя считать успешным.
Нужно отличать рефакторинг от реинжиниринга, который осуществляется для расширения функциональности программного обеспечения. Как правило, крупные рефакторинги предваряют реинжиниринг. [1]
TFD — устаревшая концепция, которая была описана Кентом Беком в книге "Экстремальное программирование". Это подход разработки, в которой разрабочики не пишут ни единой строчки кода, пока они не создали тесты (тест-кейсы), необходимые, чтобы доказать, что данный код (модуль) решает бизнес-проблему и это технически корректно на уровне модульного тестирования. [2]
TFD имеет несколько базовых шагов:
- Разработчик принимает задачу и пишет набор тестов под нее, который докажет, что функции, которые требуется реализовать на самом деле корректны на данном модульном уровне.
- Разработчики запускают тесты. Тесты должны провалиться, потому что кода для решения бизнес-задачи еще не написан. Если тесты пройдут успешно, нужно их переписать так, чтобы они провалились (если кто-то другой уже не решил эту задачу).
- Написать код, который выполнит задачу (и только ее, не более).
- Запустить тесты еще раз. Если тесты прошли - задача выполнена. Если же хоть один из тестов провалился, нужно перейти к шагу 3 и подкорректировать код. Повторяйте шаги 3 и 4, пока все тесты не пройдут успешно.
TDD — это методология разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. [3]
Данная методология является более усовершенствованной версии методологии TFD.
Разработка через тестирование требует от разработчика создания автоматизированных модульных тестов, определяющих требования к коду непосредственно перед написанием самого кода. Тест содержит проверки условий, которые могут либо выполняться, либо нет. Когда они выполняются, говорят, что тест пройден. Прохождение теста подтверждает поведение, предполагаемое программистом. На практике модульные тесты покрывают критические и нетривиальные участки кода. Это может быть код, который подвержен частым изменениям, код, от работы которого зависит работоспособность большого количества другого кода, или код с большим количеством зависимостей.
Цикл разработки через тестирование:
- Добавление теста.
- Запуск всех тестов: убедиться, что новые тесты не проходят.
- Написать код.
- Запуск всех тестов: убедиться, что все тесты проходят.
- Рефакторинг. (Новый шаг в дополнение TFD)
- Повторить цикл.
Архитектура программных продуктов, разрабатываемых таким образом, обычно лучше (в приложениях, которые пригодны для автоматического тестирования, обычно очень хорошо распределяется ответственность между компонентами, а выполняемые сложные процедуры декомпозированы на множество простых). Стабильность работы приложения, разработанного через тестирование, выше за счёт того, что все основные функциональные возможности программы покрыты тестами и их работоспособность постоянно проверяется. Сопровождаемость проектов, где тестируется всё или практически всё, очень высока — разработчики могут не бояться вносить изменения в код, если что-то пойдёт не так, то об этом сообщат результаты автоматического тестирования.
BDD — это методология разработки программного обеспечения, являющаяся ответвлением от методологии разработки через тестирование (TDD).
Основной идеей данной методологии является совмещение в процессе разработки чисто технических интересов и интересов бизнеса, позволяя тем самым управляющему персоналу и программистам говорить на одном языке. Для общения между этими группами персонала используется предметно-ориентированный язык, основу которого представляют конструкции из естественного языка, понятные неспециалисту, обычно выражающие поведение программного продукта и ожидаемые результаты. [4]
BDD методология является расширением TDD в том смысле, что перед тем как написать какой-либо тест, необходимо сначала описать желаемый результат от добавляемой функциональности на предметно-ориентированном языке. После того как это будет проделано, конструкции этого языка переводятся специалистами или специальным программным обеспечением в описание теста.
BDD фокусируется на следующих вопросах:
- С чего начинается процесс.
- Что нужно тестировать, а что нет.
- Сколько проверок должно быть совершено за один раз.
- Что можно назвать проверкой.
- Как понять, почему тест не прошёл.
Спецификация поведения строится в полуформальной форме. В настоящее время в практике BDD устоялась следующая структура:
- Заголовок (англ. Title). В сослагательной форме должно быть дано описание бизнес-цели.
- Описание (англ. Narrative). В краткой и свободной форме должны быть раскрыты следующие вопросы:
- Кто является заинтересованным лицом данной истории;
- Что входит в состав данной истории; *Какую ценность данная история предоставляет для бизнеса.
- Сценарии (англ. Scenarios). В одной спецификации может быть один и более сценариев, каждый из которых раскрывает одну из ситуаций поведения пользователя, тем самым конкретизируя описание спецификации. Каждый сценарий обычно строится по одной и той же схеме:
- Начальные условия (одно или несколько);
- Событие, которое инициирует начало этого сценария;
- Ожидаемый результат или результаты.
Следующий пример демонстрирует спецификацию поведения с использованием языка Gherkin (рисунок 1):
Рис. 1. Спецификация поведения с использованием языка Gherkin