Задорная презентация, посвещенная введению в разработку через тестирование. В частности, рассмотрены такие методологии как TDD (Test-Driven Development) и BDD (Behavior-Driven Devopment), их несомненные достоинства и недостатки, а также практическое применение.
Презентация подготовлена по материалам прошедшей 10.10.2013 конференции "Developers Software Conference 2013" в Витебске, организатором которой выступила компания "EPAM Systems".
Behavior Driven Development - подход к разработке ПО, основывающийся на ориентации на business value и исполняемых спецификациях, написанных на человеческом языке
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
Задорная презентация, посвещенная введению в разработку через тестирование. В частности, рассмотрены такие методологии как TDD (Test-Driven Development) и BDD (Behavior-Driven Devopment), их несомненные достоинства и недостатки, а также практическое применение.
Презентация подготовлена по материалам прошедшей 10.10.2013 конференции "Developers Software Conference 2013" в Витебске, организатором которой выступила компания "EPAM Systems".
Behavior Driven Development - подход к разработке ПО, основывающийся на ориентации на business value и исполняемых спецификациях, написанных на человеческом языке
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
Евгений Сафронов "Тестирование. точка зрения разработчика"DataArt
Что прежде всего объединяет тестировщика и разработчика? Работа в одной команде и общая цель — качественный и завершенный программный продукт.
Мы рассмотрим различные мнения и подходы к тестированию.
Познакомимся с различными видами тестирования, которые может выполнять программист, работая над продуктом. Разберем несколько интересных примеров Unit-тестирования, поговорим о востребованных и эффективных на сегодняшний день практиках.
XP Days Ukraine 2014 - Refactoring legacy codeDmytro Mindra
Every programmer has to face legacy code day after day. It might be ugly, it might look scary, it can make a grown man cry. Some will throw it away and try rewriting everything from scratch. Most of them will fail.
Refactoring legacy code is a much better idea. It is not so scary when you take it in very small bites, introduce small changes, add unit tests. When code is refactored and unit tests are added, changes to functinality can be introduced.
We will take an open source C# project and will refactor it showing step-by-step examples of the techniques. This session is full of tips and tricks you can start applying immediately. Although the code is in C#, the same principles can be applied in any language.
Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Документация тестировщика - Александр ТрибушныйDataArt
Как сделать документацию тестировщика лучше?
- зачем нужна матрица трассируемости?
- проблемы разработки тест-кейса;
- частые ошибки при написании баг-репорта;
- рекомендации при написании тест-кейсов и баг-репортов.
QA Fest 2019. Андрей Солнцев. Десять причин моей ненавистиQAFest
Меня часто спрашивают, за что я не люблю в тестах Page Objects, TestNG, ReportPortal, try/catch, циклы и условия, неявные ожидания, явные ожидания, Dependency injection, Spring и т.д.
Расскажу коротко и быстро. На каждую тему 5 минут.
От сердца к сердцу или эмоциональный маркетингArtjoker
Проблематика: самые успешные рекламные кампании апеллируют к эмоциям. Ведь желание, доверие и лояльность потребителей завоевывается именно через эмоции. И если в оффлайне эмоциональным маркетингом пользуются многие бренды, то в онлайне это пока еще совсем сырой и многими неосвоенный инструмент.
Евгений Сафронов "Тестирование. точка зрения разработчика"DataArt
Что прежде всего объединяет тестировщика и разработчика? Работа в одной команде и общая цель — качественный и завершенный программный продукт.
Мы рассмотрим различные мнения и подходы к тестированию.
Познакомимся с различными видами тестирования, которые может выполнять программист, работая над продуктом. Разберем несколько интересных примеров Unit-тестирования, поговорим о востребованных и эффективных на сегодняшний день практиках.
XP Days Ukraine 2014 - Refactoring legacy codeDmytro Mindra
Every programmer has to face legacy code day after day. It might be ugly, it might look scary, it can make a grown man cry. Some will throw it away and try rewriting everything from scratch. Most of them will fail.
Refactoring legacy code is a much better idea. It is not so scary when you take it in very small bites, introduce small changes, add unit tests. When code is refactored and unit tests are added, changes to functinality can be introduced.
We will take an open source C# project and will refactor it showing step-by-step examples of the techniques. This session is full of tips and tricks you can start applying immediately. Although the code is in C#, the same principles can be applied in any language.
Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Документация тестировщика - Александр ТрибушныйDataArt
Как сделать документацию тестировщика лучше?
- зачем нужна матрица трассируемости?
- проблемы разработки тест-кейса;
- частые ошибки при написании баг-репорта;
- рекомендации при написании тест-кейсов и баг-репортов.
QA Fest 2019. Андрей Солнцев. Десять причин моей ненавистиQAFest
Меня часто спрашивают, за что я не люблю в тестах Page Objects, TestNG, ReportPortal, try/catch, циклы и условия, неявные ожидания, явные ожидания, Dependency injection, Spring и т.д.
Расскажу коротко и быстро. На каждую тему 5 минут.
От сердца к сердцу или эмоциональный маркетингArtjoker
Проблематика: самые успешные рекламные кампании апеллируют к эмоциям. Ведь желание, доверие и лояльность потребителей завоевывается именно через эмоции. И если в оффлайне эмоциональным маркетингом пользуются многие бренды, то в онлайне это пока еще совсем сырой и многими неосвоенный инструмент.
Bdd j behave or cucumber jvm plus appium for efficient cross platform mobile ...ISsoft
Предлагаем вашему вниманию презентацию «BDD JBehave and Cucumber JVM + Appium for efficient cross-platform Mobile Automation». Этой презентацией сопровождался доклад Антона Семенченко, прочитанный 29 июня на конференции MobileOptimized 2014 в Минске.
В этом докладе я рассказываю о том, как работает компания Аудиомания в контексте обработки заказов, показываю удобные инструменты для сотрудников, а также региональных клиентов и пользователях сайта, а также демонстрирую, что из этого получается.
Управление людьми. Как эмоции влияют на характер? Вадим НарейкоVadim Nareyko
Презентация к тренингу по определению психотипа человека на базе механизмов психологической защиты (на основе психоэволюционной теории Р.Плутчика и структурной теории личности Х.Келлермана)
Проект: Школа Управленческого Мастерства
Ведущие: Вадим Нарейко
Презентация Станислава Полозова для доклада о технологиях продления молодости на 3-м Семинаре по трансгуманизму и научному иммортализму в Санкт-Петербурге (25.09.2010)
В докладе я расскажу о том как я вижу и применяю TDD, почему мне это нравится и почему я хочу, чтобы это нравилось другим. Все это на примере какого-нибудь мини-приложения на базе Django.
Программирование как способ выражения мыслей. Levon Avakyan
Я расскажу на простейших примерах как функционирует современный компьютер, какие языки программирования бывают, для чего они используются, какие парадигмы лежат в их основе. По сути, язык программирования это инструмент, с помощью которого можно рассказать машине, чего же мы от неё хотим, тем самым воплотив свои мысли.
Презентация делалась для JuJa конференции - Java конференции для (пре) Juniors: https://juja.com.ua/materials/jujacon-2017/
В ней
- описываются основные темы-вопросы, которые часто спрашивают на собеседовании на позицию Junior Java Developer;
- советы, что спросить собеседующего;
- как себя позиционировать, как относиться к собеседованию, как не бояться и как понять, что вам "туда".
Джоэл Спольски много лет назад придумал тест на качество и адекватность IT-компании, но ценности он не теряет и по сей день.
Сентябрь 2014, TechTalks NSU, Новосибирск
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Никита Ефимов Lead UX Architect, New Cloud Technologies Anton Anokhin
"Унификация взаимодействия: как мы проектируем интерфейсы нескольких приложений в рамках единого продукта."
"В своём докладе мы расскажем про то, как работает наша дизайн-команда:
- как организован процесс внутри команды
- как мы взаимодействуем с командами разработки
- как проверяем качество итоговой реализации
- как мы внедряем ux-культуру внутри компании (первые шаги, набитые шишки и наша стратегия)
Также поделимся опытом того, как мы прорабатываем один функционал сразу на несколько платформ."
В докладе я постарался рассазать о том, как я вижу и применяю TDD, почему мне это нравится и почему я хочу, чтобы это нравилось другим. Все это на примере мини-приложения на базе Django.
Видео: http://www.youtube.com/watch?v=077DmBBTS3o
Тест-план и исследовательское тестированиеVasiliy Burov
В своем докладе я расскажу как мы в своей работе совмещаем тест-план и исследовательское тестирование. С первого взгляда, может показаться что это не совсем совместимые вещи. Исследовательское тестирование ассоциируется с методом свободного поиска, а тест-план наоборот – следование заданному порядку. Как совместить эти сущности и ничего не потерять – я попытаюсь рассказать.
36. • тестовые методы называются в стиле TestSomeMethod и являют собой
длинную простыню хитросплетений разных сценариев для проверки
работы одного метода;
• значительную часть тестовых методов занимает подготовка и настройка
окружения, так что тяжело понять, что же именно проверяется;
• попытки поместить создание всего окружения в SetUp-методы делают
тестовые классы путанными, а отдельные тестовые методы
зависимыми друг от друга;
• рекомендация держать ровно один Assert на тест не выполняется или
приводит к огромному дублированию кода;
• при изменении требований не так-то легко найти какие тесты нужно
поправить, и даже найдя их, еще нужно сообразить что и как поправить
в длинном витьеватом коде;
• что делать, если у нескольких тестов есть общая часть, - как ее следует
оформить?
• как "правильно" называть тесты, как их группировать в тестовые
классы?
• как соотносятся между собой acceptance-критерии выполнения
требований и набор unit-тестов?
54. Давайте попробуем описать
поведение класса MyStack
• «класс MyStack должен (should):»
– создавать пустой стек
– инициировать исключение при попытке
извлечь элемент из пустого стека
– извлекать последний положенный в него
элемент
– извлекать все положенные в него элементы в
обратном порядке
55.
56. • «класс MyStack должен (should):»
– создавать пустой стек
GIVEN an empty stack ДАН пустой стек
WHEN Count property is asked КОГДА запрашивается Count
THEN it returns zero ТОГДА возвращается 0
– инициировать исключение при попытке извлечь
элемент из пустого стека
GIVEN an empty stack ДАН пустой стек
WHEN Pop() method is called КОГДА вызывается Pop()
THEN exception is raised ТОГДА возникает исключение
57. • «класс MyStack должен (should):»
– извлекать последний положенный в него
элемент
GIVEN an empty stack
and some integer item
WHEN this item is pushed
and Pop() is called
THEN it returns the last item that’s pushed
and it removes item from the stack
and further Pop() call throws exception
63. «Test method names should be sentences»
«A simple sentence template keeps test
methods focused. This sentence template –
The class should do something»
«“Behavior” is a more useful word than “test”»
«What’s the next most important thing the
system doesn’t do?»
64. От пользовательских историй
к описанию поведения
• As [role] • Given [initial context]
I want/can [action] When [event/action]
So that [result] Then [ensure some outcomes]
• Как [роль] • Дано [начальный контекст]
Я хочу/могу [действие] Когда [событие/действие]
Так что [результат] Тогда [конкретный результат]
65. Пример: калькулятор
• Как тугой на голову
Я хочу иметь возможность складывать,
вычитать, делить и умножать два числа
Чтобы видеть результат и не считать в уме
66. Пример: калькулятор
• Дан калькулятор и два числа – «2» и «2»
Когда вводим первое число, «плюс», второе
число
Тогда видим результат «4»
• Дан калькулятор и два числа – «123» и «23»
Когда вводим первое число, «минус», второе
число
Тогда видим результат «100»
68. Новые интересные метрики
• Количество описанных «Поведений»
• Процент автоматизированных тестов на
«Поводение» по отношению к общему
числу описанных «Поведений»
• Отношение количества «Поведений» к
количеству Пользовательских историй или
фич
69.
70. Ноябрь 2009
Конференция «Agile Specifications,
BDD and Testing eXchange»
Dan North
«BDD is a second-generation, outside-in, pull-
based, multiple-stakeholder, multiple-scale, high-
automation, agile methodology. It describes a
cycle of interactions with well- defined outputs,
resulting in the delivery of working, tested
software that matters.»
76. Цикл разработки в TDD
Написание неработающего теста
для новой функциональности
RED
REFACTOR GREEN
Рефакторим код, чтобы Пишем ровно столько кода,
тесты продолжили проходить, чтобы тест прошел
а код стал чистым
77. Традиционный цикл разработки
Пишем сразу заметный
кусок функциональности
CODING
DEBUGING COMPILING
Отлаживаем код, Добиваемся
ловим и исправляем компилируемости
поверхностные баги
78. Написание тестов
с использованием
*Unit-фреймворков
≠
Unit-тестирование
(в строгом смысле)
79. Тестируем как
черный ящик
Тестируем как
прозрачный
ящик Интеграционные
тесты Mock-и,
Stub-ы
Модульные
тесты
(в строгом смысле)
81. BDD – TDD done well?
«I believe this is more than just ‘doing TDD well’.
I think it’s ‘doing TDD and a number of other practices
related to professional software development well’.
The five practices above might
conceivably be done in addition to TDD,
but they’re not part of any definition of TDD I’ve seen.»
83. История
2004 год
Eric Evans
«Domain-Driven Design - Tackling Complexity in the Heart of Software»
84. Domain (словарь)
• наследственная собственность; имение,
поместье; земли; владение e.g. DNS
• территория, зона, область, район
(отмеченные некоторыми физическими
особенностями)
• сфера (интересов), поле (деятельности),
область (знаний) В данном случае
этот смысл
• область определения (мат.)
Домен поля
таблицы в БД
85. Т.е. это о
Business Domain
Предметной области
и
Business Logic
Бизнес-логики
91. • Даны шаг бегунка в исходном состоянии
и текущий пользователь – «Петров»
Когда для этого шага выполняется действие
«Подтвердить»
Тогда сам шаг переходит в состояние «+»
и автором подтверждения помечается
«Петров»
92. • Даны шаг бегунка в состоянии «?»
и в бегунке есть следующий шаг в исходном
состоянии
и текущий пользователь – «Петров»
Когда для этого шага выполняется действие
«Подтвердить»
Тогда сам шаг переходит в состояние «+»
и автором подтверждения помечается
«Петров»
и следующий шаг бегунка переходит в
состояние «?»
110. vs.
[TestMethod] [TestMethod]
void Test…() void Should…()
{ {
// Arrange // GIVEN
… …
// Action // WHEN
… …
// Assertion // THEN
… …
} }
111. Гипотеза
лингвистической относительности
• aka «гипотеза Сепира-Уорфа»
• существующие в сознании человека
системы понятий, а, следовательно, и
существенные особенности его мышления
определяются тем конкретным языком,
носителем которого этот человек является
112. GUI
Модель
Поведение модели
Аналитик
Тестировщик Разработчик
113. Спасибо за
внимание!
biBIGone@gmail.com
http://www.google.com/profiles/biBIGone