В целом со статьёй согласен, мелкие нюансы не вижу смысла обсуждать, за исключением одного тезиса:
Писать тесты на том же языке, что и тестируемое приложение;
Тут очень важно уточнить, что это оправданно до тех пор, пока соблюдаются остальные принципы, то есть пока код и отчёт о тестовом прогоне читаются лучше, тесты пишутся быстрее, работают стабильнее и покрывают больше значимых сценариев. В случае с нативным языком разработки это далеко не всегда соблюдается, и чем выше по пирамиде, тем справедливее это утверждение. Потому что начиная интеграционного уровня мы начинаем работать с "чёрным ящиком", и там на передний план выходят все остальные аспекты написания автотестов.
Я бы сказал, что в большинстве случаев тесты верхних уровней лучше писать на Питоне. Потому что, во-первых, язык сам очень лёгок в освоении и гибок, а главное - позволяет писать фичи быстрее любого другого языка, в том числе за счёт просто гигантского набора библиотек на все случаи жизни. И во-вторых - не придумано ещё ни в одном другом языке такого же удобного и гибкого тестового фреймворка, как pytest. В связке с allure это настолько удобное средство для запуска и анализа, что писать тесты и разбирать результаты прогонов получается куда проще и быстрее, чем на любом другом языке.
Например, если писать тесты чёрного ящика на php, JS, Java, Go, получится либо намного более многословно, либо значительно сложнее, либо и то, и другое. Писать на этих языках интеграционные тесты и end-to-end можно, но гораздо сложнее поддерживать и расширять, чем на связке Питон + Пайтест.
В общем, мой пойнт таков: чем выше по пирамиде, тем лучше отвязаться от языка разработки и использовать тот язык, который удобнее. Под "удобнее" можно понимать очень многое - например, если сложно найти грамотного питониста, зато в команде полно гошников, то, конечно же, лучше писать на том языке, который понимает команда. Но в отдалённой перспективе всё-таки лучше заморочиться и нанять отдельных специалистов, способных писать быстрые и понятные тесты с помощью универсальных инструментов. А уж их задача будет предоставлять команде результаты в таком виде, чтобы легко было анализировать результаты прогонов в CI.
Потому что testsuite_logger у нас уже в переменной plugin, зачем же ещё раз вытаскивать из неё одноимённый аттрибут? Имею в виду, что в коде получается, что мы возвращаем testsuite_logger.testsuite_logger.
Один наш кандидат добавил в тестовое и логирование, и потоки, и даже скромный нагрузочный тест (хотя всего этого в задании не требовалось), но, к сожалению, не прошел, так как с полнотой покрытия его тесты не справлялись. Возможно, если бы он сфокусировался сперва на кейсах, а потом уже на демонстрации остальных своих умений и возможностей, сейчас у меня был бы крутой коллега.
В целом статья интересная, с некоторыми пунктами согласен, но вот с этим не согласен прямо сильно. Я не считаю, что задача в тестовом - обеспечить максимальное покрытие. Если у вас иначе, это стоит прямо явно обозначать кандидату. Дело в том, что время на выполнение тестового всё-таки ограничено. В реальной жизни я бы, например, потратил на покрытие данного функционала тестами N времени, потому что мне за это платят, а в случае с тестовым я готов бесплатно потратить только N/4. То есть тестовое для меня - это некое демо того, что я могу. А в демо логично постараться показать максимум своих возможностей, пройдясь по ним по верхам. Я считаю, что имеет смысл скорее показать владение несколькими эффективными подходами, уделив каждому немного внимания, чем максимально покрыть функционал однотипными тестами. А то, что тут можно ещё и это проверить, и то, и вот это, можно просто обозначить одной строчкой, например - сделать кучку пустых тестовых функций с названием и без реализации или даже комментарием написать. Я почти не сомневаюсь, что вы сделали глупость, упустив того потенциального коллегу, который показал вам широту взглядов и умений вместо того, чтобы закапываться в очевидные для него вещи.
В целом со статьёй согласен, мелкие нюансы не вижу смысла обсуждать, за исключением одного тезиса:
Писать тесты на том же языке, что и тестируемое приложение;
Тут очень важно уточнить, что это оправданно до тех пор, пока соблюдаются остальные принципы, то есть пока код и отчёт о тестовом прогоне читаются лучше, тесты пишутся быстрее, работают стабильнее и покрывают больше значимых сценариев. В случае с нативным языком разработки это далеко не всегда соблюдается, и чем выше по пирамиде, тем справедливее это утверждение. Потому что начиная интеграционного уровня мы начинаем работать с "чёрным ящиком", и там на передний план выходят все остальные аспекты написания автотестов.
Я бы сказал, что в большинстве случаев тесты верхних уровней лучше писать на Питоне. Потому что, во-первых, язык сам очень лёгок в освоении и гибок, а главное - позволяет писать фичи быстрее любого другого языка, в том числе за счёт просто гигантского набора библиотек на все случаи жизни. И во-вторых - не придумано ещё ни в одном другом языке такого же удобного и гибкого тестового фреймворка, как pytest. В связке с allure это настолько удобное средство для запуска и анализа, что писать тесты и разбирать результаты прогонов получается куда проще и быстрее, чем на любом другом языке.
Например, если писать тесты чёрного ящика на php, JS, Java, Go, получится либо намного более многословно, либо значительно сложнее, либо и то, и другое. Писать на этих языках интеграционные тесты и end-to-end можно, но гораздо сложнее поддерживать и расширять, чем на связке Питон + Пайтест.
В общем, мой пойнт таков: чем выше по пирамиде, тем лучше отвязаться от языка разработки и использовать тот язык, который удобнее. Под "удобнее" можно понимать очень многое - например, если сложно найти грамотного питониста, зато в команде полно гошников, то, конечно же, лучше писать на том языке, который понимает команда. Но в отдалённой перспективе всё-таки лучше заморочиться и нанять отдельных специалистов, способных писать быстрые и понятные тесты с помощью универсальных инструментов. А уж их задача будет предоставлять команде результаты в таком виде, чтобы легко было анализировать результаты прогонов в CI.
Кажется, в этом фрагменте возвращаемое значение должно быть другим:
Потому что testsuite_logger у нас уже в переменной plugin, зачем же ещё раз вытаскивать из неё одноимённый аттрибут? Имею в виду, что в коде получается, что мы возвращаем testsuite_logger.testsuite_logger.
В целом статья интересная, с некоторыми пунктами согласен, но вот с этим не согласен прямо сильно. Я не считаю, что задача в тестовом - обеспечить максимальное покрытие. Если у вас иначе, это стоит прямо явно обозначать кандидату. Дело в том, что время на выполнение тестового всё-таки ограничено. В реальной жизни я бы, например, потратил на покрытие данного функционала тестами N времени, потому что мне за это платят, а в случае с тестовым я готов бесплатно потратить только N/4. То есть тестовое для меня - это некое демо того, что я могу. А в демо логично постараться показать максимум своих возможностей, пройдясь по ним по верхам. Я считаю, что имеет смысл скорее показать владение несколькими эффективными подходами, уделив каждому немного внимания, чем максимально покрыть функционал однотипными тестами. А то, что тут можно ещё и это проверить, и то, и вот это, можно просто обозначить одной строчкой, например - сделать кучку пустых тестовых функций с названием и без реализации или даже комментарием написать. Я почти не сомневаюсь, что вы сделали глупость, упустив того потенциального коллегу, который показал вам широту взглядов и умений вместо того, чтобы закапываться в очевидные для него вещи.