azShoo

Не совсем понимаю, зачем вам 200 виртуалок, если вы тестируете клиентскую часть?

Николай Сидельников, если английский позволяет, то я бы советовал начать с понимания пайтона и ООП на примере codecademy.
После этого любой запрос типа Python + Selenium Tutorial\уроки\етк вернет вам целую кучу видео и текстовых материалов, которые примерно одинаковы по содержанию.

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

sinneren, Ну, первое что выдал мне гугл по такому запросу:
www.automationtestinghub.com/selenium-headless-chr...

Данил Чекалин, это сильно зависит от приложения и его специфики.
Как вы понимаете, интернет-банк не должен держать сессию живой максимально долго, а условный Spotify - должен.
В случае с телеграмом это очевидный security reason, гарантирующий что логинящийся имеет доступ к телефону, к которому привязан аккаунт. Но сессия, AFAIK, у них живет бесконечно, пока её не оборвут разлогином\обрывом сессии с другого аккаунта.
В случае с условной онлайн игрой - это будет явный оверхед и боль пользователей.

Выглядит как типичное тестовое задание.
Правильный ответ: сесть и написать.

ероха елдобаев, жабоскрипт - король фронтенда. На этом всё.
Его можно относительно не испытывая агонии использовать для бэкенда.
С его помощью возможно делать некое подобие мобильных приложений.

Тем не менее, адекватной альтернативы нативной разработки под мобильные платформы пока нет, и в обозримом будущем не предвидится.

Владимир Дубровин, А автограф дадите? ;3

Я думаю смысл задания в том, что бы вы подумали своей головой, а не спросили на тостере.

Меня немного смущает фраза про "прогоняет тесты после внедрения фичи".
После её внедрения будет поздновато уже что-то прогонять.

Вы немного странно понимаете ТДД.

SEOVirus, AFAIK это сильно зависит от.
Например, Сишные компиляторы по умолчанию (а может и не только по умолчанию) заменяют все комменты вайтспэйсом.
В то время как в некоторых других языках (напр. для C#) есть отдельные флаги компиляции, задающие подобное поведение.

Хотя, могу ошибаться, безусловно.

SEOVirus, Как это зачем? Задать ложный след, конечно же.

Вадим Егоров, Дело не совсем в обфускации. Цель обфускации - сделать код максимально нечитаемым.
Цель подмены кодировок - убрать девайсо\платформо-специфичное указание на автора кода.
Напр. некоторые IDE любят по дефолту сохранять латиницу в одной кодировке, а текстовые редакторы - в другой.
Но, как вы понимаете, это была немного гиперболизированная ирония на тему параноить - так до конца.

Если модуль теста имеет внутреннюю логику - он должен быть покрыт тестами, не зависимо от того, происходит это из-за обращений во вне или нет.
Можете почитать Clean Code и классику TDD, порождает отличное понимание того, что такое unit в коде.

Аллегория ваша не может быть верна, потому что юнит тесты _не должны_ тестировать систему (т.е. автомобиль), тем более с точки зрения пользователя (автомобилиста). Для этого есть функциональные и end-to-end тесты.
Юниты тестируют систему изнутри, декомпозируя её на минимально возможные логические участки (юниты).
В этом их смысл.

Можно очень долго обмазываться ddd, bdd и прочими подходами, иерархию тестов это никак не меняет. Тесты разных уровней проверяют разные вещи и предназначены для разных целей.

Вот этот пассаж довольно спорный, с точки зрения тестирования:

В этом случае писать юнит-тест необходимо на класс Order. Необходимости в тестировании класса LineItem нет, так как он является составной частью класса Order. Такие классы носят название - Агрегат. Когда автосалон вас приглашает на тест-драйв автомобиля, то это предполагает тестирование Агрегата в целом, то есть Автомобиля. Тестировать отдельно составные его части такие как колеса/двигатель мы не будем.

Во первых, ваша аллегория в корне не верна, т.к. тестирование автомобиля в целом никак не попадает под юнит тестирование.
Во вторых, само утверждение, что LineItem не требует тестирование может быть верным или не-верным, в зависимости от. Если LineItem являет собой простую модель данных и не несет в себе внутренней логики, то тесты на данную структуру действительно не нужны.
Если же внутри класса есть логические операции (начиная с методами в её неймспейсе и далее), то покрывать их юнитами нужно. Т.к. тестировать их в рамках Route нарушит принцип изолированности модульных тестов, т.к. тест выйдет за пределы используемых внутри него операций.

Николай Сушко, Мой поинт был в том, что вместо прохождения сертификации следует потратить время\силы\деньги на то, что бы стать, как вы выразились "хорошим тестером".
Способов получения знаний и навыков - масса, и мне кажется что сертификация - не самый подходящий из них, т.к. она не для этого создана (она, всё таки, для валидации знаний, а не её получения).

Николай Сушко, Честно говоря, прошелся глазами по sample questions для тест менеджерского теста.
Это действительно уже не пустое заучивание терминов, но учитывая предполагаемый бэкграунд участников это категорически не серьезно.
Половина вопросов просто очевидна исходя из здравого смысла, половина вопросов весьма спорная (напр. те участки, которые касаются review и метрик\репортов). Плюс к этому оно всё настолько узко-ситуативно, что практической пользы, кмк, от этого реально мало.
Ну, т.е. это, во первых, не уровень test manager, а скорее обычного миддл специалиста обладающего здравым смыслом.

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

Николай Сушко, Прекрасно знаю, что такое ISTQB, знаний там ноль.
К тестированию имею непосредственное отношение.

rmfalx, Это не было аргументацией "за" или "против".
Каждый сам для себя решает, насколько это может ему пригодится.
Я, например, не вижу смысла для себя в этой сертификации, хотя есть вероятность того, что именно она встанет между мной и работой моей мечты в каком-нибудь там будущем (хотя вряд ли, лол).

Полезность любой "бумажки" довольно сомнительна, будь это диплом о высшем образовании, ISTQB, любая другая сертификация или приз за лучший нижний брейкданс в вашем дворе.
Основной смысл прохождения сертификации - подготовка к оной дает возможность хорошо структурировать знания в своей голове, освежить всё это в памяти и (если повезет) даже осознать и применять в будущем.
Бумажка это только приятный бонус, компенсирующий то, что в принципе вы могли и без сертификации всё это скачать, прочитать и выучить.

Насколько вам, с образовательной точки зрения, будет полезно пройти ISTQB узнать довольно просто - в интернете уже выложен миллион опросников с прошлых лет: попробуйте пройти один из них и понять, насколько эта область знаний для вас размытая.
Если вопросы вызывают затруднения - возможно подготовка к сертификации позволит глубже покопаться во всем этом и получить полезные знания (хотя, как я уже говорил, на мой взгляд ISTQB слишком сконцентрирован на терминологии вместо решения задач).
Если вы и так все это знаете - то вряд ли.
От этого уже и стоит плясать.