Предыдущая серия была тут - 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 делается не для чего-то "абстрактного", что "будет когда-то потом". А для ВПОЛНЕ КОНКРЕТНОГО.
Описанного в архитектуре и растущими ногами из ТЗ."
Промежуточные итоги я постарался сформулировать вот тут - 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 делается не для чего-то "абстрактного", что "будет когда-то потом". А для ВПОЛНЕ КОНКРЕТНОГО.
Описанного в архитектуре и растущими ногами из ТЗ."
Комментариев нет:
Отправить комментарий