neman

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

К сожалению, "правильный" ответ существует только в голове у автора задания, поэтому дать объективное решение не представляется возможным. Эта форма, очевидно, позволяет указать формулу вычисления для поля %FieldName% типа %FieldType%, вся остальная функциональность на уровне спекуляций. Загадочная фраза означает, что если значение формулы изменилось (например она зависела от текущей даты), то значение поля value тоже обновится. В противном случае оно останется таким же, каким и было. Может быть. Или нет. Кто его знает?

 

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

https://github.com/a...js/issues/10993

 

В свое время другого решения, кроме боли, страдания и retry я не нашел, потому что не мог откатиться на 1.9.8.

 

Если выводить несколько значений, то вы выводите значение таким образом для каждой строки? 

while (rs.next()) {
  String city = rs.getString(2);
  String street = rs.getString(3);
}

 

Признаться, сто лет не работал с jdbc, но да, это делается примерно так (хотя этот код конечно нерабочий из-за объявления внутри цикла). На мой взгляд лучше использовать названия столбцов.

while (rs.next()) {
  city = rs.getString("city");
  street = rs.getString("street");
}

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

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

• Чего хочет заказчик (ПМ, руководитель проектов и т.п.)? Какой конкретно результат будет считаться приемлимым?
• Из предыдущего вытекает следующий вопрос - а на основании чего было принято такое решение? Чего не устраивает сейчас и чего хочется в будущем? Является ли автоматизация оптимальным решением этих проблем? Она должна быть частью общей стратегии тестирования, сейчас очевидно это не так. 
• Каковы риски? Если текущая загрузка 100%, автоматизировать можно будет лишь за счет времени на ручное тестирование, окупится ли это? С учетом риска провала, разумеется.
• Каково качество процесса разработки? Является ли тестирование узким местом? Сколько не тестируй Жигули, они не станут Роллс-Ройсом, понимание этого тоже должно быть.

И самый главный вопрос - а тебе-то это надо? Потому что вероятность фейла в таких условиях больше 95%. Это не очень страшно, в конце концов, все запарывают свои первые проекты, вопрос в эпичности фейла. И что ты из этого выносишь.

Вообще по селениуму никогда ничего не спрашивал. Если человек умеет программировать, то разберётся быстро. В качестве тестового задания - автоматизация формы логина.

Зачем бы я стал задавать вопросы, чтобы производить впечатление на программистов? Мне с ними не детей крестить. Надо спрашивать то, что менеджер предпочел бы не афишировать: качество кода, юнит-тесты, адекватность процессов и заказчика, переработки и т.п.

Интересно. Я вижу это так. Два варианта:

1) Есть техническое требование - должен выставляться лок при таких-то условиях. Отлично. Задача для юнит-тестов. Выполняем предусловия, проверяем что запись залочена (имеет соответствующее свойство, возвращает соответствующую ошибку и т.п). 

2) Есть бизнес-требование. Примеры уже описали сами - множество пользователей, специфические сценарии и так далее. Тут мы уже абстрагируемся от терминов многопоточного программирования. Если у нас бизнес-требование "Веб-сервис должен держать 10 000 rpm" - ну ок, имитируем подобную загрузку и следим, что у нас все тип-топ. В голове мы конечно держим, что узкое место - это лок в базе, но проверяем мы конкретное требование.

 

PS: Насчет корректной реализации лока в БД. Отчасти это так, не надо проверять сторонний компонент. Тем не менее, может быть например выставлен некорректный уровень блокировки. Мне с таким довелось сталкиваться при работе с Оракловой базой. В общем автору -- если вы спрашиваете об этом на форуме, то скорее всего не сможете предусмотреть все варианты. Так что лучше отталкиваться от бизнес-требований.

Я бы разбил это на две фичи (два теста):

1. При выполнении некоторых действий приходит сообщение.
2. Cообщение отображается в интерфейсе.

Проверять в БД лучше, если:

• Мы умеем писать в БД или умеем подменять сообщения от сервиса - тогда эти фичи мы можем проверить независимо друг от друга. Т.е. во втором тесте вместо реального получения сообщения мы его подменим своим и посмотрим, как оно отображается в интерфейсе.
• У нас есть разные наборы тестов для этих двух фич. Например, сообщение вызывается разными действиями, или у него есть параметры, которые отображаются одинаково. В этом случае быстрее сгенерировать много разных сообщений, проверить что в БД лежат верные значения, а во втором тесте посмотреть, что одно из сообщений корректно отображается в интерфейсе. Здесь мы исходим из предпосылки, что смотреть в БД - это быстрее и надежнее, чем в интерфейсе.
• В приходящем сообщении есть важные параметры, которые не отображаются в UI.

Проверять только в интерфейсе, если:

• Есть проблемы с обращением к БД или с данные лежат в тяжелом для парсинга формате.
• Приходит много системных параметров, которые мы не хотим тестировать, и которые нам тяжело замокать.
• Приходит всегда одно и тоже сообщение, которое полностью отображается в UI (проверка в БД здесь не лишняя, но если это трудоемко, то игра не стоит свеч).

Может быть я еще что-то упустил.

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

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

Трудно что-то посоветовать, много неизвестных факторов (насколько крутая инфраструктура уже есть, насколько сложный проект). Могу только поделиться собственными впечатлениями. Правда сразу скажу, что писал на руби, не на питоне. Но они очень похожи по синтаксису, идеологии и экосистеме, ruby пожалуй более редкий язык, т.е. всё более хардкорно 

 

Опыт - два года автотесты на джаве (с абсолютного нуля, вся инфраструктура включая CI), затем год на Ruby. Тут чуть получше: был некоторый код, написанный профессиональными тестировщиками  .

 

Плюсы, которые я для себя отметил:

 

  + Можно писать ОЧЕНЬ красивые тесты - практически английский текст. Синтаксис способствует.

  + То что один язык - профит огромный в техническом плане (наладил кой-какую интеграцию с тестируемым приложением). 

  + С точки зрения "бэкенда" можно весьма просто делать клёвые вещи, сильно меньше служебного кода. Честно говоря, немного воротит смотреть на джаву после этого. Но тут чистая вкусовщина, за подробностями можно обратиться к любому холивару Java vs Python. 

 + WebDriver норм. За всё время пришлось портировать только одну новую и редкую фичу. Пользоваться можно, в общем. Хотя и не без глюков.

 + Скорость разработки выше, количества кода меньше.

 

Минусы:

 

  - С точки зрения ревью и поддержки разработчиками - профит вышел минимальный.

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

  - Меньше коммьюнити со всеми вытекающими. 

 

PS: В теории серверная часть селениумовской инфраструктуры независима от языка клиентских тестов, нет? Если есть селениум сервер, обращаться к нему можно с чего угодно, API то у него один. К CI, если повезет, найдется соответствующий плагин для Python... Короче говоря, ты уверен что придется инфраструктуру так уж решительно переделывать?

Найти родителя найденного узла и получить его текст. Типа

element.findElement(By.xpath("parent::*")).getText()

Это под while не поставить, т к значение null никогда не примет

Я похоже неправильно понял задачу. Кусок кода ниже периодически выполняет метод FooExecutor.foo() пока не будет найден элемент с локатором By.id("bar"). То, что надо?

public class MyExpectedConditions{
	  public static ExpectedCondition<Boolean> fooUntilBarPresent(final By locator) {
		    return new ExpectedCondition<Boolean>() {
		    	public Boolean apply(WebDriver driver) {
	    	          try{
	    		    FooExecutor.foo();
	    		    return driver.findElement(locator);
	    	          }
	    	          catch(NoSuchElementException e){
	    	  	   return false;}
	                  }
		    };
		  }
}

new WebDriverWait(driver, 10).until(MyExpectedConditions.fooUntilBarPresent(By.id("bar")));

Не, ну а что, отличная стратегия. Тесты, которые не находят баги - не нужны. Выкинем их! А если в старом функционале всплывает бага - уволим программиста. Русская разработка, бессмысленная и беспощадная.

Я, к счастью, не гуру с многолетним опытом, поэтому могу себе позволить ответить по существу вопроса.

Ничего такого особенного не делал. Опыт программирования у меня был, надо было внедрить автотесты - вперед и с песней. Так и втянулся . В принципе нравится, но прежде чем выбирать это направление, неплохо бы оглянуться и понять, насколько оно востребовано. Все-так наличие автоматизатора подразумевает команду с достаточно высокой культурой разработки. Для России, если ты не из Москвы или Питера - это пара-тройка компаний на весь город.