1. Скорее «это не покрыто» или «это недопокрыто». Например частный кейс — проверка под авторизацией или с конкретными тестовыми данным.
2. Еще пытаемся использовать когда баг пропущен и нужно посмотреть «тестировалось это или нет»
В самом начале статьи я говорю, что метрика формального покрытия не работает в большинстве случаев. И здесь наши мысли сходятся.
Дальше я сообщаю, что при большом количестве тестов и участников команды встает вопрос о том, какие тесты есть, а каких нет.
Имея на входе эти два пункта я делаю следующий вывод: покрытие само по себе интересно, но текущая его реализация (через линии кода) не работает.
Следом я предлагаю сдалеать следующий трюк: за основу «покрытия» беру более высокоуровневую составляющую продукта, а не строку кода. Например:
1. вызовы Rest API
2. конкретный элемент на странице
3. твой вариант
И в конце я показываю, как могло бы выглядеть покрытие в этом случае.
И теперь вопрос, с чем ты споришь?
Если ты считаешь, что покрытие по строкам не работает, я с тобой согласен.
Если тебе не важно покрытие, то не делай так. Возможно у нас отличаются условия.
Если тебе не нравится конкретная реализация, то расскажи как бы ты это сделал.
В данном случае менеджер — это роль. Можно подразумевать руководителя тестирования, менеджера продукта и всех тех, кому интересно состояние продукта с точки зрения тестирования.
Наличие этой информации помогает им понимать какая часть продукта тестируется и/или не тестируется, точнее составлять планы на расширение покрыти и расставлять приоритеты.
Эти инструменты просто визуализируют то, что проверяется в тестах. Ровно как джира визуализирует то, что будет разрабатываться в ближайшее время.
Мы использовали обычный Listener, который есть в каждом фреймворке. Во время действия с элементом мы берем полный селектор этого элемента и страницу, на которой было выполнено действие.
Хороший вопрос.
Прямого упоминания слова «DevOps» ни в одной лекции вы не найдете.
Представим DevOps как пересечение разработки, тестирования и эксплуатации, прям как в wiki, да. Задача DevOps — сделать процесс поставки ПО состоящим из понятных частей, связанных ясным образом.
В лекциях мы рассказали об инструментах, с помощью которых можно эту задачу решить. А именно, автоматизировать процесс поставки ПО от коммита до продакшена.
Конкретный конвейер участники школы изобретают сейчас в рамках практики.
Практика закончится в конце января. Примерно в это же время появится пост, в котором я расскажу детали.
То ли это был хабра-эффект, то ли метеорит упал на датацентр, в котором стояла моя железяка, но ci.qatools.ru временно не работает.
Вы всегда сможете построить отчет из исходников.
Если github.com будет работать, конечно)
Ого, ты меня опередил) Я тебе респектую от души и согласен с каждым твоим словом)
Вот это вообще топ:
Ты без автоматизации будешь неконкурентноспособным, просто не сможешь держать темп.
2. Еще пытаемся использовать когда баг пропущен и нужно посмотреть «тестировалось это или нет»
Дальше я сообщаю, что при большом количестве тестов и участников команды встает вопрос о том, какие тесты есть, а каких нет.
Имея на входе эти два пункта я делаю следующий вывод: покрытие само по себе интересно, но текущая его реализация (через линии кода) не работает.
Следом я предлагаю сдалеать следующий трюк: за основу «покрытия» беру более высокоуровневую составляющую продукта, а не строку кода. Например:
1. вызовы Rest API
2. конкретный элемент на странице
3. твой вариант
И в конце я показываю, как могло бы выглядеть покрытие в этом случае.
И теперь вопрос, с чем ты споришь?
Если ты считаешь, что покрытие по строкам не работает, я с тобой согласен.
Если тебе не важно покрытие, то не делай так. Возможно у нас отличаются условия.
Если тебе не нравится конкретная реализация, то расскажи как бы ты это сделал.
Наличие этой информации помогает им понимать какая часть продукта тестируется и/или не тестируется, точнее составлять планы на расширение покрыти и расставлять приоритеты.
Эти инструменты просто визуализируют то, что проверяется в тестах. Ровно как джира визуализирует то, что будет разрабатываться в ближайшее время.
Прямого упоминания слова «DevOps» ни в одной лекции вы не найдете.
Представим DevOps как пересечение разработки, тестирования и эксплуатации, прям как в wiki, да. Задача DevOps — сделать процесс поставки ПО состоящим из понятных частей, связанных ясным образом.
В лекциях мы рассказали об инструментах, с помощью которых можно эту задачу решить. А именно, автоматизировать процесс поставки ПО от коммита до продакшена.
Конкретный конвейер участники школы изобретают сейчас в рамках практики.
Практика закончится в конце января. Примерно в это же время появится пост, в котором я расскажу детали.
yadi.sk/d/CVmVoRYBdPRpn
Вы всегда сможете построить отчет из исходников.
Если github.com будет работать, конечно)
java.lang.AssertionError: Expected: <Wednesday> but: <Saturday>