Принципы быстрой разработки ПО - Притча

E-mail Печать PDF
Рейтинг пользователей: / 0
ХудшийЛучший 
Индекс материала
Принципы быстрой разработки ПО
Экстремальное программирование
Игра в планирование (Planning Game)
Пользовательские истории
«Билль о правах» заказчика
«Билль о правах» программиста
Притча
xUnit
Приемочные тесты
План рабочего цикла
План выпуска версий
Все страницы

Притча

Метеорологическая служба одной страны истратила базиллион долларов на разработку новейшей системы предсказания погоды. Лампочки сияют, отчеты печатаются, вращаются разные колесики, все выглядит очень впечатляюще. Более того, прогнозы, которые выдает чудо-машина, верны на целых 70%! Заказчик, заплативший базиллион долларов, в полном восхищении.

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

Тестирование (Testing)

В ХР используется две разновидности тестирования:

·                    тестирование модулей (unit testing);

·                    приемочное тестирование (acceptance testing).

Тесты модулей (unit tests) разрабатываются программистами по мере того, как они пишут код. Тесты функциональности (acceptance tests) разрабатываются заказчиком после того, как он формулирует пожелания (stories). Тесты модулей в любой момент времени сообщают разработчику о том, что разработанный код функционирует корректно. Приемочные тесты сообщают всей команде о том, что разрабатываемый продукт делает именно то, чего хочет пользователь.

Если предположить, что для разработки команда использует объектно-ориентированный язык, разработчики пишут тесты для каждого метода, корректность работы которого может быть нарушена. Разработка тестов для метода выполняется до того, как будет написан рабочий код этого метода. После того как разработаны все возможные тесты, разрабатывается код метода. Реализация метода должна быть такой, чтобы обеспечить выполнение всех тестов, и не более того. Для многих такой подход кажется весьма странным, однако он вполне оправдан. Благодаря тому, что код тестов пишется до того, как разрабатывается код метода, вы получаете:

·                    наиболее полный набор всевозможных тестов;

·                    наиболее простой код, который (скорее всего) реализует заданную функциональность;

·                    четкое представление о том, какую задачу решает код.

Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой системы, Тесты модулей позволяют разработчикам убедиться в том, что их код работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода и как он функционирует. Тесты модулей – это удобная разновидность документации. Тесты модулей также позволяют разработчику без каких-либо опасений выполнять рефакторинг (relactoring) кода, то есть вносить в код любые улучшающие его изменения. В любое время разработчик может без страха модифицировать любой фрагмент кода системы, — тесты модулей немедленно сообщат ему о том, что корректность работы системы в результате этого не пострадала или, напротив, что работоспособность кода нарушена. Тесты модулей должны выполняться автоматически, в результате их работы разработчик должен получить четкий, недвусмысленный ответ: «код работоспособен» или «код неработоспособен».

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



 

Добавьтe Ваш комментарий

Ваше имя (псевдоним):
Ваш адрес почты:
Заголовок:
Комментарий:

Комментарии, категория: "IT"

Интересное




Похожие материалы

Партнёры