Как стать автором
Обновить
25
0

Team Lead

Отправить сообщение
Ох… только решил авторизоваться на хабре, увидел ваши комментарии.
Очень рад, что мои наработки вам пригодились!
Спасибо за доброе слово!

Обертку для конкретного драйвера, думаю будем создавать по мере возникновения проблем. Обертка по сути будет полноценным Proxy классом над обычным драйвером. Мысль хорошая.
Я понял вашу идею — выглядит очень не плохо. При этом похоже на наш подход с единственным отличием — у вас страницы представлены статическими объектами и при написании тестов пользователь не думает о времени жизни страницы и пишет сценарий последовательно по шагам.

Соглашусь, что ваш код читается легче :)

protected override void Setup()
{
    dailyListPage = new LoginPage(Driver)
        .LoginAsAdmin()
        .OpenDailyList();
}

[Test]
public void DailyList_Test_Parameter_Calculation()
{
    var random = new Random();
    var v110 = random.Next(100);
    var v220 = random.Next(100);
    var gou = v110 + v220;

    Step("Блокировать документ на редактирование",
        () => dailyListPage.LockButon.Click());

    Step("Отредактировать параметр 110 и 220 за третий час",
        () =>
        {
            dailyListPage.PowerTable.EditCell(3, 2, v110.ToString());
            dailyListPage.PowerTable.EditCell(3, 3, v220.ToString());
        });

    Step("Сохранить изменения",
        () => dailyListPage.SaveButon.Click());

    Step("Измененные ячейки отмечены меткой \"есть изменения\",
        () => (dailyListPage.PowerTable.CellMarkedAsChanged(3, 2) && dailyListPage.PowerTable.CellMarkedAsChanged(3, 3)).ShouldBeTrue());

    Step("Разблокировать документ на редактирование",
        () => dailyListPage.LockButon.Click());

    Step("Проверка колонки ГОУ = 110 + 220",
        () => dailyListPage.PowerTable.Rows[3].Cells[1].Value.ShouldEqual(gou.ToString()));
}
Написал ответ вам ниже.
Звучит здорово! Хотелось бы взглянуть на пример.

Насчет DSL — немного смущает еще один уровень абстракции, о котором так же надо думать.
Работа с page object на текущем уровне тестирования для нас пока достаточна.

В комментарии выше мне уже указывали на SpecFlow. Складывается впечатление, что это уже немного другой уровень восприятия задачи тестирования как таковой и похоже мы до этого уровня пока не дошли :)
По факту Page Object файлы правятся не часто. Если все же правка необходима, то в основном все сводится к изменению селектора, что выполняется достаточно просто.

Насчет использования unit-тестов, согласен с вами — одно другое не исключает. Например, мы в работе используем как unit так и acceptance тесты.

Про категоричность и «must have» относительно приемочных тестов — тут каждый решает сам, нужно ли использовать в проекте те или иные тесты. Мою точку зрения вы поняли :) я за автоматизацию приемочных тестов, хотя бы их малой части, если нет ресурсов на выполнение такого рода задач в полном объеме.
>> Это делается вручную каждый кто хочет написать/поправить тест?

Да. Вся обвязка поднята на машине разработчика локально. Для создания теста разработчик запускает систему у себя на машине и пишет тест.

Так же есть виртуальная машина с тестовой площадкой, где поднято все необходимое окружение.
Для написания и отладки приемочного теста возможно использовать данную площадку (за исключением сценариев, когда тест «ломает площадку»).

Насчет SpecFlow — пока руки не дошли попробовать этот фреймворк в работе.
Ловите плюс в карму :)

Насчет разделения тестов и классов page-object на проекты — думаю это уже более косметический штрих, т.к. проекты будут знать друг о друге.
Вместо проектов мы группируем файлы по директориям внутри одного проекта. Не исключаю, что в итоге придем к вашему решению.

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

Согласен с вами на все 100%. Примеры, которые заливал на github были написаны на «скорую руку». Боевые классы page-object инкапсулируют в себе знания о драйвере, а наружу выставляют только свойства и методы.

Page Recorder посмотрю, выглядит заманчиво.
Видимо не правильно выразился :)
Есть физическая машина, на который установлен агент. Т.е. запуск идет на удаленной машине, не на машине разработчика.
Спасибо. Обязательно посмотрю.
У нас большинство разработчиков пишут на С#, поэтому Selenium с оберткой для .NET нам ближе.
>> — кнопку переложили в другой div и 50 тестов отлетело?
Классический пример :) ничего не отлетит, т.к. кнопки выбираются при помощи css селектора по id. Тест надо будет править, если поменялся id у кнопки. Даже не сам тест, а описание страницы PageObject.

>>— БД, как я понял, создается одна — т.е. следующие тесты могут быть затронуты изменениями в БД, сделанными предыдущими тестами?
Все верно. Пока с необходимостью создавать новую БД при определенном тест-кейсе не сталкивались. Если потребуется, то добавим команду вызова скриптов на удаление/создание БД в базовый класс теста.

>>— если уж Angular — то вроде можно контроллеры юнит-тестить, используете?
Можно, но сейчас не используем. Тесты контроллеров это как вы правильно заметили unit-тесты :) Я же хочу указать на пользу именно приемочных тестов. В моей практике не раз было, что unit-тесты отрабатывают, а самые простые пользовательские сценарии сбоят.
Да, запускается все локально при помощи агента teamcity. В сторону grid честно говоря не смотрели.

>> при написании и отладке тестов всё это проделывается вручную?
разработчик и тестировщик отлаживают тесты локально, после чего заливают в репозиторий. Сразу после заливки в репозиторий — запускается агент teamcity.
>>Насколько я понимаю вы пишете под WD.
Что такое WD?

>> Как вы используете разные браузеры: создаёте selenium grid или в коде отдельно для каждого браузера прописываете capabilities?
Для базового класса теста указан атрибут TestFixture, который передается в конструктор теста. На основе значения этого атрибута создаются различные драйвера. Например, если надо запустить тест под Chrome и IE — надо базовый класс тестов пометить вот так:

[TestFixture(«Chrome»)]
[TestFixture(«IE»)]
public class BaseTest {...}

Подробнее можно посмотреть в коде. Файл BaseTest.cs и BrowserFactory.cs.

>> Вы учитываете особенности работы реализаций драйверов?
Нет. Проверяем стандартно на IE и Chrome. Данных проверок в контексте текущего проекта достаточно.

>> Так же были случаи, когда js код добавлял атрибут к элементу дерева, после чего селениум проверял этот атрибут быстрее, чем браузер применял изменения и множество других проблем.
Интересно. Ситуация видимо не типовая, соответственно требует отдельного решения.

>> В общем подавляющее большинство проблем у нас было с Actions и подобными вещами. Интересно послушать, как вы с этим боролись, заранее спасибо.
Честно говоря, пока с такими проблемами не сталкивались.
Сервис хорош, пользуюсь им второй месяц.
Чего не хватает в скомпанованых статьях — так это оглавления.

Использую этот сервис в связке с kindle 3 следующим образом — в течение недели жму «read later» на интересных публикациях, а в выходные скачиваю с instapaper сборку и закачиваю ее на kindle.
Автоматической отправкой по 1,3,5 статей не пользуюсь — периодически глючит.
Здорово.
RSS на сайте вроде нет. Как бы отслеживать ваши релизы?
Не устраивают скоростью, и объемом информации, которую необходимо держать в памяти(чуть выше рассматривали этот вопрос).

Если рассматривать алгоритм Дугласа-Пекера, то чтобы отсечь «лишние» точки необходимо в памяти держать координаты всех предыдущих точек(по крайней мере на первом шаге), перебирать все точки ломанной, находить наиболее удаленную и т.д А Инфоконт поступают десятки тысяч таких точек каждую секунду.

Прелесть алгоритма SwingingDoor в том, что для принятия решения о записи точки не надо помнить о предыдущих данных. Алгоритм принимает решение в реальном времени, чем существенно экономит ресурсы машины.
Да, это минус алгоритма.

Для каждого параметра надо экспертным путем решать допустимое значение погрешности(пример в статье про изменения частоты на 0.01 Гц и изменение мощности на 0.1 МВт). Для реализации алгоритма в Инфоконте задача упрощается тем, что мы заранее имеем информацию о типах параметров, а для каждого типа параметра характерна своя допустимая погрешность.

Теоретически алгоритм можно модифицировать, сделав его адаптивным при помощи пересчета погрешности E для каждого нового коридора. Для этого надо ввести показатели на сколько текущая погрешность удовлетворяет нам, например, можно считать, что погрешность «хорошая» если в коридор попадает 20% точек, а если более этого, то на следующем шаге погрешность можно уменьшить на заданную величину. Но это только теоретически, опыты такие не проводили.
В примере некоторые экстремумы красной линии не совпадают с экстремумами зеленой линии, т.к. точки зеленой линии лежат в пределах заданной погрешности алгоритма.
Задумка программы хорошая, но реализация пока страдает.

Возьмите пожалуйста на заметку предложения по фичам:
* в редакторе словарей иметь возможность перемешивать слова — вряд ли кто-то захочет учить слова по алфавитному порядку;
* иметь возможность создавать словарь из .txt файла — вариант использования, я открыл специализированную статью, в которой много незнакомых мне слов, я копирую всю статью в txt файл и скармливаю его программе (или даже так — указываю урл в самой программе на статью), программа фильтрует слова по уникальности и на их основе составляет словарь.
Спасибо, что подвели итог.
Ваш комментарий, действительно, формализует то, что до этого читалось между строк в комментариях, но не было сказано прямо в самой статье.
1

Информация

В рейтинге
Не участвует
Откуда
Самара, Самарская обл., Россия
Дата рождения
Зарегистрирован
Активность