Selenium - CSS или XPath?

Предисловие.

В последнее время стал замечать в разных местах - в автоматических тестах, в статьях, в обсуждениях на форумах, что люди стали очень часто использовать XPath для определения элеметов в web тестах написанных с использованием Selenium WebDriver. Единого ответа на вопрос - почему - я так и не смог получить. Лично я как-то никогда особо xpath не любил(уж не знаю почему) и при написании использовал исключительно CSS. И вот я решил разобраться и попытаться сравнить(больше для себя, а может и кому-нибудь полезно будет) эти 2 способа поиска элементов - CSS и XPath. Основными критериями для сравнения хочется взять следующие:

а)скорость - оценить, кто же быстрее ищет элементы?

б)красота и удобство написания локаторов - достаточно субъективная оценка, но все же

в)возможности и ограничения - что может один и не может другой?

Скорость.

Наверное самый интересующий показатель в данном исследовании - это скорость. Раздел будет состоять из 2-х частей:

а)как проводилась проверка - описание теста, входные данные и тп

        б)анализ результатов

Входные данные:

Jsonium - инструмент для тестирования REST запросов

Как часто в моей практике работы в IT я сталкивался с проблемой - нужно быстро попробовать послать , скажем, POST  запрос по определенному url с некоторыми параметрами в теле. 

Понятно, что существует множество инструментов для этих целей. Один из самых известных - это, наверное, Postman - плагин для chrome, позволяющий делать множество различных операций с REST. 

В данном посте хотелось бы рассказать о новом инструменте - Jsonium( ссылка на сайт ).

Что такое Jsonium?

      По сути своей - это инструмент с удобным и , что важно, очень простым интерфейсом для тестирования различных REST запросов, но со смещением в сторону популярного в наше время формата передачи данных - JSON. 

       Что хотелось бы выделить из явных плюсов:

Maven: specify folder for jars

Sometimes you need to download jars, which were in your "dependencies" block into specified directory.
For this task you may use this approach: in "plugins" part of your pom.xml add such block:

<build>

        <plugins>

            <plugin>

                <groupId>org.apache.maven.plugins</groupId>

                <artifactId>maven-dependency-plugin</artifactId>

                <version>2.1</version>

                <executions>

                    <execution>

                        <phase>generate-sources</phase>

                        <goals>

                            <goal>copy-dependencies</goal>

                        </goals>

                        <configuration>

                            <outputDirectory>${project.build.directory}/lib</outputDirectory>

                        </configuration>

                    </execution>

                </executions>

            </plugin>

        </plugins>

    </build>

This will copy all jars into target/lib folder after run command : mvn generate-sources

If you want to specify directory from command line, you can do such thing:

Роль архитектуры в автоматизации тестирования

Введение.

В последнее время всё чаще при просмотре чьих-либо автоматических тестов я начал сталкиваться с рядом проблем, связанных во многом с  изначально слабой продуманностью их архитектуры.  Стало создаваться такое впечатление, что весь процесс написания автотестов сводится к 2 шагам - получение задачи от заказчика(во многом в его роли выступает начальник отдела тестирования или какой либо project manager) и написание кода. В этой цепочке слишком часто стал упускаться один важнейший шаг, а именно - проработка архитектуры тестов. В итоге всё это приводит к тому, что при желании модифицировать или добавить что-либо в тесты - приходится , как говорил один мой хороший знакомый, “переколбашивать” много уже написанного кода. А это - время, которое в современном мире очень дорого может стоить.

В данной статье мне хотелось бы описать некоторые проблемы, которые встречаются чаще всего при написании автоматических тестов, попробовать разобраться, почему они возникают, и предложить, разумные решения для выхода из сложившихся ситуаций. Так же постараюсь описать некоторые правила , которые я понял на своём “горьком” опыте, и которые должен понять каждый специалист, занимающийся непростым занятием - автоматизацией тестирования.

Начнем, наверное, с главного, а именно - что же это за зверь, автоматизация?

SoapUI - the best ways of test projects integration.

I want to talk about some problem I encountered with while I created some tests with SoapUI tool.
The problem was - when we want to use some tests modules , which was developed by another person also with SoapUI - we often do the following:
1)Import someone's test suite to our project
2)use "Run TestCase" step for executing of test cases of someone's suite.
This is the standard way of integration of several test projects in SoapUI.
But. What will happened if this "someone" modified his test suite? Your imported test suite now doesn't work.
After that you will try to do the following:
1)get new version of "someone's" test suite and import it instead of old version.
After run of modified tests - you will get an exception, because SoapUi saved dependency to old version of "someone's" test suite and "doesn't understand" the new version of this suite.
I hope I well described the problem. Now I want to describe good(in my opinion) way to solve this problem.

First.
When you are writing your tests and you know that you will use someone's modules(in SoapUI terminology - this means - Test Suites), the better way is NOT to use "Run TestCase" from your tests. The better way is described on the image below: