О Рейли вообще плохих книг не выпускают, на моей памяти. :)

по питону не совсем понравилась

Ну, это не значит, что книга плохая.

да. других по питону не читал

вот по паттернам у них клёвая

Питоновская тоже хорошо заходит, если прямо с нуля учишься. Она, в принципе, сильно похожа на джава хед ферст по структуре. Мне её было скучновато читать, т.к. половину описанного уже знал по аналогии с другими языками, надо было только синтаксис языка натянуть. А так книжка вполне дельна для супер-джунов.

Раз разговор о питоне зашёл , было бы неплохо узнать годный материал по нему)

Раз разговор о питоне зашёл , было бы неплохо узнать годный материал по нему)

плюсую

Раз разговор о питоне зашёл , было бы неплохо узнать годный материал по нему)

Hitchikers Guide to Python, книги ОРейли.

Hitchikers Guide to Python, книги ОРейли.

а, я не эту читал

Не, первое это не книга, это сайтик.

ааа

ты про эту говорил?

http://shop.oreilly.com/product/0636920036777.do Более простая, с задачками и прочим.

http://shop.oreilly.com/product/0636920028154.do Более академичная и поинтереснее.

А эта как? http://shop.oreilly.com/product/0636920042921.do

http://shop.oreilly.com/product/0636920028154.do Более академичная и поинтереснее.

вот я с этой начал

тогда всё понятно

Ну, их правильнее в обратном порядке читать. :)

Для старта на питоне вот этот ресурс тоже неплох: http://pythontutor.ru

Ну, их правильнее в обратном порядке читать. :)

я позже узнал о серии head first, когда за джаву сел

http://python-guide-pt-br.readthedocs.io/en/latest/

Я думал это только сайт, а оказывается и книжка О Рейли по этому делу тоже есть. :)

а по sql эта серия книг кто то читал?

У него норм программа, но как преподаватель он мне категорически не понравился. Но это субьективное.

у него и программа такая себе, во всяком случае питон не питоничный у него :(

у него и программа такая себе, во всяком случае питон не питоничный у него :(

Питон не видел, только жаву проходил, и то 4 года назад.

но это было 3 года назад, может что поменялось

а больше всего бомбит с того что все уроки на винде

Ну, это логично, на самом деле. На винде это сложнее всего настраивать. :D

Одно прописывание envов чего стоит.

а, вот оно как :D

Раз разговор о питоне зашёл , было бы неплохо узнать годный материал по нему)

Читал Dive into Python, Learning Python, Programming Python , Learn Python The Hard Way) и имхо лучшее - это Погружение в Питон + Fluent Python

Вопрос по окружениям. 1. Прод. Актуальные данные, 2. Стейдж. Актуальность данных отстает от прода на день, или неделю. 3. Тест - какое-то синтетическое окружение-песочница которая постоянно сбрасывается в какое-то синтетическое состояние модифицирующееся в зависимости от роста количества фич

а где вопрос?)

да, заинтриговал и молчит)

Вопрос по окружениям. 1. Прод. Актуальные данные, 2. Стейдж. Актуальность данных отстает от прода на день, или неделю. 3. Тест - какое-то синтетическое окружение-песочница которая постоянно сбрасывается в какое-то синтетическое состояние модифицирующееся в зависимости от роста количества фич

Да.

Вопрос по окружениям. 1. Прод. Актуальные данные, 2. Стейдж. Актуальность данных отстает от прода на день, или неделю. 3. Тест - какое-то синтетическое окружение-песочница которая постоянно сбрасывается в какое-то синтетическое состояние модифицирующееся в зависимости от роста количества фич

нет

а где вопрос?)

discuss

лiл

нет

А как?

но так-то скорее нет чем да, набор данных вообще не показатель тестового инстанса

или нетестового :) у кого-то прод и не прод базы вообще не пересекаются

и это нормально, да.

потому что если у вас например какое-то ПО по обзвону, и на стейдже/деве будут данные с продакшна, разработчики могут случайно обзвонить продакшн базу

или нетестового :) у кого-то прод и не прод базы вообще не пересекаются

вообще не пересекаются, отдельные планеты

потому что если у вас например какое-то ПО по обзвону, и на стейдже/деве будут данные с продакшна, разработчики могут случайно обзвонить продакшн базу

На самом деле не могут, конечно, но это ладно. :)

неплохо

Ну, я к тому, что проблемы того, что разработчики могут обзвонить реальных клиентов не должны решаться на уровне данных в БД.

Они должны решаться за счет изолированности тестового контура.

тут всё оч зависит от процессов. Как эффективнее и лаконичнее решается, так и надо решать.

Нет, не зависит. Отсутствие данных в БД не решает этой проблемы вообще.

Оно её, в лучшем случае, отсрочит.

ну, раз вы так говорите -_-

Ну, а какая разница будет ли телефон реального человека добавлен путем дампа базы с продакшена, или он будет добавлен автотестами\юнитами\манки-тестерами в ходе отладки?

разница в масштабе например

Если с тестового окружения звонок уходит на не-тестовое - это уже косяк by design.

Я почти уверен, что мой скрипт регистрации способен нагенерить больше телефонных номеров, чем реальные пользователи.

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

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

тесты, куски, что %) очень много каких-то предположений

А я согласен

тесты, куски - все так и есть

за хождение тестовой среды в продакшн нужно отрывать руки

никакие процессы этого оправдать не могут :)

Подскажите в testrail есть теги или что то подобное? У меня кейс который относится к А, но частично затрагивает и Б, и я подумал что можно к этому кейсу поставить тег Б, и при необходимости сделать выборку по всему что связанно с Б

ERROR: S client not available

или такое лучше делать через кастомный “type”

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

для тестирования мейл сервисов в таком случае реальные данные пользователей (почтовые ящики) можно модифицировать, чтобы письма вместо боя уходили на свой собственный мейл сервер. В этом случае это тоже заранее поднятный мейл-сервер заглушка, указание константы в конфиге сервера + в кроне когда каждый день делаются свежайшие данные с боя для тестового контура - ряд миграций накатывает такие "защитные" изменения для тестового дампа. Нет НИКАКИХ принципов того, КАК ты будешь изолировать тестовый контур от реального мира. Хочешь заморочиться БД миграцией для подмены домена в поле "email" - хорошо. Хочешь имитировать реальный домен и перехватывать письма, прописав себя в DNS, при этом данные оставляя в базе нетронутыми - пожалуйста. Все упирается в то, насколько devops готово помочь тестированию в создании того или иного образа тестирования. Нужно знать что делаешь и всё :)

для тестирования мейл сервисов в таком случае реальные данные пользователей (почтовые ящики) можно модифицировать, чтобы письма вместо боя уходили на свой собственный мейл сервер. В этом случае это тоже заранее поднятный мейл-сервер заглушка, указание константы в конфиге сервера + в кроне когда каждый день делаются свежайшие данные с боя для тестового контура - ряд миграций накатывает такие "защитные" изменения для тестового дампа. Нет НИКАКИХ принципов того, КАК ты будешь изолировать тестовый контур от реального мира. Хочешь заморочиться БД миграцией для подмены домена в поле "email" - хорошо. Хочешь имитировать реальный домен и перехватывать письма, прописав себя в DNS, при этом данные оставляя в базе нетронутыми - пожалуйста. Все упирается в то, насколько devops готово помочь тестированию в создании того или иного образа тестирования. Нужно знать что делаешь и всё :)

всё так

> Нет НИКАКИХ принципов того, КАК ты будешь изолировать тестовый контур от реального мира. Хочешь заморочиться БД миграцией для подмены домена в поле "email" - хорошо. Это не дает изолированности. Вообще.

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

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

Если честно то я не представляю как живут питонолюди без private переменных

отлично живут, умные питонолюди придумали нейминг конвенцию для этого

если уж хотят показать, что это private method и лучше его переиспользовать в паблик методе

Так это же костыль. А что если человек по ошибке заюзает "приватный конвенциональный" метод?

потому что подразумевается, что ни один идиот не будет ТЕСТОВЫЙ код ломать на предмет выхода из сандбокса и обращения к приватным полям объекта

Полагаться всегда на сознательноть и квалификацию программиста это странно

Так это же костыль. А что если человек по ошибке заюзает "приватный конвенциональный" метод?

смотрим п.1 - Питон пишут для умных людей а не для "IDE не подставило мне все методы ааааа, что мне делать, я не знаю, как посмотреть сигнатуру метода!"

полагаться на IDE в 10\10 случаях странно.

Так тут же не на IDE полагаются а на семантику самого языка. Он не пропустит.

делать умные изоляции прекрасно, если ты собираешься нанять десять обезьян тестировщиков, которые делают все по инструкции, даже тесты пишут

Если честно то я не представляю как живут питонолюди без private переменных

зачем они вообще?

Просто я сталкивался с рефакторингом 100500 строчек кода, когда на каждой переменной ищешь find usages в проекте и находишь сотню-другую вхождений. И когда видишь что перед переменной или перед методом private стоит то это прямо как бальзам на душу что метод можно смело удалить.

Так как он гарантированно нигде не мог быть использован.

И того, всё сводится к тому, что "У нас контур не изолирован, но не один идиот не будет за его пределы выходить".

Это примерно то, про что я и говорил.

смотрим п.1 - Питон пишут для умных людей а не для "IDE не подставило мне все методы ааааа, что мне делать, я не знаю, как посмотреть сигнатуру метода!"

Ha-ha~

Так тут же не на IDE полагаются а на семантику самого языка. Он не пропустит.

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

Почему нет? :)

Тривиальные случаи рассматривать не интересно, в них всегда все легко и понятно.

Стопэ, а как пейджобжект влияет на необходимость изолировать тестовый контур?

обсуждение языка немного выходит за рамки QA

это был "пример"

того, что в питоне нет изоляции, и все хорошо и никто не жалуются при должном уровне сознательности

защита от дурака и прочие violations - violations всегда по факту принятого разгильдяйства либо умышленного желания причинить зло

в тестировании примем, что в тестовом контуре злодеев нет, остаются тоьлко несмышленые ждуны, которые переписывают в БД имейлы на реальные и отправляют людям реальные письма :)