Дмитрий Лисичкин Tab10id

Кучу лет в openvpn-клиенте была бага не позволяющая вводить пин от рутокена если openvpn собран с поддержкой systemd (а он всегда собран с поддержкой systemd в бинарных дистрибутивах). В генту все исправляется одним USE-флагом, в остальных дистрибутивах нужно было собирать пакет самостоятельно.

Суть в том что мы хэшируем не просто номер паспорта, а номер паспорта + что-то еще, чем усложняем перебор.

Хах, хорошие коммиты кучу раз меня спасали. Любой код когда-нибудь может стать legacy-кодом (достаточно не трогать его около двух лет). И тогда только git blame сможет объяснить что имел ввиду разработчик.

Вкладки ведь в опере первыми придумали..

1. Далеко не у всех есть большой выбор профессии.
2. Может я конечно ошибаюсь, но я сильно сомневаюсь что ваш выбор развития в IT-области был обусловлен именно деньгами, скорее всего вам это направление нравилось еще со школы, а высокие зарплаты были просто приятным бонусом. Как-то не укладываются у меня в голове мысли типа: "программистам платят мало, пойду-ка я лучше в нефтянники".

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

Коллизии возможны, тест при этом падает сообщая что найдено более одного элемента. В этом случае прибегаем к помощи css/xpath (обычно все же css), но используем их для обозначения области поиска, выше приводил пример:

within('#comments') do
  click_button 'Ещё'
end

Локатор в итоге указывает на контейнер, а не на сам элемент, соответственно меньше вероятность что он изменится из-за правок верстки.
В нашем проекте, эта практика работает почти всегда.
Иногда конечно бывают исключения, но они часто говорят о проблемах юзабилити.
К примеру, тест находит 2 кнопки с текстом "Ещё", это значит что на странице действительно находится 2 такие кнопки и какую из них заметил будет нажимать пользователь — большой вопрос.
В случаях когда наличие нескольких элементов действительно оправдано (например, идентичный пагинатор сверху и снизу страницы), можно использовать уточнения:

within('.article_list') do
  click_link('следующая страница', match: :first)
end

По поводу нескольких проверок в одном тесте.
В рубишном rspec'e на этот случай есть фича aggregate_failures. При включении, в случае провала одной из проверок, тест продолжает выполнение, а потом выдает все собранные ошибки. В UI-тестах используем очень часто, в остальных случаях пригождается значительно реже.

Смотрю на ui тесты со своей колокольни (ruby web). У нас используется другой подход к проблеме локаторов (продвигаемый библиотекой capybara https://github.com/teamcapybara/capybara/blob/3.5_stable/README.md#using-capybara-with-rspec)
Если коротко, в качестве локаторов используется обычный человекочитаемый текст:

describe 'регистрация' do
  before do
    fill_in 'Имя пользователя', 'vasya_pupkin'
    fill_in 'Пароль', 'qwerty'
    fill_in 'Подтверждение', 'qwerty'
    click_button 'Регистрация'
  end

  it 'работает' do
    expect(page).to have_text('Вы зарегистрированы!')
  end
end

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

within('#comments') do
  click_button 'Ещё'
end

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

Я бы сказал что начинать нужно не с Марса=)

Спасибо! Раньше тоже накидывал план тестирования в "картах", но поддерживать было неудобно. С плагинами все должно быть получше.

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

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