Простите за глупый вопрос, пытался сделать как на картинке, что б линтер не только подсвечивал проблемное место, но и рядом писал описание проблемы. IDE - PyCharm Если кто напишет в двух словах, буду сильно благодарен
1) Время деплоя не тривиально, но можно посчитать. Во многих статьях по метрикам даются примеры. Это может быть как время между 2мя соседними релизами, там и время между началом работы над релизом и его деплоем.
2) А не получился ли этот плагин «выстрелом себе в ногу».
У вас 2 основных цели: сократить время деплоя и сократить затраты аппаратных ресурсов на прогон автотество
— по первому пункту без замера времени на деплой невозможно ответить, но можно представить себе ситуацию, когда время затраченное на «промежуточные прогоны» превышает время, которое тратиться на приведение тестов к зеленому состоянию во время ревью
— по второму пункту — по вашим графикам видно что кол-во запусков тестов выросло в 3-4 раза, соответственно и траты на аппаратные ресурсы выросли
Одним словом придется искать якорь (отправную точку) и далее работать по пикселям
В любом случае спасибо, интересный инструмент. Пополню свою «теоретическую» базу инструментов им, может когда-нибудь получится и на практике с ним поработать.
1 Подход понятен, хорошо что есть такие возможности. Только меня смущает синтаксис (я бы назвал его смешанным) и если инструмент предназначался для людей, незнакомых с языками программирования — такие конструкции будут им не совсем понятны. Но опять таки, это тот случай где я могу выразить критику, но не предложить что-то взамен.
2 Можно разбить вопрос на 2 ситуации:
— например у нас есть таблица со списком сотрудников, вверху названия полей (Имя, Фамилия, Должность) и мы должны заполнить ее. Как будет обращение к N-ой ячейке в столбце «Имя» например
— взять ситуацию, когда у таблицы нет названий столбцов и полей. Можно вместо таблицы взять любую игру, типо сапера или крестики-нолики. Как будет идти обращение к ячейке и как ваш движок находит понятие «ячейка»
Вкину свое мнение, как автотестровщик:
Крайне «больно» писать системные тесты на ранних этапах разработки какого-нибудь функционала. Он часто меняется и не стабилен, поэтому часто приходится оставлять работу на половину, а потом возвращаться к дописыванию этих тестов после того, как фича будет более менее дописана, протестирована и исправлена.
На этапе же старта приложения запускать Е2Е тесты попросту не на чем.
К тому же написание Unit-тестов в некоторых случая помогают ускорить написание самого кода модуля. И во вторых Unit-тесты могут улучшить саму архитектуру приложения в целом и качество написанного модуля в частности. При написании тестов может стать очевидным, что модулем пользоваться просто неудобно.
Поэтому на мой взгляд ответом на вопрос «С чего начинаются тесты» должно быть — тесты начинаются с момента разрабокти приложения, Е2Е тесты на старте — это просто спецификация, за реализацией дело не стоит. Unit-тесты на старте — вполне оправданы. Поэтому стоит их начинаться писать одновременно, спецификации — аналитики или тестировщики, unit — разработчики
Такой пользовательский вопрос:
Например нам надо нажать на кнопку старт, а их несколько на экране?
Или необходимы тестировать протестировать приложение с таблицей, где много однообразных ячеек?
Для целостности статьи я бы добавил еще пример практического использования данной модели. Как получить оценку какого-нибудь нового фильма, на ее основе.
А работать когда?
Спасибо
Простите за глупый вопрос, пытался сделать как на картинке, что б линтер не только подсвечивал проблемное место, но и рядом писал описание проблемы.
IDE - PyCharm
Если кто напишет в двух словах, буду сильно благодарен
Но откуда вы взяли //[@my_menu_item]?
Модели советских машин, которые так и не увидели свет
Или фантазии на тему, какими могли бы они быть в «идеальном мире»
2) А не получился ли этот плагин «выстрелом себе в ногу».
У вас 2 основных цели: сократить время деплоя и сократить затраты аппаратных ресурсов на прогон автотество
— по первому пункту без замера времени на деплой невозможно ответить, но можно представить себе ситуацию, когда время затраченное на «промежуточные прогоны» превышает время, которое тратиться на приведение тестов к зеленому состоянию во время ревью
— по второму пункту — по вашим графикам видно что кол-во запусков тестов выросло в 3-4 раза, соответственно и траты на аппаратные ресурсы выросли
В любом случае спасибо, интересный инструмент. Пополню свою «теоретическую» базу инструментов им, может когда-нибудь получится и на практике с ним поработать.
2 Можно разбить вопрос на 2 ситуации:
— например у нас есть таблица со списком сотрудников, вверху названия полей (Имя, Фамилия, Должность) и мы должны заполнить ее. Как будет обращение к N-ой ячейке в столбце «Имя» например
— взять ситуацию, когда у таблицы нет названий столбцов и полей. Можно вместо таблицы взять любую игру, типо сапера или крестики-нолики. Как будет идти обращение к ячейке и как ваш движок находит понятие «ячейка»
Крайне «больно» писать системные тесты на ранних этапах разработки какого-нибудь функционала. Он часто меняется и не стабилен, поэтому часто приходится оставлять работу на половину, а потом возвращаться к дописыванию этих тестов после того, как фича будет более менее дописана, протестирована и исправлена.
На этапе же старта приложения запускать Е2Е тесты попросту не на чем.
К тому же написание Unit-тестов в некоторых случая помогают ускорить написание самого кода модуля. И во вторых Unit-тесты могут улучшить саму архитектуру приложения в целом и качество написанного модуля в частности. При написании тестов может стать очевидным, что модулем пользоваться просто неудобно.
Поэтому на мой взгляд ответом на вопрос «С чего начинаются тесты» должно быть — тесты начинаются с момента разрабокти приложения, Е2Е тесты на старте — это просто спецификация, за реализацией дело не стоит. Unit-тесты на старте — вполне оправданы. Поэтому стоит их начинаться писать одновременно, спецификации — аналитики или тестировщики, unit — разработчики
Например нам надо нажать на кнопку старт, а их несколько на экране?
Или необходимы тестировать протестировать приложение с таблицей, где много однообразных ячеек?