вторник, 3 июня 2014 г.

Тестируем калькулятор №6.2.1. Применяем "классическое TDD" (анонс)

Предыдущая серия была тут - http://programmingmindstream.blogspot.ru/2014/06/62.html

Промежуточные итоги я постарался сформулировать вот тут - http://programmingmindstream.blogspot.ru/2014/06/62.html?showComment=1401745726422#c664156170645232329

Теперь мы поговорим о "классическом TDD", а именно - о его части - Test First.

В предыдущих главах мы сделали вот что:

1. Настроили ИНФРАСТРУКТУРУ тестирования.
2. Сделали GUI-тесты.
3. Сделали тесты бизнес-логики.
4. Сделали тесты бизнес-логики с использованием эталонов и ПРОТЕСТИРОВАЛИ (худо-бедно) работу эталонов.
5. Из тестов бизнес-логики и работы с эталонами при помощи псевдослучайных данных мы сделали РЕГРЕССИОННЫЕ тесты.

Теперь давайте попробуем применить "классическое TDD".

Итак.

В нашем калькуляторе есть ЧЕТЫРЕ операции - сложение, вычитание, умножение и деление.

И ПУСТЬ - мы выпускаем НОВУЮ версию приложения, в которой ЗАКАЗЧИК захотел увидеть ЕЩЁ ОДНУ операцию.

Пусть это будет - "целочисленное деление" (варианты от аудитории - рассматриваются).

Итак.

Что мы делаем?

1. Проводим интервью с заказчиком и выясняем подробности.
2. Фиксируем ТЗ.
3. Пишем тест TestIntDiv (где?) который содержит ОДНУ СТРОЧКУ - Assert(false, 'Not Implemented'). Убеждаемся, что тест НЕ ПРОХОДИТ. Проверяем все остальные тесты. Коммитим изменения.
4. Пишем операцию бизнес-логики. Переносим в неё строчку Assert(false, 'Not Implemented'). Вызываем эту операцию из теста. Убеждаемся, что тест НЕ ПРОХОДИТ. Проверяем все остальные тесты. Коммитим изменения.
5. Реализуем операцию бизнес-логики. Убеждаемся, что ТЕСТ ПРОХОДИТ. Проверяем все остальные тесты. Коммитим изменения.
6. Подключаем новую бизнес-логику к GUI. Проверяем все тесты. Коммитим.
6. Пишем GUI-тест для НОВОЙ ОПЕРАЦИИ. Убеждаемся, что он проходит. Проверяем все тесты. Коммитим.

Понятное дело, что "алгоритм несколько избыточен". Далеко не всегда в реальной жизни происходит именно так.

Но!

Отдельно хочется отметить два шага с Assert.

Они - ОБА ВАЖНЫ.

На первом - мы отвечаем на вопрос "ГДЕ мы тестируем", т.е. выбираем ПОДХОДЯЩЕЕ МЕСТО для теста (в нашей инфраструктуре).

На втором - мы отвечаем на вопрос "ЧТО мы тестируем", т.е. связываем тест с ПОДХОДЯЩЕЙ бизнес-логикой (в нашей архитектуре).

Ну и хочется обратить внимание на тот факт, что ПОДКЛЮЧЕНИЕ бизнес-логики к GUI происходит "на заключительных этапах", т.е. когда бизнес-логика УЖЕ написана и УЖЕ оттестирована.

Так далеко НЕ ВСЕГДА бывает "в жизни", но мы ПОКА рассмотрим именно ТАКОЙ ВАРИАНТ.

И ешё - последний пункт - "Пишем GUI-тест для НОВОЙ ОПЕРАЦИИ." - он вообще говоря - ОПЦИОНАЛЕН, чтобы не утонуть во множестве "Це из Эн по Ка". Вообще говоря - можно не писать тест, а дать протестировать тестировщикам - "руками". В общем - этот вариант - он "обсуждаемый". И мы коснёмся (надеюсь) данного вопросы в будущих статьях.

Надеюсь, что мне с коллегой удастся раскрыть данную тему МАКСИМАЛЬНО интересно.

P.S. На что я хочу ещё СДЕЛАТЬ УПОР говоря о TDD - так это о первой части - "настроили ИНФРАСТРУКТУРУ тестирования".

По МОЕМУ мнению - НИ О КАКОМ TDD не может идти речь, если не проделан шаг "настройки ИНФРАСТРУКТУРЫ".

Если не решены вопросы:

1. Куда добавлять тесты.
2. Куда "жать", чтобы запустились тесты.
3. Как увидеть результаты тестов.
4. Как тесты связаны со сборками реальных проектов.
5. Какие применять метрики.

И т.д. и т.п.

Это - ОЧЕНЬ ВАЖНЫЙ ШАГ. Подумайте об этом, если конечно вы не применяете тестирование. Если ПРИМЕНЯЕТЕ, то скорее всего - "ИНФРАСТРУКТУРУ вы УЖЕ НАСТРОИЛИ".

Ссылки:
http://programmingmindstream.blogspot.ru/2013/11/tdd.html
http://programmingmindstream.blogspot.ru/2013/11/blog-post.html
http://programmingmindstream.blogspot.ru/2013/11/blog-post.html
http://programmingmindstream.blogspot.ru/2013/11/tdd_28.html

--------------------------------

http://programmingmindstream.blogspot.ru/2013/11/tdd_28.html
!!!!
"Я не хочу "спорить", а тем более опровергать или критиковать никого из уважаемых "теоретиков TDD".  

Я лишь хочу описать свою трактовку. Ну или - как я это "для себя" понял.


TDD говорит нам примерно следующее:

1. Запустите ВСЕ тесты, убедитесь, что они прошли.
2. Добавьте новый тест для новой функциональности. Убедитесь, что он не прошёл.
3. Добавьте функциональность. Убедитесь, что тест прошёл.

Какой вопрос сразу возникает у людей?

А вот какой: "Как я могу написать тест к тому, чего НЕТ?"?

И люди - ПРАВЫ.

Я сам когда впервые смотрел на TTD - думал - "вот чушь собачья". (Это - "эпитет", а не "ругательство")

"Как можно писать тест к тому чего НЕТ? Пусть даже и НЕ проходящий.

"Пойди туда не знаю куда..."

Я долго думал и вот, что я для себя надумал:

НЕТУ TestFirst.

НЕТУ TestFirst.

В ПЕРВУЮ очередь - есть "набросок" АРХИТЕКТУРЫ. Не код, ни тесты, ни что-то ещё. А именно - "набросок" АРХИТЕКТУРЫ.

И TestFirst делается не для чего-то "абстрактного", что "будет когда-то потом". А для ВПОЛНЕ КОНКРЕТНОГО.

 Описанного в архитектуре и растущими ногами из ТЗ."

Комментариев нет:

Отправить комментарий