Обновил версию до 1.0.4.

Нововведения:
Добавлена поддержка net45/net451/net452 и netstandard2.0.

Доброго времени суток, коллеги!

Я столкнулся со следующими проблемами/неудобствами в аллюре на C#:

1. Невозможность добавления шагов/аттачей в [SetUp] и [TearDown] методах.
2. Отсутствие нормальной возможности указания собственных:

• Suite (самое неприятное)
• SubSuite
• Owner
• Epic Suite
• Parent Suite

3. При выполнении действий в других потоках в рамках одного теста - allure падает с исключением.
   Т.е. если вы сделаете нечто подобное

   Task.Run( () => someMethod());

   и внутри данного метода будет вызвано логирование аллюр - выбросится исключение NullReferenceException.

4.  

5. Отсутствие проигнорированных тест-кейсов/тестов в отчётах. Это кейсы, у которых прописано TestCaseData.Ignore(string), а не в самом тесте Assert.Ignore (!)
   Для меня это оказалось критично, т.к. если мы не смогли найти подходящие тестовые данные из БД для кейса, он должен об этом кричать в отчете, а не отсутствовать там.

6. Отсутствие нормального AddAttachment метода, который форматировал бы string в читабельный вид с отступами (json/xml).

Было что-то ещё, но оно не столь критичное, сейчас я уже не вспомню.

Я взял за основу проект https://github.com/u...ure-csharp-fork и добавил в него всю необходимую функциональность.

Переработанный мною C# allure имеет функциональность только для классического NUnit.
Если вы используете SpecFlow - не устанавливайте этот пакет, в нём нет ничего относящегося к SpecFlow, у вас всё сломается!
В будущем я добавлю нововведения для SpecFlow и сам SpecFlow, если это вообще кому-то будет нужно, кроме меня.

Представляю вашему вниманию nuget пакет с переработанным C# Allure под классический NUnit: https://www.nuget.or...a.NUnit.Allure/

.NET 4.5.x и .NET 4.5 на данный момент не поддерживаются.

Некоторые методы я видоизменил, поэтому возможно придётся немного изменить их старую сигнатуру переходя с классического аллюра. Но это не точно. 

Кратко, как использовать данный allure и его некоторые новые фишки:

1. ГЛАВНОЕ: Для включения логирования - необходимо унаследовать класс Allure.Commons.AllureReport базовым классом ваших тестов. Не нужно у каждого класса/метода писать какие-либо allure атрибуты:

public abstract class ABaseTestConfig : AllureReport

Либо непосредственно каждый класс с тестами, если базового нет.

2. Для использования своего названия Suite, нужно добавить атрибут [AllureSuiteAttribute] у класса:

[AllureSuite(LoginPassNotExists)]
public partial class MyTests: ABaseApiTestConfig

Пример:

Внутри класса у методов можно использовать атрибут [AllureSubSuiteAttribute], для разделения на более мелкие Suite’s внутри одной большой [AllureSuiteAttribute]

3. Для указания Epic Story для всего класса следует использовать атрибут [AllureEpicAttribute]:

[AllureEpic("Epic story")]
public partial class MyTests: ABaseApiTestConfig

Пример:

Соответственно, если в таком классе будут методы с атрибутами [AllureStoryAttribute], все они будут дочерними в следующем порядке:
Epic -> Feature > Story.

4. Атрибут [AllureOwnerAttribute] - устанавливает Owner’a теста\тест-кейса.

5. Если у метода указаны атрибуты [AllureIssueAttribute], то в отчете в Suite класса добавится ещё один SubSuite с названием “With Defects”, где будет список тестов/кейсов класса, в которых этот атрибут присутствует.
   Сделано для быстрого поиска тестов с дефектами в указанных классах.
   

6. Аналогично дефектам из 5 пункта, в Suite класса будут добавлены все проигнорированные тесты/кейсы этого класса (для этого ничего указывать не надо).

7. Сам игнорированный тест имеет в отчете указанную причину, по которой это произошло.

8. Добавлена перегрузка метода AddAttachment()
   Выглядит так:

public AllureLifecycle AddAttachment(string name, AttachFormat type, string content, string fileExtension = "")

Используется для добавления отформатированных аттачей (xml/json), чтобы они выглядели читабельно, а не в одну строку: 

9. Соответственно, теперь можно использовать добавление шагов/атачей в [SetUp] и [TearDown]методах.
   Пример Setup:

[SetUp]
public virtual void Setup()
{
AllureLifecycle.Instance.AddAttachment($"Screenshot [{DateTime.Now:HH:mm:ss}]",
"image/png",
Driver.TakeScreenshot().AsByteArray);
...
}

10. • Возможность использования потоков внутри одного теста для логирования в аллюр.
      Например: 

      Task.Run( () => someMethod());

      Данный метод будет иметь начальным шагом не текущий шаг главного потока, а рутовый шаг отчета.
      Если вы в этом методе будете создавать steps с substeps - они будут создаваться корректно, внутри steps своего потока.

Итд…
Если возникнут проблемы/вопросы, пишите, буду рад помочь.

Из известных проблем сейчас:

1. В отчет попадают все проигнорированные тест-кейсы из тестового класса, даже если вы запускали только один тест в нём.

За прошедшее время было выпущено много новых версий.

Текущее положение дел можно смотреть тут:

https://github.com/Noksa/Allure.NUnit

compose = driver.find_element(By.XPATH, "//span[@class = 'mail-ComposeButton-Text' and text() = 'Написать']")
compose = driver.find_element(By.XPATH, "//span[@class = 'mail-ComposeButton-Text' and contains(text(), 'Написать')]")

Данные локаторы более подвержены поломке, нежели чем 

compose = driver.find_element(By.CSS_SELECTOR, ".mail-ComposeButton-Text")

Просто хотя бы потому, что текст может поменяться, либо поменяться язык, и локаторы сломаются. 

Так что привязываться к тексту стоит только в самом крайнем случае.

А ещё лучше - просить разработчиков добавлять ID элементам. 
Тогда ваши локаторы всегда будут самыми лучшими, и короткими :)

А я всё равно задам вопрос.

Для чего нужен именно golang в тестах? Какая цель?

Лично я бы не выбирал Go для автоматизации.

Посмотрите вот это, попробуйте: https://github.com/tebeka/selenium

Скажу от себя.

 

 

создаем маленькие методы (например заполнить поле, выбрать с селекта)

Предположим, что у вас будет на странице 20 полей, которые нужно заполнить и 5 селектов, которые нужно выбрать.

Если вы будете для каждого поля делать отдельный метод, то количество методов на данной странице, помимо каких-то вспомогательных и унаследованных, будет большое количество и это не очень удобно. Количество методов не должно быть слишком большим, это очень неудобно.

Здесь можно пойти другим путём. Сделать один универсальный метод, например "fillField", который будет принимать в себя два аргумента: enum и string.

Где enum - это перечисление всех полей\селектов, которые есть на странице, а string - соответственно чем нужно заполнить\что нужно выбрать.

Ну а в теле метода уже через switch реализовать заполнение\селект конкретных полей\селектов.

В итоге у вас будет всего один метод, который работает с полями\селектами на странице.

Далее.

 

 

Жду конструктивной критики

Я сторонник PageFactory с кастомным локатором\декоратором, поэтому для меня поиск элементов через findElement и поля с типом By - это некрасиво и глаза разбегаются.

Могу привести пример, почему PageFactory лучше, на мой взгляд.

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

Есть, допустим, элемент, который появляется динамически, но точно должен появиться спустя 3 секунды.

При поиске через чистый findElement, у вас тут же будет выброшено исключение, если элемент не существует или исчез из DOM страницы.

Конечно же, вы всегда можете обернуть вызов findElement для достижения нужного результата - но это тоже на мой взгляд не оптимально.

А при использовании PageFactory и своей собственной аннотации, вы можете указать, что конкретный элемент нужно ждать 3 секунды. И если спустя эти 3 секунды он не появился - тогда будет выброшено исключение.

Либо вы можете добавить аннотацию, чтобы не выбрасывалось исключение, а просто писался варн в лог и тест шёл дальше - словом, всё что захотите.

Пример с C#:

[FindBy(Id = "date_from")]
[ElementTitle("Операции с")]
[TimeToSearch(3)]
private ADatePicker _dateFromPicker;

При обращении к этому элементу, будут предприняты попытки его поиска в течении 3 секунд. 

Или можно использовать не хардкодное значение, а ссылаться на какое-то проперти, и при его изменении оно соответственно изменится у всех затронутых элементов:

[FindBy(Id = "date_from")]
[ElementTitle("Операции с")]
[TimeToSearch(App.Properties.Timeouts.Small)]
private ADatePicker _dateFromPicker;

А так же задавать нужный polling time, да в общем-то что угодно. 

Я, например, реализовал атрибут (аннотацию) для указания родительского элемента:

[FindBy(Id = "date_from", ParentElement = dateBlockName)]
[ElementTitle("Операции с")]
private ADatePicker _dateFromPicker;

Чтобы избежать дублирования XPath.

Далее.

 

 

Создал класс BaseTest, в котором у меня реализована инициализация драйвера, также убрал SetProperty с явным указанием в нем пути к драйверу заменив его dependency WebDriverManager в pom файле. В итоге получился такой код:

Хардкод хромдрайвера и до сих пор есть необходимость всюду пропихивать экземпляр драйвера.

 

 

Мне кажется что в тестовых классах я не должен иметь возможности делать driver.findElement, driver.click и т.д. Тоесть на прямую обращаться к драйверу. Или я ошибаюсь?

И да и нет.

У вас, как ни крути, будет доступен драйвер в тестовом классе. У вас же тестовый класс наследуется от базового, в котором драйвер protected.

Просто не используйте драйвер в тестовых классах в таких целях.

 

 

 В архитектуре классов у меня есть также класс SummaryAPI. В лекции что я смотрел, от этого класса неследовались классы BasePage и BaseTest - тоесть в них была реализация чего то общего для этих двух классов, например того же метода find:

Могу сказать по себе. 

Мне пришлось форкнуть Allure под C# и реализовать в нём возможность создания\добавления шагов и аттачей в [setup] и [teardown] методах.

И чтобы не указывать в каждом тестовом классе, что этот класс должен генерить отчет, я наследую базовый тестовый класс от класса, в котором у меня реализован старт\стоп отчета и прочее.

В итоге для всех тестовых классов у меня будет создаваться отчет.

public abstract class ABaseTestConfig : AllureReport
    {
      ...
    }

Но это что касается базового тестового класса.

Для чего нужно иметь общий базовый класс и для базового тестового класса и для BasePage - честно говоря никогда не думал об этом.

Могу лишь предположить, что какие-то общие данные текущего запуска тестов \ теста, но вроде все (?) тестовые фреймворки и так это хранят в доступных через статичные классы контекстах. 

 

 

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

 

Вот здесь я не понял Вас немного. Каждый методу меня это этап бизнес процесса. Вот cardFill  - это заполнение карточки заявления. В итоге я хочу на одной ветке БП создать этот метод (так как я и сделал в классе FirstBP_OrgCreating) , а дальше наследовать все классы от этого класса, и просто вызывать этот метод. Я не могу понять чем это чревато?

 

1) Ваши классы нарушают SRP в чистом виде.

Они не выполняют одну задачу, а выполняют две - проверяют какой-то функционал и создают драйвер.

Вам нужно вынести всю логику по работе с драйвером в базовый класс для всех тестов. Всё создание драйвера и его уничтожение будет описано в одном месте.

От него и надо будет наследовать классы тестов.

В идеале это должна быть фабрика по созданию нужного драйвера.

В классах тестов не должно быть никакого упоминания о драйвере!

Сейчас у вас создание драйвера, во-первых, имеет хардкод в жесткий диск (это вообще жесть полная), во-вторых - предусмотрено создание только хромдрайвера.

И, опять же, дублирование кода создания драйвера, при этом один класс наследует другой... выглядит странным.

Чем всё это чревато? А тем, что если у вас поменяется что-то в создании драйвера, например, вам будет нужен не хром, а лиса - вам придётся это менять во всех местах.

Эту проблему вообще надо решать другим путём, конечно, это просто как пример.

2) Сейчас у вас заполнение карточки является по сути не тестом, а precondition шагом. 

В той реализации, что у вас есть - у вас все тесты будут зависеть по факту от одного теста. Зависимые тесты - это очень плохо. Если ваш первый тест не будет работать - все остальные тоже не будут работать из-за того, что они не могут выполнить precondition шаг.

В идеале, нужно уходить от такого рода шагов. Например, путём создания другого precondition шага, который будет в БД приложения записывать нужные данные, а тест уже будет их использовать.

Таким образом, если создание precondition шага в интерфейсе не будет работать - вы сможете проверить другой функционал, минуя его.

А в отдельном одном тесте уже проверять непосредственно cardFill через интерфейс.

Действия на страницах надо выносить не в базовый класс, а следовать PageObject паттерну, и выносить это в отдельные методы на конкретном pageobject'е. А в самих PageObject применять композицию для избежания дублирования кода.

Допустим, есть общее меню для всех страниц - его нужно выносить в отдельный класс (я их называю блоками) и используя композицию вносить его во все pageobject, где он присутствует.

Таким образом, элементы описанные в этом блоке - будут описаны в одном месте, и при их изменении вам нужно будет исправить их только в одном месте, а не на всех страницах.

Общее видение PageObject:

У вас есть страница Cards. 

Создаёте класс Cards, в нём создаете мелкие методы, которые делают что-то на этой странице.

Потом, если вас это не устраивает - делаете там же общий метод cardFill, который содержит в себе вызовы мелких методов, а не дублирует их логику.

А в тесте уже используете этот класс и методы из него. Здесь не нужно наследование.

Вам нужно вынести всю логику по работе с драйвером в базовый класс для всех тестов. Всё создание драйвера и его уничтожение будет описано в одном месте.

От него и надо будет наследовать классы тестов.

 

В идеале это должна быть фабрика по созданию нужного драйвера.

В классах тестов не должно быть никакого упоминания о драйвере!

 

Тут я Вас понял! Именно из за того что я создавал драйвер в каждом классе у меня и наследование не получится. 

Фабрики для создание драйверов мне не нужно - работаем только с chrome, поэтому и указал путь на ЖД. Но уже видел ссылку где это делаеться через maven, пересмотрю потом.

И да то, что в тестах не должно быть упоминание о драйвере только сейчас понял. Но так как я только начинаю работать то для меня понимание этого уже плюс)

 

Мыслите шире. Или даже так - мыслите интерфейсами. Это позволит вам писать легкоизменяемый код, который при этом не повлияет на работоспособность другого кода, который его использует.

Сейчас не нужно - а завтра будет нужно. Заказчики люди непостоянные и требования у них могут меняться каждый день :)

Лучше сразу предусмотреть возможность создания любого драйвера, чтобы потом не пришлось строить костыли.

Хороший вариант, это параметризация запуска тестов. При запуске передавать параметр - какой браузер использовать.

Таким образом, вы одновременно, например на разных машинах, сможете запустить все тесты на разных браузерах.

Дело в том что как бы я не хотел сделать тесты независимыми - этого у меня не получиться. Возьмем для примера заполнения этой карточки. От этого теста зависит выполнение всех последующих. В конце теста есть клик на кнопку, после которого отправляеться на емейл ссылка для дальнейшей работы. Поэтому если даный тест не отработает (ссылка не прийдет) то и последуюющие шаги мне выполнять не нужно. Я не смогу начать выполнять тест с 3 или 4 этапа бизнес процесса. Только в такой последовательности. Поэтому даже при запуске, для того что бы проверить например 8 сетод (завершения БП) мне нужно тест запустить с самого начала. 

public string fillCard()
{    
    this.setFieldsOnTheOrgCard();
    PopUpMessage popUpMessage = this.createButtonClick();
    return popUpMessage.getLinkFromPopUp();
} 

А в тестах используйте в первой строке:

new OrgCard(driver).fillCard()

и никакого наследования тестами других тестов.

Так же, я бы вам советовал сразу писать такую архитектуру, в которой не требуется в конструктор страницы передавать драйвер.

Т.е, в конструктор страницы вообще ничего не следует передавать.

Как вариант, использовать статичный драйвер в контейнере ThreadLocal<>.

Это моё субъективное мнение.

Пример с C#, на страницах не требуется объявлять конструктор, он вызывается из базового класса.

При этом все прекрасно бегает в параллельных потоках.

public class NewsPage : BasePage
    {
      ....
    }


public abstract class BasePage
    {
     ...

     protected BasePage()
        {
            Elements.Clear();
            ElementsInBlocks.Clear();
            PageFactory.InitElements(DriverManager.Driver, this, new AFieldDecorator());
        }

Не очень понятен вопрос, что вы понимаете под фразой "правильно написать автоматизированный тест"?

У меня, например, тест после запуска лезет в БД приложения, и если не находит там подходящие данные, грузит их туда посредством отправки запросов через апи.

Всё это в тесте выглядит как одна строка

var order = GetOrderFromDb(orders.Service._24, DBStaticDataForTests.OrdersInfo.OrderType.CourierDeliveryOnCourierAny,
true, TestsData.OrdersGoodsNum, true, false);

Что вам мешает делать нечто подобное?

Ну а внутри уже реализация может быть и громоздкой, либо опять же разбита на более мелкие вызовы.

Я конечно игры никогда не тестировал, но по-моему ни один автотест не протестирует игру так, как это сделает руками человек)

Добавлю лишь, что реализуя проверку локального диска вы получаете совершенно не контролируемую систему, так как вы не знаете о том, что ответил сервер при нажатии на кнопку, были ли в процессе скачивания какие либо проблемы, как долго ждать до завершения скачивания и тому подобные проблемы которые от вас потребуют такое кол-во костылей, что полагаться на результат теста станет невозможно.

 

Не буду вас переубеждать в этом.

 

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

 

Очень странное у вас мышление, честно говоря.

У меня кейс E2E. А вы мне предлагаете зачем-то тестировать саму возможность скачивания. Похоже это вы не понимаете о чем речь идёт.

Как я могу не знать, что ответил мне сервер, нажимая на кнопку, если я после нажатия этой кнопки вполне конкретно ожидаю начала скачивания файла и заведомо знаю, что должно быть внутри него, включая его размер?

Покрывать юнит-тестами саму возможность скачивания должен разработчик, это он разработал эту функцию. Не надо переваливать это на плечи автоматизатора.

Интересно, а "Как долго ждать до завершения скачивания по клику" чем-то отличается от "Как долго ждать до завршения скачивания по прямой ссылке"?

 Так-то это вообще не константа, может у вас вообще интернета не будет в момент скачивания. 

У меня нет ни одной проблемы пока что со скачиванием файлов через клик по кнопке, и я ни секунды лишней не жду.

Все тесты прекрасно могут хоть в 100 потоков параллельно качать файлы в одну и ту же папку и не мешать друг другу.

Если для вас это проблема и нужно городить костыли, то не надо это проецировать на других.

А вот если скачивание по кнопке отломается, но будет работать по прямой ссылке, о которой пользователь естественно не знает - что вы будете говорить в этом случае? Что само скачивание работает? Ну так а толку от этого, если пользователь это скачивание запустить не может?

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

Александр спасибо за ответ.

В том то и дело что файл может быть не скачан. Кликаем на download а в ответ тишина. 

 

Насчет подождать условные 2-3 секунды - вот тут то и основная загвоздка, что по моим наблюдениям файл начинает скачиваться как мгновенно после нажатия кнопки, так и через 10 секунд :)),  да да через 10(редко, но бывает и дольше), почему так это не ко мне, имеем что имеем, по этому ставить в "лоб" ожидание 10 секунд для каждого моего документа (а их около 200) не совсем камильфо, собственно я и думал что есть уже какое-то "умное" решение этого ожидания. 

 

В любом случае, спасибо что отозвались.

Ну здесь по-другому не получится.

Да и это не совсем в лоб.

Вы же не будете ждать каждый раз 10 секунд. Если файл начал качаться за 1 секунду - то ожидание прервется и начнется другое - ожидание завершения скачивания файла.

Если у вас файлы начинают качаться спустя 10 секунд после клика по кнопке - это проблема разработки, надо идти к ним/к начальству и просить оптимизировать. 

Предполагаю, что после нажатия кнопки "Скачать" начинается формирование файла, и после того как он сформируется - начинается скачивание, отсюда и различие в ожидании.

Ничего не мешает, кроме того что файл может быть не скачен

В каком смысле он может быть не скачан?

Я использую такой вариант:

После нажатия кнопки/ссылки начинается скачивание файла (в течении 2-3 сек).

Сам файл может качаться при этом любое время.

Ждём условные 2-3 секунды изменения количества файлов в директории загрузки.

Если по истечении 2-3 секунд количество файлов не изменилось - значит что-то пошло не так и скачивание не началось.

Если же началось, то количество файлов уже изменилось, даже если файл ещё не скачался.

Вычитаем из одной коллекции другую, получаем одно вхождение - это наш новый файл.

Далее ждём, пока он скачается целиком.

Здесь вариантов может быть много:

1)  Ждём пока у файла расширение изменится с .download/.temp/ещё какого-то на любое другое кроме этих

2) Ждём пока у файла будет конкретное расширение, если вы знаете, каким оно должно быть после скачивания.

3) Ждём пока у файла будет ожидаемый размер.

4) Итд.

 

 

Чем меньше вы работаете с окружением, а не с тестируемым приложением тем лучше. В вашем случае, я бы брал ссылку на файл и качал его напрямую питоном сверяя хеш полученного и эталонного файла, обрабатывая исключения стандартной для 3 его питона http библиотекой.

 

 

 

 

К сожалению, установка заказчика - проверять скачивание файла через сам сайт и сверять его содержимое после этого с БД. 

 

ну моё предложение не нарушает установки заказчика.

 

Ну как же не нарушает - скачивание файла по ссылке != скачивание файла по клику кнопки

Опять же, а если файл не стал скачиваться? Сколько его ждать? И если ждать то получается нужно опять принудительно выставлять максимальное время ожидания... 

 

Если файл не стал скачиваться, то это дефект, со всеми вытекающими. Сколько ждать его - это вам должно быть известно, у меня на проекте скачивание начинается в пределах 3 секунд, я это время и жду.

Если файл начал качаться позже - это уже дефект.

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

У вас в любом случае при почти любых проверках, где результат появляется не моментально есть неявные ожидания. Почему же вас это ожидание смущает именно при скачивании файла, ведь это такая же абсолютно проверка?

Либо воспользуйтесь советом человека выше.

Чем меньше вы работаете с окружением, а не с тестируемым приложением тем лучше. В вашем случае, я бы брал ссылку на файл и качал его напрямую питоном сверяя хеш полученного и эталонного файла, обрабатывая исключения стандартной для 3 его питона http библиотекой.

 

 

 

К сожалению, установка заказчика - проверять скачивание файла через сам сайт и сверять его содержимое после этого с БД. 

Спасибо за советы, в принципе картина ясна. Мне самое главное было понять как сделать правильно, и не городить огородов.   

Роман правильно написал - проверять генерацию и содержимое файла лучше через юнит-тесты - это должны делать разработчики.

Если такие юнит-тесты не написаны, значит разработчики забивают на юнит-тесты.

Я использую для переключения на новое окно такой метод:

public static void SwitchToNewWindow<T>(this T page, Action<T> action) where T : BasePage
        {
            var handlesBefore = DriverManager.Driver.WindowHandles.Count;
            action.Invoke(page);
            DriverManager.Driver.Wait()
                .Until(() => handlesBefore != DriverManager.Driver.WindowHandles.Count);
            if (handlesBefore == DriverManager.Driver.WindowHandles.Count)
                throw new NullReferenceException(
                    "Количество открытых окон в браузере не изменилось. Новое окно не открылось.");
            DriverManager.Driver.SwitchTo().Window(DriverManager.Driver.WindowHandles.Last());
        }

Соответственно работает как-то так:

Pages.GetPage<ReturnsPage>().SwitchToNewWindow(_ => _.TransferSelectedToCourier());