Anton semenchenko. Comaqa Spring 2018. Nine circles of hell. Antipatterns in UI-automation.

9 кругов Ада: антипаттерны UI-
Автоматизации

План беседы
1. Инкапсуляция – как основной единственный  принцип ООП
2. Инкапсуляция2  – как эффективный способ «классификации»
Design Patterns (в том числе «процессных» )
3. Рефакторинг по Фаулеру и Кириевски – как критерий перехода
4. Минимальный полный спектр теоретической информации

План беседы
5. Алгоритм best practices + сквозная нумерация
6. Страстный призыв «Думай»
7. «Горячая» проверенная временем метафора
8. Новый взгляд на Гемификацию
9. Символ 
10. Список видео аудио литературы

Условная категоризация
1. Концептуальные
2. Процессные Организационные
3. Уровня взаимодействия с бизнесом
4. Уровня Архитектуры
5. Уровня Дизайна
6. Человеческий Капитал
7. Гибридные

Условная категоризация - «человеческий
фактор»
1. Концептуальные
2. Процессные Организационные
3. Уровня взаимодействия с бизнесом
4. Человеческий Капитал
5. Гибридные

Условная категоризация – тех.
составляющая
4. Уровня Архитектуры
5. Уровня Дизайна

1. Page Objects – encapsulates the way of identification and logical grouping of widgets.
2. Page Object == Logical Page
3. Page Object != Physical Page
Page Object – just to “refresh”

Page Object – “example” 

1. Let’s compare:
• Photo
• Share – looks like parallelism (easy parallelism).
• Video
• Share – looks like parallelism (not trivial parallelism).
State-less or state-full solution?

1. How easy transform solution from “single” to “multi” threading (to decrease “QA Automation
Windows”)
• State-less – like share a photo
• Just 5 minutes of work.
• State-full – like share a video
• Not trivial task, could be a night mare.
2. Summary
• prefer state-less solutions to state-full solutions in mooooost cases;
• before start implementation a state-full solution, please, take a break for a minute, and re-thing everything
again, possibly you can find a proper state-less solution.
State-less or state-full solution?

1. Static class
• could be implemented as a state-less solution easily
2. Object
• State-full solution in 99,99% cases
3. Summary
• prefer static class based solutions (state-less) to object based (state-full) in mooooost cases;
• before start implementation based on objects, please, take a break for a minute, and re-thing everything
again, possibly you can find a proper solution based on static classes.
Object or static class State-full or state-less solution?

1. Too complicated business logic due to Domain
2. Too complicated business logic due to System size (thousands test-cases)
3. Too many “contexts”
• Browser versions
• Environments
• Customers with a tiny nuances of functionality
• Platforms (cross-browser Web plus cross-platform Mobile)
• Combination 
4. Combination 
Page Objects – state-full, general case

1. Web UI that behaves like a Wizard
2. Web UI in combination with Mobile in one use case
3. Internet of Things (in most cases)
4. More then 1 page during 1 test (for example several portals or several instances of one portal to
implement one “business use case”):
• Really seldom;
• Looks like integration tests (in most cases):
• Std solution- some type of “Unit” Tests or “White Box” Testing (terminology question).
5. Many others “special cases”
Page Objects – state-full, special cases

How to select a proper PO implementation?

1. 30 Physical Pages
2. Standard Header, footer and search functionality for all physical pages
3. Each Physical Page consists of
• Header – H
• Footer – F
• Search – S
• Some functionality, specific for the Page – U (unique)
Hypothetical project context – to compare

1. 33 Static Page Objects = Logical Pages
2. 0 explicit and 30 implicit Physical Pages
3. Just share 33 Static Page Objects between 30 implicit Physical Pages
• For example, Header Static Page Object (static class) is used in test cases for all 30 Physical Page Objects
4. Complexity – just 33 static state-less entities (plus limitations due to state-less solutions)
Compare complexity – Static Page Object based

1. 33 Dynamic Page Objects = Logical Pages
2. It depends on implementation (one of the ways):
• 0 explicit and 30 implicit Physical Pages
• implicit Physical Page implements on Action layer (limitations example)
• Action for Physical Page aggregates all necessary Dynamic Logical Pages
• Physical Pages are implemented in a next way: create all necessary instances of logical pages, aggregate in some way,
use Action layer as a point of aggregation in most cases, free resources
Compare complexity – Dynamic Page Object based (option 1)

1. 120 objects (min), each with some state, dynamically created and frees to implement necessary
behavior - to implement 30 implicit Physical Pages
2. Complexity – 120 dynamic, state-full entities min (plus some limitations due to state-full solution
implementation nuances)

1. 33 Dynamic Page Objects = Logical Pages
2. It depends on implementation (another way):
• 30 explicit Physical Pages
• Multiple Interface inheritance
• Combine Page Objects and Actions layer (at least low level actions, in most cases)
• Action-Physical Page (low level actions, sometimes “business” actions or both plus limitations example)
• Implements all Logical Pages interfaces using aggregation and “delegation”
• Aggregate all Dynamic Logical Page Objects
• Create and frees resources (Dynamic Logical Page Objects)

1. 150 objects, each with some state, dynamically created and frees to implement necessary behavior -
to implement 30 explicit Physical Pages
2. Complexity – 150 dynamic, state-full not trivial entities with a multiple interface inheritance (plus
some limitations due to state-full solution implementation nuances)

1. Can be used together with next Design Patterns Approaches
• Action (both static – preferable and dynamic)
• Key-word driven
• DSL – external only
• BDD – partially, it depends on exact BDD engine implementation limitations
2. Can’t be used together with next Design Patterns
• Factory
• Flow (Fluent Interface)
• Navigator (for Web)
Compare “tech” limitations - Static Page Object based

1. No limitations, but …
• For example, in most cases it’s hard to isolate Action and Page Objects layers
Compare “tech” limitations - Dynamic Page Object based

1. (-) Too complicated business logic due to Domain
2. (-) Too complicated business logic due to System size (thousands test-cases)
3. (-) Too many “contexts”
• Environments
• Combination 
4. (-) Combination 
Compare “business” limitations - Static

1. State-less approach - you have a conditional that chooses different behavior depending on …
2. Solution to simplify the project – refactoring “Replace Conditional with Polymorphism”
3. Polymorphism = object = State-full approach
Rationale “business” limitations – Static (Transformation)

1. “From Refactoring to Patterns”
• There is a set of specific Design Patterns
2. The trickiest part – find a balance for your project now and update point of balance in time
Rationale “business” limitations – Static (Balance)

1. (-) Relatively simple business logic due to Domain
2. (-) Relatively simple business logic due to System size (hundreds test-cases)
3. (-) Not so many “contexts”
• Environments
Compare “business” limitations - Dynamic

1. State-full approach - you have a set of objects classes, which developed, possibly, using several
Design Patterns to implement necessary functionality – to choose different behavior depending on …
2. Solution to simplify the project – refactoring “Replace Polymorphism with Conditional”
3. Polymorphism ~= object ~= State-full approach
4. No Polymorphism ~= no objects ~= State-less approach
Rationale “business” limitations – Dynamic (Transformation)

1. “From Patterns to refactoring”
• There is no need to use a set of specific Design Patterns
2. The trickiest part – find a balance for your project now and update point of balance in time
Rationale “business” limitations – Dynamic (Balance)

Find and “update” a balance for your own project

1. Ask yourself "how can I hide some details from the rest of the software?“
2. What is encapsulation?
• hide variability
• hide complexity
• Details
• "conflict of interests“
• “tech” discussions
3. Example of public member or private member + setter/getter
• What is really hidden?
• Where is simplicity?
Encapsulation – the most important OOP principle

1. “Refactoring is a controlled technique for improving the design of an existing code base.”
2. “Its essence is applying a series of small behavior-preserving transformations, each of which "too
small to be worth doing".”
3. “The cumulative effect of each of these transformations is quite significant.”
4. “By doing Refactoring in small steps you reduce the risk of introducing errors. You also avoid having
the system broken while you are carrying out the restructuring - which allows you to gradually
refactor a system over an extended period of time.”
Refactoring by Martin Fowler

1. “There is a close relationship between refactoring and patterns.”
2. “Often the best way to use patterns is to gradually refactor your code to use the pattern once you
realize it’s needed.”
3. “Joshua Kerievsky’s Refactoring to Patterns explores this topic, making this a great topic to learn
about once you’ve got the basic refactoring's under your belt.”
4. “From Refactoring To Design Pattern” path – from pure design to adequate design
5. “From ~Design Patterns To Refactoring” path – from over design to adequate design
Refactoring and Design Patterns by Martin Fowler

1. “Refactoring to Patterns is the marriage of refactoring - the process of improving the design of
existing code - with patterns, the classic solutions to recurring design problems.”
2. “Refactoring to Patterns suggests that using patterns to improve an existing design is better than
using patterns early in a new design. This is true whether code is years old or minutes old.”
3. “We improve designs with patterns by applying sequences of low-level design transformations,
known as refactoring's.”
4. And vice versa
Refactoring and Design Patterns by Joshua Kerievsky

1. There are more then 90 types of refactoring
2. Refactoring types that relate to a particular field is called a ”Refactoring Language”
3. ”Refactoring Language” gives a common terminology for discussing the situations specialists are
faced with:
• “The elements of this language are entities called Refactoring types”;
• “Each type of Refactoring describes a problem that occurs over and over again in our environment”;
• “Each type of Refactoring describes the core of the solution to that “~low level” problem, in such a way
that you can use this solution a million times over, without ever doing it the same way twice!”
Refactoring Catalog / Language

1. You have a conditional that chooses different behavior depending on the type of an object.
2. Move each leg of the conditional to an overriding method in a subclass. Make the original method
abstract.
3. And vice versa
4. Example
Replace Conditional with Polymorphism and vice versa

1. Replace Conditional Dispatcher with Command Design Pattern
• Create a Command for each action. Store the Commands in a collection and
replace the conditional logic with code to fetch and execute Commands.
2. Replace Conditional Logic with Strategy Design Pattern
• Create a Strategy for each variant and make the method
delegate the “calculation” to a Strategy instance.
3. Replace Conditional Logic with State Design Pattern
• Create a State for each variant as a part of “State Machine” and make the method
delegate tricky “calculation” to the “State Machine”.
Replace Conditional with … more sophisticated options

1. Problem:
• You have a conditional that performs various actions depending on object type or properties.
2. Solution:
• Create subclasses matching the branches of the conditional.
• In them, create a shared method and move code from the corresponding branch of the conditional to it.
• Replace the conditional with the relevant method call.
• The result is that the proper implementation will be attained via polymorphism depending on the object
class.
Replace Conditional with Polymorphism – detailed description

1. This refactoring technique can help if your code contains operators performing various tasks that vary
based on:
• Class of the object or interface that it implements
• Value of an object's field
• Result of calling one of an object's methods
2. If a new object property or type appears, you will need to search for and add code in all similar
conditionals. Thus the benefit of this technique is multiplied if there are multiple conditionals
scattered throughout all of an object's methods.
Why refactor

1. This technique adheres to the Tell-Don't-Ask principle: instead of asking an object about its state and
then performing actions based on this, it is much easier to simply tell the object what it needs to do
and let it decide for itself how to do that.
2. Removes duplicate code. You get rid of many almost identical conditionals.
3. If you need to add a new execution variant, all you need to do is add a new subclass without touching
the existing code (Open/Closed Principle).
Benefits

1. For this refactoring technique, you should have a ready hierarchy of classes that will contain
alternative behaviors. If you do not have a hierarchy like this, create one. Other techniques will help
to make this happen:
2. Replace Type Code with Subclasses. Subclasses will be created for all values of a particular object
property. This approach is simple but less flexible since you cannot create subclasses for the other
properties of the object.
3. Replace Type Code with State/Strategy. A class will be dedicated for a particular object property and
subclasses will be created from it for each value of the property. The current class will contain
references to the objects of this type and delegate execution to them.
4. The following steps assume that you have already created the hierarchy.
Preparing to Refactor

1. If the conditional is in a method that performs other actions as well, perform Extract Method.
2. For each hierarchy subclass, redefine the method that contains the conditional and copy the code of
the corresponding conditional branch to that location.
3. Delete this branch from the conditional.
4. Repeat replacement until the conditional is empty. Then delete the conditional and declare the
method abstract.
Refactoring Steps

1. Follow Refactoring to Patterns or Patterns to Refactoring flows
How to select a proper PO implementation?

Base class, inheritance, virtual functions and overloading

«Паттерны» и «антипаттерны»

Концептуальный [1]

#1 Не может существовать абсолютных
решений
Описание:
1. Применимость не применимость
2. Сама категоризация да и понятие Паттерн АнтиПаттерн –
относительно и зависит от контекста
Паттерны:
• Избегайте holy war -ов
• Как минимум, до начала полемики, четко и однозначно выясните
контекст, а так же сформулируйте в явном виде основания на
которых вы стоите и которых ожидаете от собеседника

1. Ask yourself "how can I hide some details from the rest of the software?“
2. As with any encapsulation this yields two benefits (QA Automation, Page Object Design Pattern
context):
• store logic that manipulates the UI to a single place you can modify it there without affecting other
components in the system;
• it makes the client (test) code easier to understand because the logic there is about the intention of the
test and not cluttered by UI details.
Encapsulation – the most important OOP principle

1. Page Element – encapsulates “complexity” of UI element, canonical example – table as a part of UI.
2. Page Element – the simplest Page Object (Page Object with one and only one UI element)
3. Let’s focus on Page Objects and then return back to Page Element Design Pattern.
#2 Page Element

1. Page Objects – encapsulates the way of identification and logical grouping of widgets.
2. Page Object == Logical Page
3. Page Object != Physical Page
#3 Page Object

#3 Page Object – state-less approach

#3 Page Object – state-less approach 

1. Aggregation
2. Inheritance
• Much more complicated then aggregation.
3. Summary:
• prefer aggregation to inheritance in mooooost cases;
• before start implementation based on inheritance, please, take a break for a minute, and re-thing
everything again, possibly you can find a proper solution based on aggregation.
2 ways (main, in 99% of cases) of re-usage any entity
in OOP

1. Static class
• could be implemented as a state-less solution easily
2. Object
• State-full solution in 99,99% cases
3. Summary
• prefer static class based solutions (state-less) to object based (state-full) in mooooost cases;
• before start implementation based on objects, please, take a break for a minute, and re-thing everything
again, possibly you can find a proper solution based on static classes.
Object or static class State-full or State-less
solution?

1. Static classes based
2. State-less
3. Summary:
• Such an implementation (the simplest one, state-less) – is a proper one in most cases;
• You can find dozens of examples in this presentation.
#3 Page Object – the simplest implementation

1. UI Map – one entry point
• One entry point, tree of Page Objects;
• One entry point, tree of locators.
#4 UI Map

Уровня Дизайна [5]

1. Web UI that behaves like a Wizard
2. Web UI in combination with Mobile in one use case
3. Internet of Things (in most cases)
4. More then 1 page during 1 test (for example several portals or several instances of one portal to
implement one “business use case”):
• Really seldom;
• Looks like integration tests (in most cases):
• Std solution- some type of White Box Testing.
5. Many others “special cases”
#3 Page Objects – state-full, special cases

1. “Page objects are a classic example of encapsulation - they hide the details of the UI structure and
widgetry from other components (the tests).”
• “store logic that manipulates the UI to a single place you can modify it there without affecting other layers
in the QA Automation solution (architecture)”;
• “it makes the test code easier to understand because the logic there is about the intention of the test
(focus on business logic) and not cluttered by UI details”.
#3 Page Object by Martin Fowler

1. “When you write tests against a web page, you need to refer to elements within that web page in
order to click links and determine what's displayed.”
2. “However, if you write tests that manipulate the HTML elements directly your tests will be brittle to
changes in the UI.”
3. “A page object wraps an HTML page, or fragment, with an application-specific API, allowing you to
manipulate page elements without digging around in the HTML.”
4. ”Page Object should allow a software client to do anything and see anything that a human can.”
5. ”Page Object should also provide an interface that's easy to program to and hides the underlying
widgetry in the window.”
#3 Page Object by Martin Fowler, “general” rules

#3 Page Object by Martin Fowler

1. “The page object should encapsulate the mechanics required to find and manipulate the data in the
UI control itself”
2. “Changing the concrete control - the page object interface shouldn't change.”
3. “A page object wraps an HTML page, or fragment, with an application-specific API, encapsulate a way
of page elements manipulation (without digging around in the HTML).”
4. ”A page object should also provide an interface that's easy to program to and hides the underlying
widgetry in the window.”
#3 Page Object by Martin Fowler, “encapsulation”

1. “A page object wraps an HTML page, or fragment, with an application-specific API, allowing you to
manipulate page elements without digging around in the HTML.”
2. “Despite the term "page" object, these objects shouldn't usually be built for each page, but rather for
the significant elements on a page”
3. “A header page object and a footer page object – canonical examples.”
#3 Page Object by Martin Fowler, “logical page” rule

1. “Model the structure in the page that makes sense to the user of the application.”
2. ”Page Object should allow a software client to do anything and see anything that a human can.”
3. “Some of the hierarchy of a complex UI is only there in order to structure the UI - such composite
structures shouldn't be “showed” by the page objects.”
#3 Page Object “hierarchy of a complex UI”

1. “To access a text field you should have accessor methods that take and return a string, check boxes
should use booleans, and buttons should be represented by action oriented method names.”
2. “Page object operations should return fundamental types (strings, dates) or other page objects.”
3. “If you navigate to another page, the initial page object should return another page object for the
new page.”
#3 Page Object by Martin Fowler, “should return” rule

1. “There are differences of opinion on whether page objects should include assertions themselves, or
just provide data for test scripts to do the assertions.”
2. “Advocates of including assertions in page objects say that this helps avoid duplication of assertions in
test scripts, makes it easier to provide better error messages, and supports a more TellDontAsk style
API.”
3. Asserts in Page Objects increase QA Automation window dramatically.
#3 Page Object by Martin Fowler, “assertion” rule

1. “Advocates of assertion-free page objects say that including assertions mixes the responsibilities of
providing access to page data with assertion logic, and leads to a bloated page object.”
2. “I favor having no assertions in page objects.”
3. “I think you can avoid duplication by using assertion libraries (there is a huge set such a frameworks)
for common assertions - which can also make it easier to provide good diagnostics.”
#3 Page Object by Martin Fowler, “assertion” rule

1. We've described this pattern in terms of HTML, but the same pattern applies equally well to any UI
technology. I've seen this pattern used effectively to hide the details of a Java swing UI and I've no
doubt it's been widely used with just about every other UI framework out there too.
2. Patterns that aim to move logic out of UI elements (such as Presentation Model, Supervising
Controller, and Passive View) make it less useful to test through the UI and thus reduce the need for
page objects.
#3 Page Object - notes

1. Page objects are most commonly used in testing, but can also be used to provide a scripting interface
on top of an application.
2. It's best to put a scripting interface underneath the UI, that's usually less complicated and faster.
3. However with an application that's put too much behavior into the UI then using page objects may
make the best of a bad job. (But look to move that logic if you can, it will be better both for scripting
and the long term health of the UI.)
#3 Page Object – alternative areas of usage

1. Page Element – encapsulates “complexity” of UI element, canonical example – table as a part of UI.
2. Page Element – the simplest Page Object (Page Object with one and only one UI element)
#2 Page Element

1. Action – a set (tiny or huge) of lines of code based on “primitive” “low level” API (for example
Selenium or some wrapper) calls.
2. Action is usually used in a combination with Page Element and Page Object Design Patterns.
3. Action layer could be separated from, combined with Page Objects layer … or even both approached
in one solution.
#5 Action

1. 2 “types” of Actions:
• QA Automation specialist oriented;
• Business (~Product Owner) oriented;
2. Action – isn’t a right place for asserts in mooooooooost cases:
• There is no sense to check the same functionality in the same build dozens of times;
• Such an approach seriously increase QA Automation windows;
#5 Action

1. QA Automation specialist oriented Action can contain just several lines of code, to simplify
manipulations with Widgets.
2. Business oriented Action can be a “copy” of some test (without all asserts).
3. In general Action layer could be implemented ether as a classical API or as a DSLFlow based API.
#5 Action

#6 Flow, Fluent Interface, “logical chain”
• Ubiquitous language
• Domain model
• Domain driven design (DDD)
• In fact – really-really useful, general purpose practice, part of fully
implemented Agile process
• Key word driven QA Automation
• Behavior Driven Development (BDD) approach – as a special case of
DSL based QA Automation solutions

• Domain specific language (DSL) based QA Automation
• Flow – as a way of implementation DSLBDD
• State-full solution

• Flow- fluent interface is an implementation of an object oriented API
that aims to provide more readable code.
• A fluent interface is normally implemented by using method
cascading (concretely method chaining) to relay the instruction context
of a subsequent call (but a fluent interface entails more than just
method chaining).
• Generally, the context is defined through the return value of a called
method self-referential, where the new context is “equivalent” to the
last context terminated through the return of a void context.

LoginPage.Instance().Navigate()
.Login()
.Search("some entity")
.ClickImages()
.SetSize(Sizes.Large)
.SetColor(Colors.BlackWhite)
.SetTypes(Types.Clipart)
.SetPeople(People.All)
.SetDate(Dates.PastYear)
.SetLicense(Licenses.All);

Flow by Martin Fowler
• “Building a fluent API like this leads to some unusual API habits.”
• “One of the most obvious ones are setters that return a value.”
• “The common convention in the curly brace world is that modifier
methods are void, which I like because it follows the principle of
CommandQuerySeparation. This convention does get in the way of a
fluent interface, so I'm inclined to suspend the convention for this
case.”

Flow by Martin Fowler
• “You should choose your return type based on what you need to
continue fluent action.”
• “The key test of fluency, for us, is the Domain Specific Language
quality. The more the use of the API has that language like flow, the
more fluent it is.”

Уровня взаимодействия с бизнесом [3]

#7 Keyword driven testing
Вы можете найти детальную информацию «#8 Domain Specific
Language»
COMAQA Piter 2017. Роман Иовлев vs Антон Семенченко. BDD vs
notBDD battle

#8 BDD
Вы можете найти детальную информацию «#8 Domain Specific
Language»
COMAQA Piter 2017. Роман Иовлев vs Антон Семенченко. BDD vs
notBDD battle

#9 Domain Specific Language
DSL
• DSL = Domain (ether technical or business … or both – Gherkin for
specific domain) + Language
• Language = Dictionary + Structure
• Dictionary = Ubiquitous language
• Structure = some rules how to combine words (business terms) from
dictionary in a proper ways (based on business logic)
• Way of implementation (one of the ways) – Flow Design Pattern

DSL by Martin Fowler
• The basic idea of a domain specific language (DSL) is a computer
language that's targeted to a particular kind of problem (QA
Automation or even QA Automation in exact domain), rather than a
general purpose language that's aimed at any kind of software
problem. Domain specific languages have been talked about, and used
for almost as long as computing has been done.
• DSLs are very common in computing: examples include CSS, regular
expressions, make, rake, ant, SQL, HQL, many bits of Rails, expectations
in JMock …

DSL by Martin Fowler
• It's common to write tests using some form
of DomainSpecificLanguage, such as Cucumber or an internal DSL. If
you do this it's best to layer the testing DSL over the page objects so
that you have a parser that translates DSL statements into calls on the
page object.

DSL types by Martin Fowler
• Internal DSLs are particular ways of using a host language to give the
host language the feel of a particular language. This approach has
recently been popularized by the Ruby community although it's had a
long heritage in other languages - in particular Lisp. Although it's
usually easier in low-ceremony languages like that, you can do
effective internal DSLs in more mainstream languages like Java and
C#. Internal DSLs are also referred to as embedded DSLs or
FluentInterfaces

DSL types by Martin Fowler
• External DSLs have their own custom syntax and you write a full parser
to process them. There is a very strong tradition of doing this in the
Unix community. Many XML configurations have ended up as
external DSLs, although XML's syntax is badly suited to this purpose.
• Mixed (internal with external)
• Graphical DSLs requires a tool along the lines of a Language
Workbench.

#10 Navigator (for Web)
• Navigator (for Web) – follows “DRY” and “Single source of truth”
principles, encapsulates “complexity” of links transitions between
web pages and store this information in one and only one place.
• Usually:
• works in a combination with a “Page Object” and “Action” Design Patterns for
QA Automation;
• “Action” layer implements via Flow or DSL approaches;
• state-full approach;
• applies for really big projects.

#11 +20 Design Patterns в контексте
Автоматизации тестирования
Эти DP в контексте Автоматизации тестирования будут
рассмотрены в соответствующем 8 часовом тренинге:
1. Factory method, Abstract Factory, Creational Method, Builder
2. Assert Object / Matchers
3. Builder, Composite, Iterator, Decorator, Visitor
4. Proxy / Loadable component

Эти DP в контексте Автоматизации тестирования будут
рассмотрены в соответствующем 8 часовом тренинге:
5. Data Registry / Singleton
6. Object Pool / Flyweight / Singleton
7. Data Provider / Singleton
8. Value Object / Data Transfer Object

Технические детали тренингов по Архитектуре:
• В ООП существует всего 2 базовых средства «художественной
выразительности»: агрегация и наследование.
• Даже если мы начнем оперировать на более высоком уровне
абстракции, что в корне не верно, но все же, то получим 5 базовых
элементов (+ объект, класс, интерфейс).
• Средств «художественной выразительности» единицы; DP сотни и
даже тысячи; бизнес проблем миллионы.

• Классический подход предлагает нам сделат ь выбор mapping в
общем виде новой для себя проблемы на новые для себя DP
используя связь проблемы – DP’s и их комбинации.
• Если мы попытаемся разобраться в родственных DP’s, используя
классические подходы к класификации, то 10-ки или даже 100 DP’s
реализованы с использованием одних и тех же средств «худ.
выразительности», возможно в чууууть иных комбинациях, а
значит сделать разумный выбор без экспертной оценки
невозможен.

• Пример: Factory Method, Abstract Factory, Creational Method, Builder
как способ формирования Composite или вариант группировки
Decorator-ов реализованы с помощью агрегации и наследования ...
А значит сделать среди них осознанный выбор в неизвестном
контексте опираясь на классические начала невозможен.

• Предложенный многими специалистами mapping БизнесПроблема
– DP не работает и работать не может (за исключением
стандартного списка проблем, что так удобно для студентов и
молодых специалистов)
• Инкапсуляция! Что именно инкапсулирует тот или иной DP!
• Бизнес проблема - что, когда, как и почему нужно инкапсулировать
=> минимальный полный набор инкапсуляций по которому и
строится связка DP с выбором оптимизацией по некоему доп.
критерию.

#12 State-less or State-full solution
Вы сможете найти детальную информацию в «Theoretical
fundamentals».

Уровня Архитектуры [4]

#13 Особенности функционирования в
экосистеме Enterprise языков
Проблема (на популярном примере):
Java – один из самых популярных языков для Автоматизации
тестирования; основная задача Java – разработка ПО для
«кровавого» Enterprise-а => большая часть конструкций языка
слишком сложна излишня для Автоматизации тестирования, best
practices – переусложнены для Автоматизации, советы официальной
документации и форумов проф разработчиков – так же выдают не
оптимальное для Автоматизации, а переусложненное решение.

Паттерн:
• Использовать минимальное полное подмножество языка (Java)
• Сознательно выбирать наиболее простые конструкции языка
• Сознательно избегать большинства популярных библиотек
(субъективный пример на базе выборки ЭПАМ: так Swing
используется примерно в 40% проектов по Автоматизации
тестирования на Java, а реально необходим лишь в 2%)

Паттерн:
• Использовать специализированную литературу и форумы с
фокусом в Автоматизации тестирования, а не классической
разработки.
• Задуматься о переходе на легковесные языки, скажем Kotlin

#14 Трудоемкая разработка Архитектуры
тестового проекта
Паттерн:
1. В подавляющем большинстве случаев (не владею точными
данными по отрасли в целом, пусть будет 98% ) разработка
стартового варианта Архитектуры тестового проекта должна
занимать от 4 человеко-часов (при наличии опыта и готовых
наработок) до считаных человеко-дней (в обратном случае) ...
Любое затягивание фазы работы над архитектурой
автоматически приводит к проблеме Over-Design-а.

#15 «Прости Господи Архитектор»
Проблема:
Специалисты в Автоматизации тестирования регулярно не могут
найти конструктивный способ саморазвития ... И не найдя
конструктива, погружаются с головой в деструктив: разработка
Архитектуры ради Архитектуры, разработка собственных
вспомогательных инструментов без бизнес обоснования, и конечно
разработка собственных Wrapper-ов над популярными
инструментами, вроде Selenium-а, без единого здравого аргументу в
пользу инвестиций человеко-месяцев лет
Паттерн:
Работа Resource Manager-а особенно важна и трудоемка с
Автоматизаторами.

Человеческий капитал [6]

#16 Использование конфигураций Hardcoded
values
Данные

values
Конфигурации

values
Паттерн:
1. Вместо hardcoded values используйте
1. Параметры командной строки для CI
2. Соответствующий набор конфигурационных файлов того или иного
формата
Выбор опции «1» или «2» зависит от размера сложности проекта, деталей
окружения
Универсальное решение: сразу использовать пусть вырожденный, но уже
готовый для потенциального расширения набор входных конфигурационных
файлов (контр аргумент – преждевременное, пока не оправданное,
введение дополнительного уровня косвенности)

#17 Удобная отчетность

#17 Удобная отчетность
Паттерн:
1. Используйте “QA Automation Analyses Windows” метрику для
контроля анализа принятия решения
2. Разработка matcher-ов в качестве стандартных helper-ов проекта
3. Идеальный конечный результат:
1. Вы пишете, но не читаете логи и трейсы
2. Вы вкладываетесь в зеленый параметр метрики “QA Automation Analyses
Windows”

#18 Понеслась
Контекст:
Заказчик выступил в роли «не компетентного» инициатора
Автоматизации:
• Автоматизация – это «модно»;
• CI – это «модно», но без АвтоТестов не работает;
• Запрос на Автоматизацию – один из самых популярных;

#18 Понеслась
Паттерн:
• Начинать поиск решение с Vision, Test Strategy, Test Plan, QA
Automation ROI, Metrics
• COMAQA Piter 2017. Антон Семенченко. Разработка эффективной
тестовой стратегии
• http://dpi.solutions/education?name=testing-strategy
• http://dpi.solutions/education?name=roi-for-automation-testing
• http://dpi.solutions/education?name=metrics-in-testing
АнтиПаттерн:
• Just do it Понеслась

#19 Test Pyramid
Описание Паттерн:
• Антон Семенченко. Пирамида Тестирования через призму ROI
калькулятора #1
• Антон Семенченко. Пирамида Тестирования через призму ROI
калькулятора #2
АнтиПаттерн:
• Не использование некорректное использование пирамиды
тестирования
• «Мороженка» 
• «Кексик» 

#19 Test Pyramid
Юнит-тесты
API-тесты
UI- автотесты
Ручное тестирование

#19 Test Pyramid – «Мороженка»
Много ручного тестирования
Слой хрупких и требовательных тестов
очень велик
Слой самых быстрых и надежных тестов
крайне мал

Откуда берутся ... «Мороженки»
Кажущаяся сложность написания юнит-
тестов (создание / поддержка моков) по
сравнению с UI-тестами
Нужно таски
закрывать! Какие
юнит-тесты?!

#19 Test Pyramid - «Кексик»
Ручные тесты дублируют проверки
того, что покрыто UI-автотестами
UI-тесты дублируют проверки того, что
покрыто Unit-тестами

Откуда берутся ... «Кексики»
Стремление автоматизировать все, что
можно
Нет четкого плана (каскадность
антипаттернов ... как и паттернов)
“Положительные” контр примеры
пирамидальных трансформаций: опыт
работы с Siemens, Intel, Telekom*

Паттерн 
Юнит-тесты
API-тесты
UI- автотесты
Ручное тестирование

#20 Не атомарные Test Cases == не
линейные отчеты + проблема
тестирования тестов четность ошибок
TableDefaultBehaviorTest PASSED
TableDefaultBehaviorTest FAILED

#20 Не атомарные Test Cases == не линейные
отчеты + проблема тестирования тестов
четность ошибокПричины проблем:
• Стремление «сэкономить» на
количестве тестов, т.е. времени
их разработки, поддержки,
прогона.
• «И так же проверяет!»
• «А по другому не получается!»
Паттерн:
«Разделяй и властвуй» - дробите
Автотесты до минимальной
цикломатической сложности; в
идеале, добивайтесь автомарности
автотестов

#20 Не атомарные Test Cases == не
линейные отчеты + проблема
тестирования тестов
Дополнительные источники информации:
COMAQA Piter 2017. Антон Семенченко. Системный взгляд на
параллельный запуск Selenium #1
«Хорошие» и «плохие» варианты параллельного запуска Selenium
WebDriver тестов — Антон Семенченко #2

#21 На позитиве
Контекст:
• Доминирование «позитивных» тестов
Паттерны:
• Планирование: Test Plan, Metrics
• COMAQA Piter 2017. Антон Семенченко. Разработка эффективной
тестовой стратегии
• http://dpi.solutions/education?name=testing-strategy
• http://dpi.solutions/education?name=roi-for-automation-testing
• http://dpi.solutions/education?name=metrics-in-testing

#21 На позитиве
АнтиПаттерны:
• Отсутствие планирования
• «Майндсет» разработчика
• «Бездумное» следование спецификации

#21 На позитиве ;)
Большой объем тестирования
остается за ручными тестировщиками

Паттерн 
Keep calm and stay pessimistic

Main “principles”
• “If you have WebDriver APIs in your test methods, You're Doing It
Wrong.” - Simon Stewart
• Don't repeat yourself (DRY): “Every piece of knowledge must have a
single, unambiguous, authoritative representation within a system” -
Andy Hunt and Dave Thomas in their book The Pragmatic Programmer
• “Broken windows theory”

“Tell-Don't-Ask” principle
This is a principle that helps people
remember that object-orientation is
about bundling data with the
functions that operate on that data. It
reminds us that rather than asking an
object for data and acting on that
data, we should instead tell an object
what to do. This encourages to move
behavior into an object to go with the
data.

Useful “principles”
• “Test-driven development”
• “Single responsibility principle”
• “Single source of truth”
• “Interface segregation principle”
• “Occam's razor”
• “Poka-yoke”

Врата - песнь 3, стихи 22-31
• Там вздохи, плач и исступленный крик
• Во тьме беззвездной были так велики,
• Что поначалу я в слезах поник.
• Обрывки всех наречий, ропот дикий,
• Слова, в которых боль, и гнев, и страх,
• Плесканье рук, и жалобы, и всклики
• Сливались в гул, без времени, в веках,
• Кружащийся во мгле неозаренной,
• Как бурным вихрем возмущенный прах.

Врата
Аантипаттерны UI-Автоматизации
Если за дело берется «прости Господи Архитектор», то «оставь
надежду всяк сюда входящий»

Что делать?
Стараться избегать рисков из областей:
#11, #12, #13, #14, #15

Первый круг: Лимб – песнь 4, стихи 25-31
• Сквозь тьму не плач до слуха доносился,
• А только вздох взлетал со всех сторон
• И в вековечном воздухе струился.
• Он был безбольной скорбью порожден,
• Которою казалися объяты
• Толпы младенцев, и мужей, и жен.

Первый круг: Лимб
Statefull решение без причины - ...

Что делать
#12

Второй круг: Похоть – песнь 5, стихи 31-39
• То адский ветер, отдыха не зная,
• Мчит сонмы душ среди окрестной мглы
• И мучит их, крутя и истязая.
• Когда они стремятся вдоль скалы,
• Взлетают крики, жалобы и пени,
• На господа ужасные хулы.
• И я узнал, что это круг мучений
• Для тех, кого земная плоть звала,
• Кто предал разум власти вожделений.

Второй круг: Похоть
Разработка собственного Selenium Wrapper-а 

Что делать
#11, #12, #14, #15

Третий круг: Чревоугодие – песнь 6, 7-15
• Я в третьем круге, там, где, дождь струится,
• Проклятый, вечный, грузный, ледяной;
• Всегда такой же, он все так же длится.
• Тяжелый град, и снег, и мокрый гной
• Пронизывают воздух непроглядный;
• Земля смердит под жидкой пеленой.
• Трехзевый Цербер, хищный и громадный,
• Собачьим лаем лает на народ,
• Который вязнет в этой топи смрадной.

Третий круг: Чревоугодие
«Прости Господи Архитекторы - Гурманы»

Четвертый круг: Моты Жадины – песнь 7,
стихи 24-35
• Так люди здесь водили хоровод.
• Их множество казалось бесконечным;
• Два сонмища шагали, рать на рать,
• Толкая грудью грузы, с воплем вечным;
• Потом они сшибались и опять
• С трудом брели назад, крича друг другу:
• "Чего копить?" или "Чего швырять?" / «Over-design» или «Pure-
design»

Четвертый круг: Моты Жадины – песнь 7,
стихи 24-35
• И, двигаясь по сумрачному кругу,
• Шли к супротивной точке с двух сторон,
• По-прежнему ругаясь сквозь натугу;
• И вновь назад, едва был завершен
• Их полукруг такой же дракой хмурой.

Четвертый круг: Моты Жадины
«Апологеты» Over-design или Pure-design 

Что делать
#12 + Refactoring and theory

Пятый круг: Ленивые Гневливые – песнь 8,
стихи 31-38
• Посередине мертвого потока
• Плачь, сетуй в топи невылазной,
• Проклятый дух, пей вечную волну!

Пятый круг: Ленивые Гневливые
«Понеслась» или начать работу предварительно не
подумав запланировав

Что делать
#18, #19
и как следствие
#20, #21

Шестой круг: Еретики и лжеУчителя – песнь
9, стихи 115-124
• Гробницами исхолмлен дол бесплодный, -
• Так здесь повсюду высились они,
• Но горечь этих мест была несходной;
• Затем что здесь меж ям ползли огни,
• Так их каля, как в пламени горнила
• Железо не калилось искони.
• Была раскрыта каждая могила,
• И горестный свидетельствовал стон,
• Каких она отверженцев таила

Шестой круг: Еретики и лжеУчителя – песнь
11, стихи 1-7
• Мы подошли к окраине обвала,
• Где груда скал под нашею пятой
• Еще страшней пучину открывала.
• И тут от вони едкой и густой,
• Навстречу нам из пропасти валившей,
• Мой вождь и я укрылись за плитой.

Шестой круг: Еретики и лжеУчителя
«Апологеты» BDD, Kew-word driven, Flow Fluent Interface 

Что делать
#6, #7, #8, #9
и как следствие
#12, #11

Седьмой круг: Насильники Тираны – песнь
12, стихи 100-118
• Вдоль берега, над алым кипятком,
• Был страшен крик варившихся живьем.
• Я видел погрузившихся по брови.
• Кентавр сказал: "Здесь не один тиран,
• Который жаждал золота и крови:
• Все, кто насильем осквернил свой сан.
• Потом мы подошли к неотдаленной
• Толпе людей, где каждый был покрыт
• По горло этой влагой раскаленной.

Седьмой круг: Насильники Тираны
Over-design Архитекторы в Автоматизации жестоко
насилуют десятки разработчиков тестов ежедневно

Что делать
#14, #15
и как правило
#11, #12, #13

Седьмой круг: Самоубийцы – песнь 13,
стихи 4-16
• Там бурых листьев сумрачен навес,
• Там вьется в узел каждый сук ползущий,
• Там нет плодов, и яд в шипах древес.
• Там гнезда гарпий, их поганый след,
• С широкими крылами, с ликом девьим,
• Когтистые, с пернатым животом,
• Они тоскливо кличут по деревьям.

Седьмой круг: Самоубийцы
Over-design Архитекторы в Автоматизации которые лично
реализуют Авто-тесты на базе собственной переУсложненной
архитектуры; костыль и велосипед

Седьмой круг: Богохульники и Содомиты –
песнь 14, стихи 19-31
• Я видел толпы голых душ в пустыне:
• Все плакали, в терзанье вековом,
• Но разной обреченные судьбине.
• Кто был повержен навзничь, вверх лицом,
• Кто, съежившись, сидел на почве пыльной,
• А кто сновал без устали кругом.

Седьмой круг: Богохульники и Содомиты –
• Разряд шагавших самый был обильный;
• Лежавших я всех меньше насчитал,
• Но вопль их скорбных уст был самый сильный.
• А над пустыней медленно спадал
• Дождь пламени, широкими платками,
• Как снег в безветрии нагорных скал.

Седьмой круг: Богохульники и Содомиты
Все те, кто по неким «соображениям» не читает
классических книг священного писания IT специалиста, а
пытается постичь азы теории путем практического
экспериментирования, обычно, проходящего через опу ...

Что делать
#0 + теория о рефакторинте как критерии перехода

Восьмой круг: Сводники Обольстители –
• Внизу скалы повапленный народ
• Кружил неспешным шагом, без надежды,
• В слезах, устало двигаясь вперед.
• Все - в мантиях, и затеняет вежды
• Глубокий куколь, низок и давящ;
• Так шьют клунийским инокам одежды.

Восьмой круг: Сводники Обольстители –
• Снаружи позолочен и слепящ,
• Внутри так грузен их убор свинцовый,
• Что был соломой Федериков плащ.
• О вековечно тяжкие покровы!
• Мы вновь свернули влево, как они,
• В их плач печальный вслушаться готовы.

Восьмой круг: Сводники Обольстители
Все те, кто идет на поводу «требований» заказчика в виде
лозунга «Автоматизация – это тренд», «Автоматизация – один
из наиболее популярных бизнес запросов» ... отбрасывая Test
Strategy, QA Planning, ROI Calculator, Test Pyramid и конечно
Metrics для принятие адекватного задаче решения ... Команда
же взваливает на себя «Сизифов труд».

Девятый круг: Предатели – песнь 32, стихи
22-47
• Что подо мною озеро, от стужи
• Подобное стеклу, а не волнам.
• И как лягушка выставить ловчится,
• Чтобы поквакать, рыльце из пруда,
• Когда ж ее страда и ночью снится,
• Так, вмерзши до таилища стыда
• И аисту под звук стуча зубами,
• Синели души грешных изо льда.

Девятый круг: Предатели – песнь 32, стихи
22-47
• Свое лицо они склоняли сами,
• Свидетельствуя в облике таком
• О стуже - ртом, о горести - глазами.
• И их глаза, набухшие от слез,
• Излились влагой, и она застыла,
• И веки им обледенил мороз.

Девятый круг: Предатели
Жертвы ошибок при использовании QA Automation ROI и Test
Pyramid

«Что мы имеем в итоге ...»
1. Алгоритм best practices + сквозная нумерация
2. Инкапсуляция – как основной единственный  принцип ООП
3. Инкапсуляция2  – как эффективный способ «классификации»
Design Patterns (в том числе «процессных» )
4. Рефакторинг по Фаулеру и Кириевски – как критерий перехода
5. Страстный призыв «Думай»
6. «Горячая» проверенная временем метафора
7. Новый взгляд на Гемификацию
8. Символ 
9. Список видео аудио литературы

«Горячая» метафора

Гемификация - было

Гемификация – стало 

Символ
Научно-технический рэп «Костыль и велосипед»
• Если программисты строили бы дом,
• Фундамента могло б не оказаться в нем.
• Четыре стены глухие, двери - потом,
• Окна - тоже, понадобится - пробьем!
• Так, что еще нужно? А, крыша!
• Видишь картон? Бери его, парниша!
• Тащи его наверх, клади его в два слоя,
• Чтоб ветром не срывало, к черту остальное.
• Опять стройка встала, на стройке паралич -
• Прораб изобретает свой собственный кирпич.
• Пока косится лавэ, все прорабу трын-трава,
• Он ходит-напевает эти странные слова

Символ
• Если программисты были бы врачами:
• "Чувак, сломал ногу" - голвами покачали:
• "Эй, гляди сюда, такая же нога,
• Но у меня работает - бугага"
• У хирурга был бы самый неблагодарный труд:
• Он все время что-то режет, но люди не встают,
• Хирург пишет на форуме: "Наверно, мой косяк.
• Вот фотки со стола, что я делаю не так?"
• А еще в стационаре есть нацистская бригада,
• Она следит за тем, чтоб все было так, как надо
• И не зная праздников, не зная выходных,
• Отправляет прямо в морг недолеченных больных.

Символ
• Все правильно, конечно - зачем людей лечить,
• Если можно просто выключить и снова включить,
• Живыми из больнички не выходят зачастую,
• Персонал напевает эту песенку простую:
• Семь бед - один ответ:
• Костыль и велосипед,
• Семь бед- один ответ:
• Вставь костыль, изобрети велосипед

Символ  Семь бед - один ответ:
Костыль и велосипед,
Семь бед- один ответ:
Вставь костыль, изобрети велосипед

Автоматизация сегодня 
Семь бед - один ответ:
Костыль и велосипед,
Семь бед- один ответ:
Вставь костыль,
изобрети велосипед

Идеальный конечный результат

Решение
Человеческий фактор на 90%

Полезное видео
1. Николай Алименков — Паттерны проектирования в
автоматизации тестирования
2. Вадим Зубович. Жизнь на костылях, или антипаттертны UI-
автоматизации

Полезное аудио 
1. Научно-технический рэп «Костыль и велосипед»
2. Научно-технический рэп «... и в продакшн»
3. Научно-технический рэп «Полиморфизм»
4. Научно-технический рэп «Дедлайн»
5. Научно-технический рэп - Ария тестировщика ПО
6. Научно-технический рэп «Папа может в си»

Литература 
• Данте «Божественная комедия»

Martin Fowler “Refactoring”
• http://martinfowler.com/books/refactoring.html
• http://refactoring.com/
• http://refactoring.com/catalog/
• http://refactoring.com/catalog/replaceConditionalWithPolymorphis
m.html

Refactoring to Patterns and vice versa
• https://industriallogic.com/xp/refactoring/
• https://industriallogic.com/xp/refactoring/catalog.html
• https://industriallogic.com/xp/refactoring/conditionDispatcherWith
Command.html
• https://industriallogic.com/xp/refactoring/conditionalWithStrategy.
html
• http://martinfowler.com/books/r2p.html

Полезные линки от source making
• https://sourcemaking.com/
• https://sourcemaking.com/refactoring
• https://sourcemaking.com/refactoring/replace-conditional-with-polymorphism
• https://sourcemaking.com/design_patterns
• https://sourcemaking.com/antipatterns
• https://sourcemaking.com/antipatterns/software-development-antipatterns
• https://sourcemaking.com/antipatterns/software-architecture-antipatterns
• https://sourcemaking.com/uml

Человеческий фактор
1. Tom de Marco «Peopleware: Productive Projects and Teams.»
Notes: «Spiritual» book... easy to read, almost fiction... recommend to read twice.
[E1-E3]
2. Tom de Marco «The Deadline: A Novel About Project Management»
Notes: «Spiritual» book... easy to read, almost fiction... recommend to read twice
[E1-E3]
3. F. Brookes «The Mythical Man-Month: Essays on Software
Engineering»
Notes: «Spiritual» books ... easy to read, almost fiction ...recommend to read
twice.
[E1-E3]

Обще техническая литература
1. Grady Booch “Object oriented analysis and design with C++
examples”
Notes: Do not be afraid of С++ examples, 95% of the material is conceptual, and
not depending on the exact programming language From my point of view it’s
one of the best books for real learning what OOP is. It might look too simple for
you – which makes it even more pleasant to read before going to bed.
[E1-E3]

2. Martin Fowler «Refactoring»
Notes: IMHO strongly recommend to read from the beginning to the end, twice in
a row, to make the ideas of the book part of your life and active professional skill.
(I’ve done it myself and recommend to everybody). You should put the additional
attention to the refactoring “Replace Conditional with Polymorphism” and vice
versa “Replace Polymorphism with Conditional” and concepts “From Refactoring
to Design Patterns” and “From Patterns to Refactoring” (the book and the
following articles), those 2 pair refactoring and 2 pair concepts give us an exact
answer where we should or shouldn’t use Design Patterns, also during designing
the Architecture solutions for Automation, give us solution criteria when we
should make existing lean architecture more complex and add patterns, and
when should we make the existing “monster” simpler, and avoid the created
complex architecture to a couple of if’s.
[E1-E3]

3. D. Thomas, A. Hunt “The Pragmatic Programmer: From Journeyman
to Master”
Notes: Amazing book, consisting of a ton of atomic advices. IMHO should be read
twice from the beginning to the very end and then you should look through
different chapters while preparing to the discussion with the customer or an
interview.
[E2-E3]
4. Steve McConnell «Code compete»
Notes: Do not be afraid of the size of that book...It should be read before going to
bed from any place of the book...or by separate chapters, in order to get update
and refresh the knowledge of different fiel.
[E1-E3]

5. Gang of four “Design patterns”
Notes: IMHO strongly recommend to read from the beginning to the very end, at
minimum, 2 times in a row, in order to have contents of the book become your
active professional baggage, and then implement each of the pattern on your
personal, even training project.
[E1-E3]
6. «Pattern-Oriented Software Architecture» Volume 1-3
Notes: IMHO very good book about architecture, recommend to read from the
beginning to the very end.
[E3-E5]

7. «Domain Specific Languages», Martin Fowler
Notes: IMHO recommend to read from the beginning to the end, because
creating DSL – a regular practice in Automated testing.
[E3-E5]
8. «Patterns of Enterprise Application Architecture», Martin Fowler
Notes: IMHO a big variety of additional Design Patterns which are relevant for
big complex systems.
[E2-E4]
9. Kent Beck «Extreme programming. Development through testing»
Notes: IMHO easy to read book, conceptually holistic book, with useful examples
[E1-E2]

Спасибо за внимание!

Anton semenchenko. Comaqa Spring 2018. Nine circles of hell. Antipatterns in UI-automation.

Recommended

Recommended

More Related Content

Similar to Anton semenchenko. Comaqa Spring 2018. Nine circles of hell. Antipatterns in UI-automation.

Similar to Anton semenchenko. Comaqa Spring 2018. Nine circles of hell. Antipatterns in UI-automation. (20)

More from COMAQA.BY

More from COMAQA.BY (20)

Anton semenchenko. Comaqa Spring 2018. Nine circles of hell. Antipatterns in UI-automation.