Небольшое отступление: Буквально пару месяцев назад у меня была прекрасная возможность начать автоматизацию с нулю в компании, где её вообще не было на моём любимом языке - C#. Пошуршав в интернетах, я понял - что, в принципе, на C# нет в опенсорсе достаточно мощного и удобного фреймворка написанного для использования со SpecFlow (либо я его не нашёл).
К сожалению, на C# подобного я не нашёл и решил сам написать аналог. Но, обстоятельства сложились так, что от BDD отказались (слава Богу, на мой взгляд), и я начал допиливать классический фреймворк, забросив specflow. Но, учитывая что он всё же уже был написан, я решил его возродить и поддерживать, т.к. уже накопилось много плюшек, которые можно реализовать в нём. (Проект фреймворка: https://github.com/Noksa/AAA)
Но, чтобы не заниматься этим просто так, я решил провести опрос.
Нужен ли конкретно вам подобный фреймворк и будете ли вы им пользоваться?
Да, нужен.
Попробовал(а) бы.
Нужен, но переход с существующего фреймворка слишком затратен.
Скачал и запусти ваши тесты, результат выполнения нашел только в тестовой консоли(надеюсь это пытается распарсить результаты, которых я не смог найти):
Allure + Nunit + Specflow - по моему, это слишком. Раньше использовал Nunit + Specflow. Через некоторое время Nunit выкинул - проще обновлять один фреймворк, чем сразу два(или больше).
Русский язык для написания фич и для сообщений о ошибках - ваш фреймворк, смогут испольовать только в проектах для стран бывшего СССР)
P.S. Код должен читаться как книга, а не как ребус. Возможно, это классный код, но как вы думаете, какой порог входа в ваш фреймворк? Какими минимальными знаниями должен обладать автоматизатор?
Попытаюсь ответить на ваши не заданные и заданные вопросы.
Попробуйте запустить студию под админскими правами, если запускаете тесты в ней. Это поможет. У меня была похожая проблема, которая сама рассосалась и я не смог найти в чем была причина, т.к. она исчезла. Видимо, не на совсем…
Аллюр отвечает за отчеты. NUnit за запуск тестов. (Хотя, по большому счету, NUnit можно заменить на любой другой тестовый фреймворк, с которым дружит SpecFlow). Ну а SpecFlow - понятное дело, за сами тесты.
Это недолго исправить, если в этом будет необходимость.
Для того, чтобы использовать этот фреймворк, вам достаточно просто добавлять свои методы. Вам нет необходимости лезть во внутреннюю кухню, зачем Вам это?
В самом фреймворке есть всего два места, куда вы можете добавлять core-steps.
Класс с самой высокоуровневой абстракцией - CoreSteps.cs. С этого места начинается каждое действие в ФФ. Я для примера туда написал далеко не все возможные варианты.
может выглядеть в ФФ в зависимости от действия так:
И пользователь (заполняет поле) "Логин" значением "Мой логин"
или так:
И пользователь (заполняет поле) "Логин" "Мой логин"
или так:
И пользователь (сравнивает текст элемента) "Логин" со значением "Это не мой логин"
Все эти действия будут обработаны вышеуказанным методом. И там таких методов много, но, возможно, не все.
Второе место - класс BasePage. Какие-то общие действия, которые встречаются чаще всего во многих проектах. Например такой метод:
[ActionTitle("заполняет поле")] public virtual void FillField(string elementTitle, string value) { var element = (AProxyElement) GetElementByTitle(elementTitle); element.Clear(); element.SendKeys(value); AllureSteps.AddSingleStep($"Поле '{elementTitle}' заполнено значением '{value}'."); }
Этот метод можно использовать в любом из методов в классе CoreSteps.cs.
Т.е. метод, помеченный атрибутом [ActionTitleAttribute] можно поместить в скобки методов из CoreSteps.cs.
Например:
[StepDefinition("^пользователь \\((.*)\\) из таблицы$")] public void ExecuteMethodByTitle(string actionTitle, Dictionary<string, string> dict) { PageManager.PageContext.CurrentPage.ExecuteMethodByTitle(actionTitle, dict); }
Метод из BasePage.cs:
[ActionTitle("заполняет поле")] public virtual void FillField(string elementTitle, string value) { var element = (AProxyElement) GetElementByTitle(elementTitle); element.Clear(); element.SendKeys(value); AllureSteps.AddSingleStep($"Поле '{elementTitle}' заполнено значением '{value}'."); }
Всё вместе это будет выглядеть так:
И пользователь (заполняет поле) из таблицы |Поле |Текст | |Логин |МойЛогин | |Пароль |МойПароль|
Естественно, у метода (заполняет поле) должна быть перегрузка с Dictionary. Вот она:
public virtual void FillField(Dictionary<string, string> dictionary) { foreach (var keyValuePair in dictionary) { var element = GetElementByTitle(keyValuePair.Key) as IWebElement; element.SendKeys(keyValuePair.Value); AllureSteps.AddSingleStep($"Поле '{GetElementByTitle(keyValuePair.Key)}' заполнено значением '{keyValuePair.Value}'."); } }
Все остальные локальные методы, в том числе и их перегрузки - вы можете писать конкретно в pageobject и в блоках в конкретном проекте. При необходимости изменения где-то локально общих методов из ядра - просто оверрайдить их, если они работают иначе (не писать новый с атрибутом - а просто оверрайднуть) Фреймворк найдет их.
В ядре, по задумке, хранятся только общие действия, которые есть везде, и все они помечены как virtual, для того, чтобы можно было изменить реализацию на конкретной странице, если классическая не работает или работает не так, как задумано.
Каков минимальный уровень знания у автоматизатора должен быть - достаточный для того, чтобы он мог писать свои методы и помечать их атрибутом ActionTitle в ядре / в своих проектах. А так же при необходимости дописывать core steps или изменять их, в данном случае так же знать регулярки.
У меня где-то завалялась презентация по этому фреймворку, если хотите, могу найти, там более понятным языком всё описано.
Что значит фреймворк со спекфлоу? Забиндженные шаги кликов и прочих экшенов?
То есть хочется написать свои хардкодные шаги? и на русском языке? Не, я понимаю, что в атрибут можно написать все что уогодно, но русский язык это… ну короче не для всех
Все давно есть. Плагин для спекфлоу, который в конце теста записывает JSON файлы Аллюра. Какой раннер будет у спеклофлоу - без разницы.
Угу. Что-то типа этого на Java => GitHub - sbtqa/page-factory: Java framework for functional UI test automation in the BDD style Где для старта написания авто-тестов не нужно ничего делать, кроме как подключить либу с фреймворком и написать ФФ с экшенами, попутно естественно создав pageobjects. Понятно, что всё равно какие-то экшены будут свои и их придётся дописывать - либо в ядро либо в проект конкретного приложения, но это вопрос наполнения, который легко решается.
Ну, написать можно сразу на нескольких языках, просто добавив много атрибутов с соответствующей фразой, хоть на всех языках мира. Просто я не стал заморачиваться и написал только русский язык
А так методы могут выглядеть так:
[ActionTitle("заполняет поле")] [ActionTitle("fills field")] [ActionTitle("füllt das Feld")] public virtual void FillField(string elementTitle, string value) { var element = (AProxyElement) GetElementByTitle(elementTitle); element.Clear(); element.SendKeys(value); AllureSteps.AddSingleStep($"Поле '{elementTitle}' заполнено значением '{value}'."); }
ну и так далее, тоже самое и для coresteps.
На мой взгляд куда проще использовать что-то универсальное для всех проектов и уже готовое, чем писать свои экшены, которые делают тоже самое.
Если только вы занимаетесь написанием тестов в BDD стиле, то конечно всё это не имеет смысла. (хотя тогда и BDD не имеет смысла)
Посыл фреймворка же здесь такой, что ваш словарь действий будет одинаковым для всех проектов, за исключением индивидуальных под проект действий (коих обычно бывает немного). А это в свою очередь позволит пользователям писать ФФ на любом проекте используя общий словарь действий, а не искать в конфлюенсе словарь под каждый проект со своим стилем написания действий и объяснением что же это действие делает.
Например пользователь просто будет знать, что в любом проекте достаточно написать фразу
Если же действия описываются для каждого проекта конкретно свои, то пользователю придется знать стиль написания/название экшена.
Ну а реализация самого действия может за счет виртуального метода меняться от проекта к проекту или от страницы к странице, но пользователь, который пишет ФФ этого знать не будет, для него всё равно текст действия везде будет оставаться таким же.
Если надо оверрайднуть метод(ы) для всего проекта в целом, а не для конкретной страницы/блока, то, если мне не изменяет память, созданием одного базового класса сейчас не обойтись, т.к. их нужно будет два - для блоков и для страниц, в них овверайдить методы, и уже от них наследовать блоки/страницы. Но я давно не смотрел уже, если действительно нужно два класса - то, конечно, это требует изменения.
