А все операции с jacoco через java -jar обусловлены тем, что код тестов java приложений на разных уровнях написан на разных языках (видимо интеграционные на python)? В обратном случае все можно уложить в фазы самих тестов:
...
import org.jacoco.core.tools.ExecDumpClient;
import org.jacoco.core.tools.ExecFileLoader;
...
import org.junit.jupiter.api.AfterAll;
import java.io.File;
import java.io.IOException;
import java.util.concurrent.atomic.AtomicInteger;
public class IntegrationTestBase {
private static final AtomicInteger coveragePart = new AtomicInteger(0);
...
@AfterAll
public static void tearDown() throws IOException {
readJacocoDump("./build/jacoco/integrationTest." + coveragePart.get() + ".exec",
getDockerServiceHost(...),
getDockerServicePort(..., JACOCO_PORT));
...
}
private static void readJacocoDump(String destPath, String host, Integer port) throws IOException {
final ExecFileLoader loader = new ExecDumpClient().dump(host, port);
loader.save(new File(destPath), true);
}
...
В индустрии все очень быстро меняется - это правда. И ВУЗы из-за своей процессуальной инертности просто не могут поспевать за этими переменами... Вот только по опыту выпуска с последнего фото из статьи сложилось понимание, что матан не сильно-то и изменился за эти 13 лет... Принципы архитекруры реляционных баз - тоже. Да и ООП по большому счету все на тех же китах стоит как не удивительно. Не говоря уже о физике контактов и переходных процессов в электронике;) Многие скажут что эти вещи им даром не сдались для, к примеру, javascript и будут правы. Подход обучения на практических задачах/проектах позволяет за короткое время войти в отрасль - примеров адекватных выпускников курсов Я* и других подобных площадок вокруг хватает. Только вот из-за отсутствия знаний в соседних областях давать им архитектурные задачи в сложных проектах уже не получится в большинстве случаев... ВУЗ должен научить учиться - в отрасли всегда полезный навык. И как бонус - дать широкую базу чтобы понимать "почему". По факту оба подхода нужны: как для поиска ответа можно прочитать томик Таненбаума или выбрать stackoverflow, так и для решения бизнесовой задачи можно нанять отучившегося в университете или прошедшего узконаправленный курс за год - все зависит от горизонта планирования и сложности решаемых задач :) П.С.: Все ждал в первой части алаверды Павлу Леонидовичу, но что-то видимо не срослось...;)
И вообще, зачем читать лекцию, если он сам умеет читать, ваш ровесник? Можно же просто сказать, где и что прочесть.
Вот здесь может быть скрыта вся проблемность ситуации. 1. В совсем немалом количестве компаний архитектура решений увы выстроена не как надо (и описано в профильных статьях), а как получилось. И передавать знания таких костылей придется именно в личном общении. И здесь конкретная организация может просто оказаться в ситуации что их лид не может что-либо обьяснять старшим коллегам (не умеет, не хочет и т.д.) - согласитесь что им проще будет найти кандидата более удобного для компании. 2. Популярные несколько лет назад team-building-и по уму строятся в том числе на основе внерабочих интересов команды. Не исключаю негативный опыт вечеринки, где какой-то 30-летний старикан не захотел у них одеваться феечкой как все... Хотя лично предпочитаю верить в "Стажёр" с Де Ниро :)
В статье был очень важный момент, который нужно добавлять в каждый коммент в ее поддержку: говорится о статистическом большинстве. Да, каждый сам может подобрать и прочитать нужную книгу. Некоторые еще и по второй теме. Еще чуть меньший процент - и третью... В итоге "потолок" каждый устанавливает для себя собственной мотивацией. И вот личная профильная статистика за последние 7 лет к сожалению не дала ни одного "самоучки", который бы дорос до senior, но дает несколько примеров с вышкой. И как бы мне не хотелось поработать с человеком с "незашоренными глазами", с точки зрения бизнеса эффективнее оказывается выставлять оговорку об образовании в вакансии дабы сократить расходы на проведение собеседований и дальнейшее дообучение сотрудников.
Тут вот какой инфоцыганский фокус: если взять пример студии из 3 человек, что клепают двустраничные лендинги на продажу, то скрам у них зайдет на ура со всеми представленными в статье моментами:) А дальше уже этот "успешный кейс" будут натягивать на все глобусы в поле видимости независимо от исходных данных по взаимозаменяемости специалистов в команде, присутствия тестирования и наличия клиенстких обращений для не-стартапа.
Аллегорию с авто начал глава вашей практики :) Иными словами мы каждый день запсукаем сьюты с различным колличеством исполняющих потоков, но первый поток лопатит один тестовый класс два часа, а два других заканчивают свою пачку классов за 30 минут. Компетенции middle автоматтизатора вполне хватит чтобы на Listener и примерах из stackoverflow запилить сервис по рекомендациям распределения конкретных тестов по классам для экономии времени. Такая задача и полезна в реальной жизни, и хоть немного интересна :) Просто как пример)
Я конечно понимаю такую постановку ограничений чтобы покушать и поболтать, но всеже солидарен с отказавшимся командами: намного интереснее было бы впилить систему обнаружения того же парковочного места для машины (на которой каждый день передвигаешься) :)
Раздувание количества людей в команде не идет на пользу — рабочие встречи на большее количество участников начинают идти медленнее, появляются роли модераторов встреч.
Всегда существует вариант не собирать всю толпу, а только лидов для синхронизации, или вовсе отказаться от бюрократических встреч;)
Расширяет широту мысления, прокачивает разработчика — помимо навыков QA, будет более полная декомпозиция будущих проектов, более точные временные оценки задач.
Ну ладно когда из backend пытаются сделать fullstack-программиста, но
Дешевле обучить разработчиков тестированию, нежели увеличивать бюрократию.
вы правда не задумывались о закладываемой мине в виде несовместимости психотипов и образа мышления в программировании и тестировании?
Если такие вопросы задаются при собеседовании человека с >3 лет реального опыта — возможно да. Для новичков в отрасли тестирования они просто могут помочь понять произошла-ли уже проф. деформация мышления, т.е. остановится-ли человек на условной перепроверке шагов воспроизведения из дефекта или все же полезет щупать потенциально затронутые области.
подготовка к рабочему дню и планирование его;
Не работает для распределенных команд, где есть хотябы 2-3 часовая разница. оценка предыдущего своего рабочего дня;
Ну если таковая кому-то нужна… По крайней мере стоит обосновать данный пункт для остальных:) поделиться информацией и планами с коллегами;
В команде, где все и чтецы, и жнецы, и музыканты — ок, в остальных случаях рентабельность достаточно низкая. получить информацию от коллег, которая может пригодится в течение рабочего дня.
Рассмотрим с двух сторон: 1) озвучивая информация в теории может быть кому-то окажется полезна — хорошо, никогда не выясняли реальный процент полезной информации для всех участников?;)
2) перед концом рабочего дня обнаружить глобальную проблему и рассказать о ней на митинге с утра может оказаться достаточно тяжелым ударом для проекта… Если есть информация или вопрос важный для вас — может стоит научиться спрашивать и рассказывать сразу?:) Не отвлекать коллег показыванием фотографий котиков, а реально передавать необходимую информацию с минимальными задержками.
Согласен что при обосновании целей применительно к конкретной команде такие летучки могут быть полезны (например для подстегивания определенных сотрудников), но стоит задуматься что мотивация может быть достигнута и другими способами:)
Вы проделали серьезную работу! Обратите пожалуйста внимание на несколько пунктов:
Автотест должен создаваться максимально быстро на сколько это возможно. Если добиться этого качественно, то остальные аспекты, такие как надежность и удобство использования, должны прийти сами собой.
Если вы подразумевали под «надежностью» стабильность теста, то к сожалению встречаются ситуации, при которых свинью подкладывает архитектура или реализация тестируемого приложения. Например, зависящая от ветра на Марсе пустая страница после прохождения авторизации:)
Тесты должны быть объявлены декларативно и жить отдельно от кода
Вы не смотрели на Cucumber? Его определенно легче читать чем xml, который вам так не нравится.
НЕ оборачивать свою систему в тестовый фреймворк
Дело ваше, но терять столько готовых плюшек как возможность автоматического перезапуска упавшего теста (для устранения шума), параллельное исполнение тестов из коробки, механизмы группирования тестов для временного отключения, приоритезация исполнения, подготовка данных вне теста, своевременное закрытие сессий WebDriver'a и т.д. просто жалко терять — всетаки советую посмотреть в эту сторону:)
Отказ от использования оберток для селениума.
Вам приводили пример Selenid'a: суть не в обретке для обертки, а в уменьшении вашего же когда. Пример — клик по элементу. В классическом Selenium вы руками прописываете метод ожидания видимости (кликабельности) элемента на странице и только потом делаете клик по нему, а здесь просто пишите element.click(), который это сделает для вас.
Красивое оформление результатов не нужно… мне нужно знать 2 вещи: общий результат (положительный/отрицательный), и, если была ошибка – где именно. Возможно еще надо вести статистику.
А вот еще одна штука, которую дало бы вам использование фреймворка бесплатно — тоесть даром:) Создаваемые по умолчанию отчеты того же TestNG решают все поставленные вами задачи, а еще и легко интегрируются в CI без единой строчки кода.
Для работы приложения на ПК должен быть установлен браузер FireFox версии выше 52
не баловался с selenium server.
Вы совершенно правильно идете — останется только оценить возможности того же Selenoid'a и все закрутится еще интереснее.
Думаю ко многим идеям из комментариев вы бы постепенно пришли самостоятельно после определенного количества шишек и граблей — в любом случае удачи! :)
А все операции с jacoco через java -jar обусловлены тем, что код тестов java приложений на разных уровнях написан на разных языках (видимо интеграционные на python)?
В обратном случае все можно уложить в фазы самих тестов:
В индустрии все очень быстро меняется - это правда. И ВУЗы из-за своей процессуальной инертности просто не могут поспевать за этими переменами... Вот только по опыту выпуска с последнего фото из статьи сложилось понимание, что матан не сильно-то и изменился за эти 13 лет... Принципы архитекруры реляционных баз - тоже. Да и ООП по большому счету все на тех же китах стоит как не удивительно. Не говоря уже о физике контактов и переходных процессов в электронике;)
Многие скажут что эти вещи им даром не сдались для, к примеру, javascript и будут правы. Подход обучения на практических задачах/проектах позволяет за короткое время войти в отрасль - примеров адекватных выпускников курсов Я* и других подобных площадок вокруг хватает. Только вот из-за отсутствия знаний в соседних областях давать им архитектурные задачи в сложных проектах уже не получится в большинстве случаев...
ВУЗ должен научить учиться - в отрасли всегда полезный навык. И как бонус - дать широкую базу чтобы понимать "почему".
По факту оба подхода нужны: как для поиска ответа можно прочитать томик Таненбаума или выбрать stackoverflow, так и для решения бизнесовой задачи можно нанять отучившегося в университете или прошедшего узконаправленный курс за год - все зависит от горизонта планирования и сложности решаемых задач :)
П.С.: Все ждал в первой части алаверды Павлу Леонидовичу, но что-то видимо не срослось...;)
А подскажите пожалуйста чем такая мешанина ожиданий обусловлена?
Этот скрипт планируется запускать на единственной машине?
Все же в блоке "Тестирование безопасности" стоит корректнее использовать термины соотвествующей области.
Вот здесь может быть скрыта вся проблемность ситуации.
1. В совсем немалом количестве компаний архитектура решений увы выстроена не как надо (и описано в профильных статьях), а как получилось. И передавать знания таких костылей придется именно в личном общении. И здесь конкретная организация может просто оказаться в ситуации что их лид не может что-либо обьяснять старшим коллегам (не умеет, не хочет и т.д.) - согласитесь что им проще будет найти кандидата более удобного для компании.
2. Популярные несколько лет назад team-building-и по уму строятся в том числе на основе внерабочих интересов команды. Не исключаю негативный опыт вечеринки, где какой-то 30-летний старикан не захотел у них одеваться феечкой как все...
Хотя лично предпочитаю верить в "Стажёр" с Де Ниро :)
К сожалению и про такое отношение в отрасли приходилось слышать, но от подобных организаций сам всем желаю держаться максимально далеко.
В статье был очень важный момент, который нужно добавлять в каждый коммент в ее поддержку: говорится о статистическом большинстве.
Да, каждый сам может подобрать и прочитать нужную книгу. Некоторые еще и по второй теме. Еще чуть меньший процент - и третью... В итоге "потолок" каждый устанавливает для себя собственной мотивацией. И вот личная профильная статистика за последние 7 лет к сожалению не дала ни одного "самоучки", который бы дорос до senior, но дает несколько примеров с вышкой. И как бы мне не хотелось поработать с человеком с "незашоренными глазами", с точки зрения бизнеса эффективнее оказывается выставлять оговорку об образовании в вакансии дабы сократить расходы на проведение собеседований и дальнейшее дообучение сотрудников.
Тут вот какой инфоцыганский фокус: если взять пример студии из 3 человек, что клепают двустраничные лендинги на продажу, то скрам у них зайдет на ура со всеми представленными в статье моментами:) А дальше уже этот "успешный кейс" будут натягивать на все глобусы в поле видимости независимо от исходных данных по взаимозаменяемости специалистов в команде, присутствия тестирования и наличия клиенстких обращений для не-стартапа.
К сожалению по части тестирования у них очень сомнительная экспертиза - большинство статей на хабре кричит об этом.
Аллегорию с авто начал глава вашей практики :) Иными словами мы каждый день запсукаем сьюты с различным колличеством исполняющих потоков, но первый поток лопатит один тестовый класс два часа, а два других заканчивают свою пачку классов за 30 минут. Компетенции middle автоматтизатора вполне хватит чтобы на Listener и примерах из stackoverflow запилить сервис по рекомендациям распределения конкретных тестов по классам для экономии времени. Такая задача и полезна в реальной жизни, и хоть немного интересна :) Просто как пример)
Я конечно понимаю такую постановку ограничений чтобы покушать и поболтать, но всеже солидарен с отказавшимся командами: намного интереснее было бы впилить систему обнаружения того же парковочного места для машины (на которой каждый день передвигаешься) :)
Ну слишком медленно же было - вот изменения и подоспели :)
Но ведь 2.0 как минимум с 2017 года не развивается?..)
Всегда существует вариант не собирать всю толпу, а только лидов для синхронизации, или вовсе отказаться от бюрократических встреч;)
Ну ладно когда из backend пытаются сделать fullstack-программиста, но
вы правда не задумывались о закладываемой мине в виде несовместимости психотипов и образа мышления в программировании и тестировании?
Не работает для распределенных команд, где есть хотябы 2-3 часовая разница.
оценка предыдущего своего рабочего дня;
Ну если таковая кому-то нужна… По крайней мере стоит обосновать данный пункт для остальных:)
поделиться информацией и планами с коллегами;
В команде, где все и чтецы, и жнецы, и музыканты — ок, в остальных случаях рентабельность достаточно низкая.
получить информацию от коллег, которая может пригодится в течение рабочего дня.
Рассмотрим с двух сторон: 1) озвучивая информация в теории может быть кому-то окажется полезна — хорошо, никогда не выясняли реальный процент полезной информации для всех участников?;)
2) перед концом рабочего дня обнаружить глобальную проблему и рассказать о ней на митинге с утра может оказаться достаточно тяжелым ударом для проекта… Если есть информация или вопрос важный для вас — может стоит научиться спрашивать и рассказывать сразу?:) Не отвлекать коллег показыванием фотографий котиков, а реально передавать необходимую информацию с минимальными задержками.
Согласен что при обосновании целей применительно к конкретной команде такие летучки могут быть полезны (например для подстегивания определенных сотрудников), но стоит задуматься что мотивация может быть достигнута и другими способами:)
Если вы подразумевали под «надежностью» стабильность теста, то к сожалению встречаются ситуации, при которых свинью подкладывает архитектура или реализация тестируемого приложения. Например, зависящая от ветра на Марсе пустая страница после прохождения авторизации:)
Вы не смотрели на Cucumber? Его определенно легче читать чем xml, который вам так не нравится.
Дело ваше, но терять столько готовых плюшек как возможность автоматического перезапуска упавшего теста (для устранения шума), параллельное исполнение тестов из коробки, механизмы группирования тестов для временного отключения, приоритезация исполнения, подготовка данных вне теста, своевременное закрытие сессий WebDriver'a и т.д. просто жалко терять — всетаки советую посмотреть в эту сторону:)
Вам приводили пример Selenid'a: суть не в обретке для обертки, а в уменьшении вашего же когда. Пример — клик по элементу. В классическом Selenium вы руками прописываете метод ожидания видимости (кликабельности) элемента на странице и только потом делаете клик по нему, а здесь просто пишите element.click(), который это сделает для вас.
А вот еще одна штука, которую дало бы вам использование фреймворка бесплатно — тоесть даром:) Создаваемые по умолчанию отчеты того же TestNG решают все поставленные вами задачи, а еще и легко интегрируются в CI без единой строчки кода.
Вы совершенно правильно идете — останется только оценить возможности того же Selenoid'a и все закрутится еще интереснее.
Думаю ко многим идеям из комментариев вы бы постепенно пришли самостоятельно после определенного количества шишек и граблей — в любом случае удачи! :)