В чем проблема тестить ангуляр на пайтоне? :)

Ну разве что pytractor юзать

Не спорю, некоторые вопросы можно задать из разряда есть ли столовая и какие-нибудь доп секции. А остальное - это уже для более опытных

Он и без пайтрактора отлично тестируется.
И я как раз хотел узнать у вас в чем, по вашему мнению, там проблема.

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

Да как минимум локаторы

Прогрузка ангуляра

Джун чаще всего без понятия, какие вопросы по работе можно задать. Я так однажды в крупную фирму попала. Вышла на проект и сделала открытие, что, оказывается, вся команда разработки и техподдержки сидит на удаленке в других городах, что сильно затрудняло онбординг. На собесе мне такое спросить даже в голову не пришло. Зато потом каждый раз интересовалась, в офисе ли сидит команда :D

Я, лично, лучше подстроюсь под процессы команды, чем буду воротиться от того, что мне неизвестно. Ведь, мне не ясно где какие процессы лучше. Пару лет опыта и там можно задавать допвопросы о том, как команда работает, какие сотрудники в команде
Просто, я смотрю со стороны логичности. Разве логично узнавать то, что тебе не понятно с практической стороны? Тем более мой софт скилл позволяет найти общий язык со всеми, кроме категорично настроенных

Ну да, вот о таком не подумал. Это стоит спрашивать, а то сложновато будет :)

Будем честны, прогрузка ангуляра это десять строчек кода с ожиданием нужной проперти.
С локаторами история примерно та же.

Решается четыремя с половиной вспомогательными функциями, которые пишутся за два вечера с нуля, и за пол часа если посмотреть как это реализовано в протракторе.

Итого: любой язык с биндингами селениума отлично подходит для решения этой задачи.

Ок, зачем тогда протрактор?)

Затем, что тестировщики любят писать yet-another-useless-framework, вместо библиотек и встраиваемых функций.

Других причин его существования, в общем-то, и нет.

Можно мне недалекому, что это?

Что именно?
Ну вот есть, например, протрактор.
Это тестовый фреймворк, который обмазан поверх всё того же селениума, содержит в себе довольно спорной удобности обертки на его (селениума) стандартные ручки, и пару специфичных для ангуляра вещей.

В итоге использование протрактора подвязывает тебя на его DSL, громоздит ненужную абстракцию, подтягивает зависимости и присыпает все это особенностями реализации, с которыми придется жить.

Учитывая, что под капотом всё тот же селениум, а из специфичного для ангуляра там не так уж и много вещей, навязывается простой вопрос: зачем для всего этого фреймворк, когда можно было сделать библиотеку/пакет/модуль, который будет поддерживать совместимость с селениумом и решать одну конкретную задачу.
Сделал импорт, прокинул туда инстанс селениум драйвера - получил работающий smart wait, например.

Ответ один: про библиотеку из двух ручек не так прикольно рассказывать в резюме и на конференциях, нежели про "мы тут сделали свой тестовый фреймворк".

Я понимаю. Но опять таки, звонит мне шеф, говорит, слушай дружище, выбирай что хочешь, любой фреймворк, только объясни мне почему он самый лучший. Высше порекомендовали протрактор. Ок... Почему он самый лучший

Минусы я понял. Это ненужна я обвертка

А плюсы то в чём

Я уже сказал: лучше всего использовать тот инструмент, которым умеешь пользоваться.