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.
Дело тестера боится: как в опытных руках могут заиграть Java и TestNgIT61
Вячеслав Марков, QA engineer в Weezlabs
Я расскажу о том, как в нашей фирме организовано тестирование бэкенда с помощью тестового фреймворка TestNG и Java. Расскажу о data-driven тестировании и о том, почему его удобно применять. Покажу и опишу разработанную нами структуру типового тестового проекта. Представлю применяемые нами способы сбора и документирования результатов, а так же их анализ в условиях CI.
Solit 2014, Минусы ООП на примере языка PHP, Соловей Василийsolit
Василий Соловей, Солигорск. PHP-разработчик в в «Электронном Солигорске».
«Минусы ООП на примере языка PHP». Development секция. Для разработчиков (начальный и средний уровень).
1. Что есть ООП (легкое повторение уже знакомого)
2. Лучше доверять авторитету мнения, чем мнению авторитета (во всем нужно разбираться основательно, а в ООП тем более)
3. Неизменная скупость в похвалах — верный признак посредственного ума (плюсы ООП)
4. Не все то солнышко, что блестит (основная часть доклада – минусы ООП)
5. Кто владеет информацией, тот владеет ситуацией (пояснение сути доклада:
доклад не принижает и не умоляет достоинств ООП он создан расширить кругозор)
«Начинать никогда не поздно!». Мотивационное выступление. На личном примере, я могу рассказать, что начинать никогда не поздно, и если есть желание – нет повода себе отказывать.
1. Путь в тысячу миль начинается с одного шага (с чего начать)
2. И на верном пути повстречаются распутья (как не сбиться с дороги начав)
3. Кто ты программист? (мой взгляд на программирование)
4. Успех – дитя настойчивости
Cтатический анализ кода (на примере DDD-фреймворка)ngrebnev
Они расскажут как при разработке бизнес-приложений в модели Domain-driven design они предупреждают ошибки программиста с помощью статического анализа кода и доменной модели. А именно: возможности ORM-платформы по статическому анализу, преимущества широкого использования Linq, декларативных ограничений, модель состояний и формальной верификации элементов доменной модели.
Они разберут, в чем заключается удобство разработчика по использованию статического анализа и простота применения механизмов для задания формальных ограничений на модель предметной области. Интеграция средств статического анализа ORM в среду разработки, невозможность игнорирования ошибок, гарантия прохождения всех статических проверок до первого запуска программы. Ограниченные возможности запросов Linq к модели предметной области по сравнению с Linq to Objects и пути их преодоления.
Они расскажут, как обстоят дела с аналогичными механизмами в других ORM-системах и почему они решили реализовать собственную платформу для поддержки разработки в рамках DDD.
«Статический анализ: гордость и предубеждения», Алексей Кузьменко, аналитик И...Mail.ru Group
Анализ кода — один из эффективных подходов к выявлению дефектов на этапе разработки программного обеспечения. Это позволяет избежать тривиальных и не очень ошибок, которые могут приводить к появлению уязвимостей. Существует ряд подходов, применяемых в анализаторах, на основании которых производится анализ, позволяющий снижать риски. Однако возникает ряд предубеждений, ведь не всегда предупреждение анализатора является реальным дефектом, тем более, что не всякий дефект является уязвимостью.
Уменьшение влияния человеческого фактора при разработке бизнес приложенийngrebnev
В этом докладе мы постараемся рассказать о принципах разработки инструментов для написания бизнес-логики, позволяющих сократить количество ошибок. Речь пойдет о нескольких практиках, принятых в отделе технологического развития нашей компании. Принципы будут проиллюстрированы на примере инструментария компании для платформы Microsoft .NET.
Максимум статических проверок. Под статическими проверками мы понимаем проверки времени компиляции. Этот принцип является важным, но, к сожалению, зачастую недооценивается разработчиками инструментария разработки. Проверки времени компиляции могут отлавливать большой спектр ошибок. Есть и другая особенность – это удобство. Ошибки времени исполнения сложнее воспринимаются, труднее найти причину ошибки.
Разнообразие и декларативность проверок. Проверки общего назначения удобно задавать в декларативном виде. При этом сами проверки должен осуществлять фреймворк. За счет уменьшения дублирования и декларативности снижается вероятность ошибок. Проверки должны быть, как техническими, так и уровня доменной модели. Мы будем говорить о проверках уровня доменной модели.
Возможность анализа декларативных проверок. Любые ограничения порождают некоторую модель. Эту модель (проверки) можно формально верифицировать. Вообще, проблема доказательства большинства свойств программы невозможна. Этот вопрос выходит далеко за рамки нашего доклада. Но существует возможность верификации более слабых (менее выразительных моделей).
Во второй части мы обсудим функционал, который мы называем "состояния". Эти "состояния" образуют что-то вроде автомата, или структуру Крипке. Так вот, существуют алгоритмы проверки выполнимости темпоральных логик на таких структурах.
Behavior Driven Development - подход к разработке ПО, основывающийся на ориентации на business value и исполняемых спецификациях, написанных на человеческом языке
“Можно ли перевернуть пирамиду?” – автоматизируем тестирование с меньшим числ...Igor Khrol
Когда мы говорим об автоматизации тестирования, чаще всего вспоминается Selenium, Microsoft Coded UI, QTP и другие аналогичные инструменты. Мы хотим воспроизводить действия ручного тестирования с максимальной точностью, чтобы можно было с уверенностью сказать, что тот или иной тест-скрипт повторяет какую-то часть сложившихся на проекте тестов. Когда же тестов становится чуть больше, то мы обнаруживаем, что наши тесты запускаются долго, работают нестабильно. После чего мы начинаем говорить о параллелизации, виртуализации, четырёхслойной архитектуре фреймворка и прочих жутко интересных вещах… Это всё очень хорошо, но главная цель где-то остаётся в стороне – контроль качества нашего продукта.
В своём докладе я попытаюсь слегка задать направление другой альтернативе: отойти от автотестов через пользовательский интерфейс в сторону более низкоуровневых, которые значительно быстрее и стабильнее. Если вас также волнует “переворачивание” пирамиды автоматизации тестирования, то приглашаю присоединиться к обсуждению этой сложной и важной темы.
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.
Дело тестера боится: как в опытных руках могут заиграть Java и TestNgIT61
Вячеслав Марков, QA engineer в Weezlabs
Я расскажу о том, как в нашей фирме организовано тестирование бэкенда с помощью тестового фреймворка TestNG и Java. Расскажу о data-driven тестировании и о том, почему его удобно применять. Покажу и опишу разработанную нами структуру типового тестового проекта. Представлю применяемые нами способы сбора и документирования результатов, а так же их анализ в условиях CI.
Solit 2014, Минусы ООП на примере языка PHP, Соловей Василийsolit
Василий Соловей, Солигорск. PHP-разработчик в в «Электронном Солигорске».
«Минусы ООП на примере языка PHP». Development секция. Для разработчиков (начальный и средний уровень).
1. Что есть ООП (легкое повторение уже знакомого)
2. Лучше доверять авторитету мнения, чем мнению авторитета (во всем нужно разбираться основательно, а в ООП тем более)
3. Неизменная скупость в похвалах — верный признак посредственного ума (плюсы ООП)
4. Не все то солнышко, что блестит (основная часть доклада – минусы ООП)
5. Кто владеет информацией, тот владеет ситуацией (пояснение сути доклада:
доклад не принижает и не умоляет достоинств ООП он создан расширить кругозор)
«Начинать никогда не поздно!». Мотивационное выступление. На личном примере, я могу рассказать, что начинать никогда не поздно, и если есть желание – нет повода себе отказывать.
1. Путь в тысячу миль начинается с одного шага (с чего начать)
2. И на верном пути повстречаются распутья (как не сбиться с дороги начав)
3. Кто ты программист? (мой взгляд на программирование)
4. Успех – дитя настойчивости
Cтатический анализ кода (на примере DDD-фреймворка)ngrebnev
Они расскажут как при разработке бизнес-приложений в модели Domain-driven design они предупреждают ошибки программиста с помощью статического анализа кода и доменной модели. А именно: возможности ORM-платформы по статическому анализу, преимущества широкого использования Linq, декларативных ограничений, модель состояний и формальной верификации элементов доменной модели.
Они разберут, в чем заключается удобство разработчика по использованию статического анализа и простота применения механизмов для задания формальных ограничений на модель предметной области. Интеграция средств статического анализа ORM в среду разработки, невозможность игнорирования ошибок, гарантия прохождения всех статических проверок до первого запуска программы. Ограниченные возможности запросов Linq к модели предметной области по сравнению с Linq to Objects и пути их преодоления.
Они расскажут, как обстоят дела с аналогичными механизмами в других ORM-системах и почему они решили реализовать собственную платформу для поддержки разработки в рамках DDD.
«Статический анализ: гордость и предубеждения», Алексей Кузьменко, аналитик И...Mail.ru Group
Анализ кода — один из эффективных подходов к выявлению дефектов на этапе разработки программного обеспечения. Это позволяет избежать тривиальных и не очень ошибок, которые могут приводить к появлению уязвимостей. Существует ряд подходов, применяемых в анализаторах, на основании которых производится анализ, позволяющий снижать риски. Однако возникает ряд предубеждений, ведь не всегда предупреждение анализатора является реальным дефектом, тем более, что не всякий дефект является уязвимостью.
Уменьшение влияния человеческого фактора при разработке бизнес приложенийngrebnev
В этом докладе мы постараемся рассказать о принципах разработки инструментов для написания бизнес-логики, позволяющих сократить количество ошибок. Речь пойдет о нескольких практиках, принятых в отделе технологического развития нашей компании. Принципы будут проиллюстрированы на примере инструментария компании для платформы Microsoft .NET.
Максимум статических проверок. Под статическими проверками мы понимаем проверки времени компиляции. Этот принцип является важным, но, к сожалению, зачастую недооценивается разработчиками инструментария разработки. Проверки времени компиляции могут отлавливать большой спектр ошибок. Есть и другая особенность – это удобство. Ошибки времени исполнения сложнее воспринимаются, труднее найти причину ошибки.
Разнообразие и декларативность проверок. Проверки общего назначения удобно задавать в декларативном виде. При этом сами проверки должен осуществлять фреймворк. За счет уменьшения дублирования и декларативности снижается вероятность ошибок. Проверки должны быть, как техническими, так и уровня доменной модели. Мы будем говорить о проверках уровня доменной модели.
Возможность анализа декларативных проверок. Любые ограничения порождают некоторую модель. Эту модель (проверки) можно формально верифицировать. Вообще, проблема доказательства большинства свойств программы невозможна. Этот вопрос выходит далеко за рамки нашего доклада. Но существует возможность верификации более слабых (менее выразительных моделей).
Во второй части мы обсудим функционал, который мы называем "состояния". Эти "состояния" образуют что-то вроде автомата, или структуру Крипке. Так вот, существуют алгоритмы проверки выполнимости темпоральных логик на таких структурах.
Behavior Driven Development - подход к разработке ПО, основывающийся на ориентации на business value и исполняемых спецификациях, написанных на человеческом языке
“Можно ли перевернуть пирамиду?” – автоматизируем тестирование с меньшим числ...Igor Khrol
Когда мы говорим об автоматизации тестирования, чаще всего вспоминается Selenium, Microsoft Coded UI, QTP и другие аналогичные инструменты. Мы хотим воспроизводить действия ручного тестирования с максимальной точностью, чтобы можно было с уверенностью сказать, что тот или иной тест-скрипт повторяет какую-то часть сложившихся на проекте тестов. Когда же тестов становится чуть больше, то мы обнаруживаем, что наши тесты запускаются долго, работают нестабильно. После чего мы начинаем говорить о параллелизации, виртуализации, четырёхслойной архитектуре фреймворка и прочих жутко интересных вещах… Это всё очень хорошо, но главная цель где-то остаётся в стороне – контроль качества нашего продукта.
В своём докладе я попытаюсь слегка задать направление другой альтернативе: отойти от автотестов через пользовательский интерфейс в сторону более низкоуровневых, которые значительно быстрее и стабильнее. Если вас также волнует “переворачивание” пирамиды автоматизации тестирования, то приглашаю присоединиться к обсуждению этой сложной и важной темы.
Читабельные отчеты для автоматизации на C# / Gallio / BDDfyDmytro Zharii
Мой доклад про создание читабельных отчетов для автоматизации тестирования на .NET/C# + Webdriver + Gallio Icarus/MbUnit + BDDfy
Доклад был сделан специально для онлайн конференции Auto ConfeT&QA, прошедшей в октябре 2012 года.
http://confetqa.ru/
======================================
См. также:
Gallio Icarus:
http://gallio.org
BDDfy – фреймворк для БыДиДификации кода :)
Страница проекта на Github:
http://teststack.github.com/TestStack.BDDfy/
Описание на английском:
http://www.mehdi-khalili.com/bddify-in-action/introduction
PHP Meetup
Михайло Бондарчук
— Автор популярного фреймворку для PHP тестування - Codeception
— Веб-розробник PHP/Ruby/JS
— Спікер PHPKonf Стамбул (2015), RSConf Мінськ (2016), J&Beyond Барселони (2016), Голландська PHP Конференція 2016
Презентація про:
— реалізация плюмбусів на PHP
— як писати додатки в складній доменній області
— що таке BDD та як він пов'язаний із тестуванням
This document discusses continuous performance testing (CPT) and introduces the Jagger CPT solution. It provides an overview of why performance testing is important, outlines the principles and goals of CPT, and describes the key parts of the Jagger CPT platform including load generation, metrics collection, test data management, and environment management. It also provides an example customer success story where Jagger was used for continuous performance testing of a large ecommerce site.
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииSQALab
This document provides an overview of the JDI (Java UI test automation framework). It discusses features of JDI including being UI element oriented, providing common UI elements and solutions to common problems. It provides examples of how to write tests using JDI annotations and page object pattern. The document also summarizes benefits of JDI such as reducing test code, improving test clarity, reuse across projects. Finally it outlines new features planned for JDI 2.0 including layout verification, page object generator, integration with Selenium and expanding JDI to other languages like Python.
The document discusses testing of geolocation systems. It provides an overview of geolocation, including definitions and importance. It then outlines the speaker's experience and work testing GIS systems. The rest of the document details approaches to testing geolocation, including simulating calls, checking responses and databases, and verifying accuracy. It also discusses common data formats, projections, tools like PostGIS and QGIS, and potential bugs to watch for like coordinate jumbling. The conclusion emphasizes starting simple, practicing to improve, and for tests to grow with knowledge as geolocation is important for future IT.
7. ... который создал новые языки для разных людей, из-за чего они перестали понимать друг друга, не могли продолжать строительство ...
8. Средство для автоматизированного тестирования Позволяет описывать поведение системы на естественном языке Является основным инструментом в BehaviourDrivenDevelopment (BDD)
10. Опишите поведение системы на естественном языке(Напишите сценарий поведения) Опишите шаги сценария на языке программирования
11. Опишите поведение системы на естественном языке(Напишите сценарий поведения) Опишите шаги сценария на языке программирования Запустите тесты и убедитесь, что они не проходит
12. Опишите поведение системы на естественном языке(Напишите сценарий поведения) Опишите шаги сценария на языке программирования Запустите тесты и убедитесь, что они не проходит Напишите код, который реализует поведение, описанное в тестах
13. Опишите поведение системы на естественном языке(Напишите сценарий поведения) Опишите шаги сценария на языке программирования Запустите тесты и убедитесь, что они не проходит Напишите код, который реализует поведение, описанное в тестах Запустите тесты снова и убедитесь, что некоторые тесты начали проходить
14. Опишите поведение системы на естественном языке(Напишите сценарий поведения) Опишите шаги сценария на языке программирования Запустите тесты и убедитесь, что они не проходит Напишите код, который реализует поведение, описанное в тестах Запустите тесты снова и убедитесь, что некоторые тесты начали проходить Повторите 2-5 шаги, пока все тесты не начнут проходить
15. Опишите поведение системы на естественном языке(Напишите сценарий поведения) Опишите шаги сценария на языке программирования Запустите тесты и убедитесь, что они не проходит Напишите код, который реализует поведение, описанное в тестах Запустите тесты снова и убедитесь, что некоторые тесты начали проходить Повторите 2-5 шаги, пока все тесты не начнут проходить Повторите 1-6 шаги, пока не закончатся деньги у заказчика
17. Функционал Опишите поведение системы на естественном языке # language: ru Функционал: Сложение чисел Чтобы не складывать в уме Все, у кого с этим туго Хотят автоматическое сложение целых чисел Сценарий: Сложение двух целых чисел Допустим я ввожу число 50 И затем ввожу число 70 Если я нажимаю "+" То результатом должно быть число 120
18. Функционал Опишите шаги сценария на языке программирования Допустим /ввожу число (+)/ do|число| calc.pushчисло.to_i end Если /нажимаю "(.*)"/ do|операция| calc.sendоперация End То /результатом должно быть число (+)/ do|результат| calc.result.should==результат.to_f End
20. Gherkin "ru": name: Russian native: русский feature: Функция|Функционал|Свойство background: Предыстория|Контекст scenario: Сценарий scenario_outline: Структура сценария examples: Примеры given: "*|Допустим|Дано|Пусть" when: "*|Если|Когда" then: "*|То|Тогда" and: "*|И|К тому же" but: "*|Но|А"
21. Формат Feature: Title In order to [Business Value] As a [Role] I want to [Some action] Scenario: Title Given [Context] When [Action] Then [Outcome]
22. Формат Scenario: Title Given[Context] And[Context] When [Action] And [Action] Then[Outcome] But[Outcome]
30. Ошибки и заблуждения Хлопотно (я могу тестировать Unit test, Rspec … ) Требования быстро меняются Оформление часто меняется Описывать поведение должен заказчик Cucumber == BDD Вы действительно используете Cucumber.(Chicken test)
32. Одними из самых неприятных ошибок, являются ошибки неверной реализации требований или даже отсутствие должной функциональности. Сложность этих ошибок заключается в том, что только заказчик может найти их. Разработка программ через тестирование поведения (BDD) является продолжением идеи TDD Главное отличие BDD и TDD заключается в том, что тестируется поведение системы, а не внутренне устройство классов и код. Главной особенностью Cucumber является возможность описания поведения системы на естественном языке. Вопросы?