Приветствую друзья. Однажды задав подобный вопрос в одном из чатов telegram, я был послан в долгое эротическое путешествие в просторы интернета за ответами. Сейчас я всё же какой никакой ваш коллега. Intern AQA. Дело в том, что у меня есть старший коллега AQA но он либо занят, либо игнорирует мои вопросы, а на меня свалилась часть автотестирования нашей команды. Обратиться за помощью в общем то, больше некуда. Интернет я шерстил, но приходится информацию собирать по крупицам. Не могли бы вы ответить кратко на этот список вопросов опираясь на свой опыт, чтобы я не изобретал колесо и не тратил время выделенное мне в Jira на поиск ответов, которые давным давно найдены. Спасибо за понимание.
В чем принципиальная разница между gradle и maven ?
В чем принципиальная разница между Junit и testNG ?
Если я собираю проект на Junit, как там управлять тестами? в testNG используется testng.xml где прописаны классы для запуска. (нужно для запуска проекта из Main) так то
я обычно запускаю тесты либо по клику на шестеренке “test” maven-e, либо просто на кнопку пуска возле класса/теста.
Насколько критично указывать в pom-файле build, если тесты без него и так, в общем то, бегают?
Не получается присобачить Allure к проекту. Я видел, как Allure работает лишь при создании файла allure.properties и подтянутой dependency с Allure.
зачем тогда на некоторых видео по allure нужно качать отдельно allure себе на ПК в виде zip-файла ?
Не могу найти информацию как собрать ПРОСТОЙ проект состоящий из таких звеньев в цепочке как: Intellij IDEA - Maven - testNG - Allure (всегда одна из переменных не такая,
что по факту перечеркивает другие манипуляции) например IDE Eclipse, сборщик Gradle, библиотека Junit. Есть у кого нибудь pom-файл с минимальным набором данных, достаточных для работы c Allure?
Зачем в testNG аннотация @Description если по факту в сформированных им отчетах по прогону содержание этого описания возле тестов не отображается?
Хех, не обижайтесь, но выглядит это местами как: я очень занятой джун и мне некогда учиться самостоятельно, а тут сидит куча мне незнакомых людей с зарплатой в несколько раз выше моей и кучей свободного времени, поэтому решите за меня все мои проблемы.
Вот ваш первый вопрос:
Если я скажу, что принципиальное отличие в подходах: декларативный (maven) против императивного (gradle, точнее там микс двух подходов). Вам это как-то поможет?
Сижу каждый день по несколько часов, прохожу курсы, читаю статьи, смотрю видео, а ему видите ли надо получить ответы на те вопросы, которые в ходе обучения должны добываться. Измените свой подход к работе, потому что дальше будут проблемы более высокого уровня
По поводу отличий (2) - возможно сможешь что-то подчерпнуть из этого видео и еще и еще
Еще лучше почитать как появился JUnit4, потом как появился TestNG и потом JUnit5. И понять что для тестировщиков предложил TestNG, какие возможности в отличие от JUnit5, и что появилось нового в JUnit5.
Вопросы хорошие, сохраню себе. Но как видишь можно по-чуть чуть копать
На Вашем уровне - ни в чём. Оба инструмента одинаково юзабельны. Делал проекты и на том, и на этом.
Аналогично.
Предлагаю найти этот ответ в базовой секции документации JUnit. Какое-нить howto, overview и т.д. Нет смысла задавать вопрос, ответ на который можно получить самому в 2 мин.
Если бегают - не задавайте. Делайте так, как умеете. Когда дойдёте до граблей - посмотрите, почему они возникли и скорректируете.
Вообще ни о чём не говорит. Что не получается-то?
Зачем вообще задавать вопросы 1 и 2, если из вопроса 6 следует, что в выборе технологий Вы ограничены? А переписать зависимости из мавена в грэдл - вообще не проблема… В плане pom-ника - я уверен, что в официальной документации аллюра всё есть.
description – The ‘description’ attribute is used to provide a description to the test method. It generally contains a one-liner test summary. @Test(description = "Test summary")
Тут ничего не сказано о том, что этот атрибут работает в репорте. С чего Вы решили, что должен?
P.S. Я понимаю, почему Ваш коллега Вас игнорит. Я бы тоже с такими вопросами игнорил.
Что плохо:
В вопросах нет конкретики. “Не получается” - как комьюнити должно угадать причину проблем? Магически по фотографии?
Некоторые вопросы типа 1 и 2 заданы без видимого смысла.
Ответы на часть вопросов можно найти в гугле, даже не напрягаясь.
Часть вопросов выглядят как “сделайте за меня мою работу, а я в джире время залогаю”. Задача джуна - учиться и находить ответы на свои вопросы, а не копипастить готовые решения, выдавая их за свои. Начните с того, что почитайте документацию по грэдлу, мавену и тест раннерам. Чтобы вообще осознать, что это такое и зачем нужно. Как появятся вопросы по существу - спросите коллег. Не смогут ответить - приходите сюда.
Неверно. DevOps - это вообще не про тест раннеры и сборщики. DevOps - это про поддержку процесса сборки продукта: все эти пайплайны, виртуальные машины, энвы и т.д.
Уметь управлять процессом сборки и запуска своего проекта - прямая задача автоматизатора.
Не умеете - учитесь. Не хотите - тогда Вам в AQA просто не место.
То, что Вас на курсах ничему не научили - не повод для того, чтобы не читать документацию самостоятельно.
Спасибо за фидбэк и ответы. Я здесь за поиском информации без изобретения колёс, и ясное дело что людям, имеющим колоссальный опыт за плечами вычленять в интернете нужную информацию гораздо легче. Но мне кажется в этом и заключено главное когнитивное искажение - с точки зрения опыта перечисленные проблемы кажутся плёвыми. А когда ты делаешь всё по уроку, а потом возникает конфликт, решение которого ты не можешь найти - возникает ступор.
Опять же, здесь идет конфликт интересов свитчеров и людей на опыте 5-10 + лет.
Уметь управлять процессом сборки и запуска своего проекта - прямая задача автоматизатора.
В IDE у меня как раз всё собрано и работает)
Не умеете - учитесь. Не хотите - тогда Вам в AQA просто не место.
То, что Вас на курсах ничему не научили - не повод для того, чтобы не читать документацию самостоятельно.
В IT ведь существует система грейдов, не так ли. Полагаю что по-хорошему, я не должен (Intern/Junior) с наскоку выйдя на проект(не один причем) должен уметь внедрять (ключевое слово) свои тестовые проекты транслируя их на workflow всей фирмы, разбираясь во всех тонкостях фреймворков и сборщиков а так же тонкостях и способах внедрения тестов на проект?)
Как бы там ни было, мне хочется и придётся всё это освоить
Вы же и запускать теперь их всегда будете в своей IDE? И работу сдавать в таком виде? Ночные прогоны тоже лично будете запускать? Именно в таком виде у вас и будут принимать работу?
По поводу Intern’ов, то моё сугубо личное мнение, что основное чему должен научиться Intern - это научиться учиться.
testomat.io управление авто тестами
Буду изучать предложенные материалы.