Вот и подъехали коментарии вида "я вообще не понимаю чем занимается электрик, но хороший сантехник заниматься электрикой не захочет, значит оно уныло, нет творчества и перспектив нет".
Не надо так :-)
Вы сами себе противоречите.
Подпись под картинкой: "Одна выделенная стрелочка — один поход — одна проверка в unit тесте"
Практика есть у вас, судя по статье(хотя я спрашивал про интеграцию, а не про юнит, ну да ладно):
"В итоге спустя пару месяцев, я сама немного пишу юнит тесты и удаляю избыточные проверки на верхних уровнях"
Это тоже очень сильное заявление, которое больше запутывает, чем дает понимания того, что вы делаете и зачем это надо.
В отрыве от контекста и без понимания как эффективно(а не тестировщик глазами) мапить юниты на, как минимум, интеграционные говорить о целесообразности такого подхода нельзя(если только мы не говорим о продукте где не предъявляются высокие требования к качеству).
Добрый день.
В статье полностью подменено понятие юнит-тестов.
То что у вас нарисовано на картинке — это интеграционное тестирование сервисов на бэкэнде.
Не ясно почему этим занимается/занимался разработчик. QA у вас не пишет автотесты на бэкэнд?
Не могу понять, какая связь между темой статьи и этими тестами? Это какая-то обязательная часть методологии?
Очень удивлен, что представитель почты россии не ответил через год после написания поста или просто не сообщил, что у него обед. :-)
Не смог удержаться, простите. Готов получить порцию минусов.
В статье упущено много опций, например, про тестируемые конфигурации в GUI тестах (как пример тестирование мобильных приложений и взаиможействие с ОС) это сильно изменит процентное соотношение, или наличие отдельной бизнес-логики на стороне клиента и т.д.
Если кратко, то да, этот подход будет действенен для какого-либо проекта, но реальность намного сложнее и не все так просто.
Мне кажется, на тему сроков, ответ должен быть примерно такой: Разработка концепции, выбор инструментов, разработка, интеграция с внутренними сервисами компании, функциональное и нефункциональное тестирование, багофикс.
Я имею ввиду фанатиков, которые используют технологию просто потому что это «круто», «кошерно», «good way», «true» и т.д. И используют ее к месту и не к месту.
А то о чем говорите вы — это именно хорошие узкоспециализированные специалисты, но такие спецы всегда знают что можно ждать от смежных технологий и решений, в отличии от фанатиков.
Хороше сравнение, спасибо. Многим будет полезно. Единственное с чем не очень согласен, это с описанием юзабилити в cPanel. Для прервые попавшего в панель юзера она кажется довольно перегруженной информацией, что делает ее довольно сложной для новичков.
Может быть я повторюсь, но как уже было много раз сказано, это не совсем «облако», да и гибкость сильно урезана. Это, например, очень хорошо видно на возможностях выбора дискового пространства и т.д. Я бы назвал данный сервис — «более гибкий VPS». А по теме топика, расширение гографического покрытия — отличное направление, так держать!
Довольно интересное и перспективное решение, как мне лично кажется. Действительно, каналы не будут зажаты рамками эфирного времени и, например, для просмотра спортивных трансляций это будет большим плюсом.
Лично мне очень понравилось, они подошли к представлению продукта (промо сайт и карта с отображением геолокации загрузок и количеством загрузок). Аж приятно было скачивать :-)
Вот и подъехали коментарии вида "я вообще не понимаю чем занимается электрик, но хороший сантехник заниматься электрикой не захочет, значит оно уныло, нет творчества и перспектив нет".
Не надо так :-)
Вы сами себе противоречите.
Подпись под картинкой: "Одна выделенная стрелочка — один поход — одна проверка в unit тесте"
Практика есть у вас, судя по статье(хотя я спрашивал про интеграцию, а не про юнит, ну да ладно):
"В итоге спустя пару месяцев, я сама немного пишу юнит тесты и удаляю избыточные проверки на верхних уровнях"
Это тоже очень сильное заявление, которое больше запутывает, чем дает понимания того, что вы делаете и зачем это надо.
В отрыве от контекста и без понимания как эффективно(а не тестировщик глазами) мапить юниты на, как минимум, интеграционные говорить о целесообразности такого подхода нельзя(если только мы не говорим о продукте где не предъявляются высокие требования к качеству).
Добрый день.
В статье полностью подменено понятие юнит-тестов.
То что у вас нарисовано на картинке — это интеграционное тестирование сервисов на бэкэнде.
Не ясно почему этим занимается/занимался разработчик. QA у вас не пишет автотесты на бэкэнд?
Не могу понять, какая связь между темой статьи и этими тестами? Это какая-то обязательная часть методологии?
Не смог удержаться, простите. Готов получить порцию минусов.
В статье упущено много опций, например, про тестируемые конфигурации в GUI тестах (как пример тестирование мобильных приложений и взаиможействие с ОС) это сильно изменит процентное соотношение, или наличие отдельной бизнес-логики на стороне клиента и т.д.
Если кратко, то да, этот подход будет действенен для какого-либо проекта, но реальность намного сложнее и не все так просто.
А то о чем говорите вы — это именно хорошие узкоспециализированные специалисты, но такие спецы всегда знают что можно ждать от смежных технологий и решений, в отличии от фанатиков.
Как-то так :-)