Алексей Ильенко "In real-time with Apache Kafka"Fwdays- will talk about Apache Kafka;
- will learn how to not fear Apache Kafka, as a fire;
- will show how it can unfold in three clicks and use in production;
- how to build a Lua query logging system and what PHP is here for.
Egor Fedorov "Behavior-driven development in Python"FwdaysThe goal of the BDD technique is to establish successful communication between customers, business analysts, programmers, and testers for the whole life of the project.
That is why a language was created, in which the expected behavior of the application is described in simple text form, and then through the BDD framework, the text is translated into program code, which could already be used in testing the software product.
Where BDD is applied, software requirements turn into living code, and tests instead of a programming language are written in simple human language.
In this talk, using the automation of website testing as an example, the Behave framework for Python will be shown.
The talk will be about:
writing bdd files;
performing them in behave;
running BDD as tests in pytest;
integrating everything into the CI pipeline.
XpDays - Automated testing of responsive design (GalenFramework)Alex FruzenshteinThis document discusses automated testing of responsive web design using the Galen Framework. It provides an overview of Galen and how it allows writing specifications to test layouts across different screen sizes and devices. Key aspects covered include the Galen specification language using tags to target different devices, the test suite syntax, and examples of integrating Galen with Java tests using Maven, TestNG, and custom reporting.
The Responsible Developer - XP days Ukraine 2014TSundbergDevelopers are the translators between ideas and code. They translate ideas about functionality to code so the end users can benefit from a usable program. This translation has to be done in a careful and responsible way. It should be done by a responsible developer.
What is a responsible developer then?
It is a developer that writes clean, testable and maintainable code. A developer who can explain and describe his work. Someone that knows that he grows by helping his fellow developers and never settles for second best.
I will discuss the properties of a responsible developer and suggest ways you can improve to become a responsible developer.ccc
XP Days Ukraine 2014 - Refactoring legacy codeDmytro MindraEvery 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.
Extreme Programming practices for your teamPawel LipinskiThis document discusses Extreme Programming (XP) practices for software development teams. It begins by introducing Paweł Lipiński and his background in software development. It then discusses several key XP practices in more detail, including having short iterations of less than 4 weeks, testing features at the end of each iteration, prioritizing work based on business value, maintaining burn down charts, and having no project managers disrupting the team. Further sections provide more context on practices like test-driven development, pair programming, collective code ownership, continuous integration, refactoring, and having a 40-hour work week. The document emphasizes that XP is about creating fun, high-quality, efficient teams through these agile practices.
Юлия Викторова; Александр Тарасов. DevOps без булшита.ScrumTrekВ своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
Виды QA: Всё что вы не знали и боялись спроститьGoIT19.02.2015 состоялось очередное событие, посвященное тематике Тестирования ПО.
Встреча помогла участникам
• разобраться в видах QA;
• получить информацию о «подводных» камнях каждого из направлений;
• узнать о специфике работы тестеровщика;
• перенять опыт тестировщиков с многолетним стажем;
• узнать о нововведениях в мире QA;
• выбрать свой путь развития в тестировании.
Спикерами выступили:
Александр Майданюк – QA Lead, Manager, QA Consultant и Trainer. Занимает позицию Head
of Quality Assurance Solution в Ciklum. Эксперт и судья QA секции чемпионатов UA Web
Challenge. Соучредитель Киевского Клуба тестировщика QA Club.
Николай Ковш – QA Engineer в Ciklum. Является ярким примером свитчера - человека,
который сменил область деятельности. Со-организатор ивентов в QA Club - самом большом
киевском сообществе тестировщиков. Николай расскажет, почему тестировщику важно
научиться программировать.
Марина Шевченко – Mobile QA Engineer в Ciklum. QA з досвідом тестування веб, дестопних
та мобільних додатків. Співорганізатор заходів в QA Club – найбільшій київській спільності
тестувальників.
Python-технология которую легко продавать!Aleksey NakorenkoЭта презентация расскажет простым языком о том, что за технология Python, какие у нее сильные и слабые стороны, кто ее использует и для каких проектов она подходит.
Видеозвонки и шаринг экрана в мобильном приложенииVoximplantАлександр Сербул (Битрикс24)
Видеозвонки и шаринг экрана в мобильном приложении
О спикере
Отвечает за контроль качества интеграции и внедрений компании «1С-Битрикс» и выступает в роли архитектора и разработчика проектов, связанных с высокой нагрузкой и отказоустойчивостью («Битрикс24»). Окончил кафедру «Автоматизация и информатика» Донского государственного технического университета. До 2002 года работал советником в администрации Президента России по Южному федеральному округу, разработал официальный портал Юго-Западного банка Сбербанка России. Увлекается философией Unix, гибкими методологиями разработки ПО, системным анализом и проектированием.
О докладе
Рассмотрим технологию реализации видеозвонков HD-качества и шаринга экрана для мобильных приложений на платформах Android и Apple. Подробно остановимся на подводных камнях и доработках ядра WebRTC.
INTERCOM 2016, Москва
Сайт конференции: https://intercomconf.com/
Автоматизированный подход к локализации корпоративных приложенийSoftengi Доклад Глеба Криштова, члена команды LocServ в Softengi, на конференции для специалистов по локализации ПО Loc Kit 2014.
Доклад ответит на вопрос - как локализовать приложение-"монстр" с миллионами строк кода за рекордный срок в 6 месяцев, сократив при этом расходы на локализацию в более чем три раза?
Глеб в докладе раскрывает секреты создания командой LocServ собственного решения Localization Studio, с какими трудностями столкнулась команда до и во время создания решения и какие проблемы можно решить с помощью LocStudio.
Rempl – крутая платформа для крутых инструментовRoman DvornovФронтенд усложняется с каждым днем, и уже не представить жизнь разработчика без инструментов. Инструментов становится все больше, но нельзя сказать, что их достаточно. Если у вас собственный стек или технологическое решение, вам рано или поздно потребуется сделать свой инструмент. Это не так просто! Особенно если вы захотите интегрировать его интерфейс в браузерные Developer Tools, IDE, редакторы или открыть их на другом устройстве. Добавьте сюда проблему версионирования и другие сложности, и вам покажется, что задача неподъемная.
Но есть хорошая новость! Большинство из этих проблем решает Rempl — платформа для создания и использования удаленных инструментов (на самом деле не только инструментов). Сделаем небольшой обзор Rempl: что это, зачем нужно, какие проблемы решает. А также посмотрим примеры готовых решений, построенных на Rempl.
CodeFest, Новосибирск, 2017
Open Source Testing Framework: real project example and best practicesAliaksandr IkhelisSummary: Presentation on open source testing frameworks (improved version, more focus on real project example) at Software Engineering Forum 2009 (SEF-1) conference by Aliaksandr Ikhelis. Sponte framework developer and owner is Stanislaw Wozniak, Expedia Limited, UK. Sponte project homepage: http://rubyforge.org/projects/sponte/; http://github.com/swozniak/sponte/tree/master
Breaking logsIlya Sergeevݺߣs from my talk about logging system with rsyslog, kafka, logstash, elasticsearch and introduction to real-time analytics with kafka streams
Читабельные отчеты для автоматизации на 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
Wild microservices and imaginary DevOpsКирилл ТолкачёвСегодня очень часто можно услышать множество модный словечек, но даже среди них девопс и микросервисы будоражат умы людей как то по особенному.
Для обычного инженера DevOps и Микросервисы – это всего лишь маркетинговая профанация. Куда важнее “держать DevOps в своих руках” и уметь им пользоваться. Хочется понять где заканчиваются наши и чужие фантазии, где начинаются реально полезные практики, какие инструменты нам помогут и какие фундаментальные принципы помогут увеличить профит от используемых практик и инструментов.
Доклад в первую очередь про внедрение различных технологий, инструментов и методологий в большой организации. Поделюсь проблемами с которыми мы столкнулись при внедрении различных принципов и технологий, расскажу о решениях и выработанных принципах масштабирования процессов/инструментов.
Сегодня наш лозунг будет “DevOps в руках а не в головах”. Но то что в головах всё же важно, хоть это и совсем другая история.
Разработка надежных параллельных, распределенных приложений: быстро и дешевоDotNetConfПо материалам конференции .NET разработчиков http://dotnetconf.ru/materialy/parallel
Что вас ждет на пути реализации Soa (Битрикс отступает)Василий СавуновРассказ о том, как проект banki.ru принял решение убегать от Битрикса через SOA, а так же о том, как мы бежали к SOA, и что получилось в итоге
А нам-то зачем функциональное программирование?Vagif AbilovThe document discusses functional programming and provides examples of functional code written in F# for Conway's Game of Life, including defining neighbors, determining if a cell is alive, surviving cells, reproducing cells, and calculating the next generation. Functions are defined recursively and patterns are matched. Parallel processing is demonstrated by filtering lists in parallel.
Cross-platform Mobile Development using Portable Class LibrariesVagif AbilovAn introduction to developing iOS, Android and Windows Phone applications using Xamarin tools and .NET portable class libraries.
More Related Content
Similar to Путь к чистому и компактному коду исполняемых спецификаций (20)
Юлия Викторова; Александр Тарасов. DevOps без булшита.ScrumTrekВ своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
Виды QA: Всё что вы не знали и боялись спроститьGoIT19.02.2015 состоялось очередное событие, посвященное тематике Тестирования ПО.
Встреча помогла участникам
• разобраться в видах QA;
• получить информацию о «подводных» камнях каждого из направлений;
• узнать о специфике работы тестеровщика;
• перенять опыт тестировщиков с многолетним стажем;
• узнать о нововведениях в мире QA;
• выбрать свой путь развития в тестировании.
Спикерами выступили:
Александр Майданюк – QA Lead, Manager, QA Consultant и Trainer. Занимает позицию Head
of Quality Assurance Solution в Ciklum. Эксперт и судья QA секции чемпионатов UA Web
Challenge. Соучредитель Киевского Клуба тестировщика QA Club.
Николай Ковш – QA Engineer в Ciklum. Является ярким примером свитчера - человека,
который сменил область деятельности. Со-организатор ивентов в QA Club - самом большом
киевском сообществе тестировщиков. Николай расскажет, почему тестировщику важно
научиться программировать.
Марина Шевченко – Mobile QA Engineer в Ciklum. QA з досвідом тестування веб, дестопних
та мобільних додатків. Співорганізатор заходів в QA Club – найбільшій київській спільності
тестувальників.
Python-технология которую легко продавать!Aleksey NakorenkoЭта презентация расскажет простым языком о том, что за технология Python, какие у нее сильные и слабые стороны, кто ее использует и для каких проектов она подходит.
Видеозвонки и шаринг экрана в мобильном приложенииVoximplantАлександр Сербул (Битрикс24)
Видеозвонки и шаринг экрана в мобильном приложении
О спикере
Отвечает за контроль качества интеграции и внедрений компании «1С-Битрикс» и выступает в роли архитектора и разработчика проектов, связанных с высокой нагрузкой и отказоустойчивостью («Битрикс24»). Окончил кафедру «Автоматизация и информатика» Донского государственного технического университета. До 2002 года работал советником в администрации Президента России по Южному федеральному округу, разработал официальный портал Юго-Западного банка Сбербанка России. Увлекается философией Unix, гибкими методологиями разработки ПО, системным анализом и проектированием.
О докладе
Рассмотрим технологию реализации видеозвонков HD-качества и шаринга экрана для мобильных приложений на платформах Android и Apple. Подробно остановимся на подводных камнях и доработках ядра WebRTC.
INTERCOM 2016, Москва
Сайт конференции: https://intercomconf.com/
Автоматизированный подход к локализации корпоративных приложенийSoftengi Доклад Глеба Криштова, члена команды LocServ в Softengi, на конференции для специалистов по локализации ПО Loc Kit 2014.
Доклад ответит на вопрос - как локализовать приложение-"монстр" с миллионами строк кода за рекордный срок в 6 месяцев, сократив при этом расходы на локализацию в более чем три раза?
Глеб в докладе раскрывает секреты создания командой LocServ собственного решения Localization Studio, с какими трудностями столкнулась команда до и во время создания решения и какие проблемы можно решить с помощью LocStudio.
Rempl – крутая платформа для крутых инструментовRoman DvornovФронтенд усложняется с каждым днем, и уже не представить жизнь разработчика без инструментов. Инструментов становится все больше, но нельзя сказать, что их достаточно. Если у вас собственный стек или технологическое решение, вам рано или поздно потребуется сделать свой инструмент. Это не так просто! Особенно если вы захотите интегрировать его интерфейс в браузерные Developer Tools, IDE, редакторы или открыть их на другом устройстве. Добавьте сюда проблему версионирования и другие сложности, и вам покажется, что задача неподъемная.
Но есть хорошая новость! Большинство из этих проблем решает Rempl — платформа для создания и использования удаленных инструментов (на самом деле не только инструментов). Сделаем небольшой обзор Rempl: что это, зачем нужно, какие проблемы решает. А также посмотрим примеры готовых решений, построенных на Rempl.
CodeFest, Новосибирск, 2017
Open Source Testing Framework: real project example and best practicesAliaksandr IkhelisSummary: Presentation on open source testing frameworks (improved version, more focus on real project example) at Software Engineering Forum 2009 (SEF-1) conference by Aliaksandr Ikhelis. Sponte framework developer and owner is Stanislaw Wozniak, Expedia Limited, UK. Sponte project homepage: http://rubyforge.org/projects/sponte/; http://github.com/swozniak/sponte/tree/master
Breaking logsIlya Sergeevݺߣs from my talk about logging system with rsyslog, kafka, logstash, elasticsearch and introduction to real-time analytics with kafka streams
Читабельные отчеты для автоматизации на 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
Wild microservices and imaginary DevOpsКирилл ТолкачёвСегодня очень часто можно услышать множество модный словечек, но даже среди них девопс и микросервисы будоражат умы людей как то по особенному.
Для обычного инженера DevOps и Микросервисы – это всего лишь маркетинговая профанация. Куда важнее “держать DevOps в своих руках” и уметь им пользоваться. Хочется понять где заканчиваются наши и чужие фантазии, где начинаются реально полезные практики, какие инструменты нам помогут и какие фундаментальные принципы помогут увеличить профит от используемых практик и инструментов.
Доклад в первую очередь про внедрение различных технологий, инструментов и методологий в большой организации. Поделюсь проблемами с которыми мы столкнулись при внедрении различных принципов и технологий, расскажу о решениях и выработанных принципах масштабирования процессов/инструментов.
Сегодня наш лозунг будет “DevOps в руках а не в головах”. Но то что в головах всё же важно, хоть это и совсем другая история.
Разработка надежных параллельных, распределенных приложений: быстро и дешевоDotNetConfПо материалам конференции .NET разработчиков http://dotnetconf.ru/materialy/parallel
Что вас ждет на пути реализации Soa (Битрикс отступает)Василий СавуновРассказ о том, как проект banki.ru принял решение убегать от Битрикса через SOA, а так же о том, как мы бежали к SOA, и что получилось в итоге
А нам-то зачем функциональное программирование?Vagif AbilovThe document discusses functional programming and provides examples of functional code written in F# for Conway's Game of Life, including defining neighbors, determining if a cell is alive, surviving cells, reproducing cells, and calculating the next generation. Functions are defined recursively and patterns are matched. Parallel processing is demonstrated by filtering lists in parallel.
Cross-platform Mobile Development using Portable Class LibrariesVagif AbilovAn introduction to developing iOS, Android and Windows Phone applications using Xamarin tools and .NET portable class libraries.
Staying Close to Experts with Executable SpecificationsVagif AbilovThe document discusses using executable specifications to capture expert knowledge for the NRK media player project. Specifications were written using Gherkin and the SpecFlow framework to describe requirements. This allowed developers to work closely with domain experts and validate requirements through automated tests. Lessons learned include starting with acceptance criteria before end-to-end testing and using specifications as a communication tool between technical teams.
SOLID Programming with Portable Class LibrariesVagif AbilovDevelopers often don't pay attention to code portability until they need to target multiple platforms. However, large amount of non-portable code often hints about violation of clean code principles, so it is worth investigating which part of the source code base are platform-specific and for what reasons.
In this session we will give an overview of portable class libraries, show how to extract PCL components from a real-world application and go through typical challenges that are faced when writing portable code. We will present the original tool that analyzes assemblies for portability compliance and can be used as a guard to prevent mixing business logic with infrastructure-specific functionality. Finally we will demonstrate how PCLs help targeting platforms such as Windows Store, Android and iOS.
Typed? Dynamic? Both! Cross-platform DSLs in C#Vagif AbilovIn this session we will demonstrate how to design DSLs in C# that expose both typed and dynamic API. The advantage of such hybrid APIs is that they can take advantage of dynamic C# features, but offer a fallback for .NET platforms that lack DLR support and developers not willing to abandon the convenience of compile-time code validation. We will show how to ensure code sharing between typed and dynamic versions, and how to package and publish library files so they can be consumed on variety of .NET platforms, including iOS and Android.
Practical ODataVagif AbilovThe outline of the presentation (presented at NDC 2011, Oslo, Norway):
- Short summary of OData evolution and current state
- Quick presentation of tools used to build and test OData services and clients (Visual Studio, LinqPad, Fiddler)
- Definition of canonical REST service, conformance of DataService-based implementation
- Updateable OData services
- Sharing single conceptual data model between databases from different vendors
- OData services without Entity Framework (NHibernate, custom data provider)
- Practical tips (logging, WCF binding, deployment)
F# in Action: Playing Functional Conway's Game of LifeVagif AbilovF# in action: playing functional Conway's game of life
John Conway's game of life has become a playground for programmers using different languages and platforms. It inspired many coding dojos and code retreats because it touches various aspects of development from component design to performance testing.
In this session we are going to take functional approach and play different variations of Conway's game of life using F#. The session starts with presentation of a traditional game implementation in C#, so we can later compare it with F# versions. Switching to F#, we will first write an implementation for a standard two-dimensional board, and then extend it to support asynchronous workflows, parallel tasks and even boards of arbitrary dimensions. Each implementation will be complemented with a set of tests using FsUnit framework, and graphical presentation of results will use Microsoft Chart Controls.
Executable Specifications in ActionVagif AbilovExecutable specifications in action: building mobile bank
In this workshop we exercise a combination of BDD and TDD methods by implementing a small mobile bank solution. We start from user stories and scenarios turning them into a set of executable specifications written in Gherkin language. Then we proceed with implementation of scenario steps followed by writing production code in a test-driven manner. By the end of the workshop we have an in-memory bank communicating with its customers using simulated SMS messages.
3. План презентации
Насколько хорош код тестов?
Или насколько плох?
Тестировщики как полноправные граждане
10 шагов, ведущих к улучшению кода тестов
Примеры и случаи из практики
5. Насколько хорош код тестов?
Или насколько плох?
Какое качество вы ожидаете от кода тестов?
Уступает код тестов или превосходит качество кода
продукта? Или же их качество на одном уровне?
Как долго живет код тестов?
Столько же, сколько код продукта? Больше? Меньше?
6. Тестировщики как полноправные граждане
Все, что выпускается, публикуется или отсылается
заказчику, обычно является предметом более строгих
требований, чем программы для внутреннего
использования
Внутренности продукта подчиняются внешним
требованиям, внутренности тестов подчиняются
внутренним требованиям
7. Тестировщики как полноправные граждане
Руководство зачастую относится менее строго к
выбору тестерами средств и языков
программирования
Нет причин, по которым тестировщики не должны
обращать в свою пользу либерализм руководства -
тестировщики ПО обладают большими
возможностями адаптирования новых методов и
технологий
8. Путь к чистому и компактному коду
исполняемых спецификаций
1. Преодолевайте барьеры понимания
2. Приемочные тесты как исполняемые спецификации
3. Дайте актерам действовать в сценариях
4. Спустите КАК на нижние уровни
5. Уменьшайте количество уровней трансляции
9. Путь к чистому и компактному коду
исполняемых спецификаций
6. Пользуйтесь исследовательскими скриптами
7. Группируйте код автоматизации тестов в библиотеки
8. От DRY к DRO - следите за сообществами
9. Пробуйте динамические языки
10. Восстанавливайте лишь существенные хранимые
состояния
10. 1. Преодолевайте барьеры понимания
«BDD is a 2nd 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»
Дэн Норт
11. 1. Преодолевайте барьеры понимания
«Для метода BDD тестирование не является
первичным. Вы получите из него тесты, но обычно
потребуется и дополнительное тестирование. Куда
важнее в этом разработка и понимание того, что
должно стать конечным результатом.» – Лиз Кеог
«Обсуждение является гораздо более важным, чем
инструментальные средства BDD» – Лиз Кеог
12. 2. Приемочные тесты как исполняемые
спецификации (executable specifications)
Scenario: The answer with the highest vote gets to the
top
Given there is a question «What is your favourite
color» with the answers
| Answer | Vote |
| Red | 1 |
| Green | 1 |
When I upvote the answer «Green»
Then the answer «Green» should be on the top
13. 2. Приемочные тесты как исполняемые
спецификации (executable specifications)
Сценарий: Ответ с наибольшим количеством голосов
выдается первым
Дано вопрос «Какой ваш любимый цвет?» с ответами
| Ответ | Голосов |
| Красный | 1 |
| Зеленый | 1 |
Если я отдам голос за «Зеленый»
То ответ «Зеленый» должен стать первым в списке
ответов
14. Преимущества исполняемых спецификаций
Пишутся на естественном языке (и своем языке)
Формализуют требования к продукту
Интегрируются в ежедневные билды
Живая документация
Показывают прогресс разработки
Функциональное покрытие
18. 3. Дайте действующим лицам действовать в
сценариях
Feature: Pay bill
Background: Prices
Given the following operations are available:
| operation | price |
| routine check up | 10 |
| shots | 5 |
Scenario: Dave pays for Fluffy
Given Dave owns a pet Fluffy
And Dave brings Fluffy into the clinic for the following operations:
| routine check up |
| shots |
When the veterinarian charges Dave for the visit
And Dave pays cash
Then Dave is given a receipt which looks like this:
Operations:
$10 (routine check up)
$5 (shots)
Total to pay: $15 (из блога Мэта Уинна)
19. 3. Дайте действующим лицам действовать в
сценариях
Feature: Pay bill
Background: Prices
Given the following operations are available:
| operation | price |
| routine check up | 10 |
| shots | 5 |
20. 3. Дайте действующим лицам действовать в
сценариях
Scenario: Dave pays for Fluffy
Given Dave owns a pet Fluffy
And Dave brings Fluffy into the clinic for the following
operations:
| routine check up |
| shots |
When the veterinarian charges Dave for the visit
And Dave pays cash
Then Dave is given a receipt which looks like this:
Operations:
$10 (routine check up)
$5 (shots)
Total to pay: $15
22. Обновление результатов норвежских
парламентских выборов
Scenario: Received report is saved and notification message is
enqueued
Given table RP07 doesn’t contain reports for 46010000
And notification queue is empty
When receival service receives report RP07 with data
| Element | Value |
| dateCreated | 2013-05-01T10:01:02 |
| identifier | 46010000 |
| mandates | Ap=6;H=5;V=4 |
Then receival service should return OK
And table RP07 should contain report for 46010000
And notification queue should contain message
| Code | Identifier | Mandates |
| RP07 | 46010000 | Ap=6;H=5;V=4 |
(пример 1)
23. Обновление результатов норвежских
парламентских выборов
When receival service receives report RP07 with data
| Element | Value |
| dateCreated | 2013-05-01T10:01:02 |
| identifier | 46010000 |
| mandates | Ap=6;H=5;V=4 |
Then receival service should return OK
And table RP07 should contain report for 46010000
And notification queue should contain message
| Code | Identifier | Mandates |
| RP07 | 46010000 | Ap=6;H=5;V=4 |
(пример 1)
24. Переработанный сценарий
Scenario: Parliament overview is updated shortly upon the report
receival
Given I see following Parliament party mandates overview
| Party | Mandates |
| Ap | 3 |
| H | 2 |
| V | 1 |
When receival service receives report RP07 with data
| Party | Mandates |
| Ap | 6 |
| H | 5 |
| V | 4 |
And I wait 10 seconds
Then I should see following Parliament party mandates overview
| Party | Mandates |
| Ap | 6 |
| H | 5 |
| V | 4 |
25. 4. «Спустите КАК на нижние уровни»
Цитата из доклада Себа Роуза и Мэтта Уинна
Гойко Аджич определил три уровня автоматизации тестов интерфейса
пользователя:
Бизнес-правила
Интерфейс пользователя / рабочий процесс
Технический
27. 5. Уменьшайте количество уровней трансляции
«Сценарии BDD транслируют пользовательские
сущности в системные.
Чем больше работы
производится в этих сценариях,
тем больше вносится искажений в систему.»
@richarddalton
28. В поисках наиболее эффективного языка для
сценариев
Scenario: Refunded items should be returned to stock
Given a customer buys a black jumper
And I have 3 black jumpers left in stock
When he returns the jumper for a refund
Then I should have 4 black jumpers in stock
30. 6. Пользуйтесь исследовательскими
скриптами
Не бросайтесь писать библиотеку автоматизации
тестов, пока не исследуете систему
Поищите инструменты REPL для языка ваших тестов
Исследуйте систему из скриптов
Воспользуйтесь результатами исследований для
написания автоматизированных тестов
Помните, что у ручных скриптов и
автоматизированных тестов различные контексты, и
обычно они не взаимозаменяемы
32. 7. Группируйте код автоматизации тестов в
библиотеки
Если вы напрямую вызываете интерфейс WebDriver в
ваших тестах, ваши тесты написаны неверно (Саймон
Стюарт)
Tests Tests
UI
Automatio
n
API
UI
33. 8. От DRY к DRO – следите за сообществами
DRY – Don’t repeat yourself
DRO – Don’t repeat others
Различные (и бесплатные!) библиотеки уже
удовлетворили большинство ваших нужд в
форматировании, конвертировании и передачи
данных
Генерация псевдослучайных данных
Конвертация таблиц сценариев
Сравнение содержимого таблиц с содержимым баз данных
Перевод DTO в динамические объекты
34. Пример: проверка данных
ввода пользователя
Scenario: Validate users
Given the following users exists in the database:
| Name | Birth date | Length in meters
|
| John | 1940-10-09 | 1.80 |
| Paul | 1942-06-18 | 1.80
|
| George | 1943-02-25 | 1.77 |
| Ringo | 1940-07-07 | 1.68 |
Then the following users must exist in the database:
| John | 1940-10-09 | 1.80 |
| Paul | 1942-06-18 | 1.80
|
| George | 1943-02-25 | 1.77 |
| Ringo | 1940-07-07 | 1.68 |
(Примеры 9-12)
35. 9. Пробуйте динамические языки
Меньше церемоний – больше действий
Доступ к базам данных без необходимости создания
промежуточных классов
Доступ к веб-сервисам без необходимости импорта
файлов WSDL
Нет нужды в объектах передачи данных (DTO)
(Примеры 13-15)
36. 10. Восстанавливайте лишь существенные
хранимые состояния
Тест не должен рассчитывать на определенное хранимое
состояние
После завершения теста не нужно восстанавливать
первоначальное хранимое состояние
Не тратьте время на сложные процедуры удаления
взаимосвязанных данных
Просто отодвиньте в сторону данные, которые мешают
исполнению теста
(Примеры 16-17)
37. Повторим еще раз
Преодолевайте барьеры понимания
Пользуйтесь исполняемыми спецификациями
Дайте действующим лицам действовать в сценариях
Спустите КАК на нижние уровни
Уменьшайте количество уровней трансляции
Пользуйтесь исследовательскими скриптами
Группируйте код автоматизации тестов в библиотеки
От DRY к DRO - следите за сообществами
Пробуйте динамические языки
Восстанавливайте лишь существенные хранимые
состояния