)) я пощавчера так делал

Все исключительно зависит от проекта.

Плюсую. У нас 1 к 2м, специфика

И я понимаю о чем нонейм говорит. Разрабы бывает покрывают юнит тестами оч херово

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

Ребят, есть несколько вопросов, тем кто автотесты ваяет: 1. как часто пишете комментарии по коду? 2. описываете комментарием переменные? 3. если переменных несколько, то как комментируете?

Имеется в виду код автотестов?

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

Имеется в виду код автотестов?

да

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

т.е. вы не пишете комментарии, чаще? почему? и сколько вы в среднем экономите времени не написав комментарий?

Я очень редко пишу так как почти всегда код теста простой, и так понятно что он делает

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

ну лично мне иногда нравиться написать небольшой коммент к методу, чтобы потом в ide можно было глянуть описание (речь о java)

Я очень редко пишу так как почти всегда код теста простой, и так понятно что он делает

правильно я понимаю, что вы расчитываете на человека, который в принципе понимает код и сидит и разбирается в коде в свободное время? и, вы один только пишете код?

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

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

так что на мой взгляд надо комментировать только неочевидные вещи

Ребят, есть несколько вопросов, тем кто автотесты ваяет: 1. как часто пишете комментарии по коду? 2. описываете комментарием переменные? 3. если переменных несколько, то как комментируете?

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

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

а когда кто-то другой читаешь ваш код, у него возникают вопросы по коду?

а когда кто-то другой читаешь ваш код, у него возникают вопросы по коду?

редко, когда накосячил с названиями методов в основном

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

дада, так же делаем

коллеги, помогите определить тип тестирования. тестировать будем API, тестировать будем при помощи codeception. на данный момент, тесты будем запускать руками. Какое это тестирование, ручное, полуавтоматизированное?

это не тип тестирования

тип тестирования: функциональное скриптовое

спасибо

пытаюсь написать тест план, вот хочу описать стратегию типо.

коллеги, помогите определить тип тестирования. тестировать будем API, тестировать будем при помощи codeception. на данный момент, тесты будем запускать руками. Какое это тестирование, ручное, полуавтоматизированное?

При помощи codeception невозможно ручное делать ;)

под ручным я понимаю, сапуск каждого теста руками.

А чем отличается полуавтоматизированное от автоматизированного ?

не знаю

поэтому и спрашиваю.

Я думаю ничем

под ручным я понимаю, сапуск каждого теста руками.

Ну там же от опций зависит. Можно в командной строке запустить 1 тест, можно всю директорию или вообще все тесты

согласен

Как правило все тесты разом пускают

И через CI систему по триггеру

Короче это все авто-тесты ;)

под ручным я понимаю, сапуск каждого теста руками.

это прохождение каждого кейса руками

а стоит ли делать автотесты сразу?

это прохождение каждого кейса руками

спасибо

а стоит ли делать автотесты сразу?

ну как ты думаешь, стоит ли сразу писать тесты, если ты систему то не трогал...

и без кейсов ну вообще стремно писать тесты

кейсы\юзер стори по сути ТЗ к тестам

на каком этапе, надо начинать автоматизацию?

т.е. вы не пишете комментарии, чаще? почему? и сколько вы в среднем экономите времени не написав комментарий?

Скорее сколько я экономлю не поправляя устаревшие комментарии. А зачем они нужны, если понятно что происходит? // тут я присваиваю проёмной а значение 10?

на каком этапе, надо начинать автоматизацию?

ну это уже сукубо субьективное мнение

кто то решает что им она только мешает

кто то ее ведет паралельно с разработкой и тестированием

на каком этапе, надо начинать автоматизацию?

Чем раньше тем лучше

на каком этапе, надо начинать автоматизацию?

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

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

Прототипы тестов можно сразу набросать

Можно написать общие методы для работы с запросами, а потом обертку для различных форматов. Если оно уже часть роутов обслуживает - вперёд!

Вы же понимаете какие примерно методы там будут тестироваться

Разбей на директории и классы, распиши тесты, впиши в них markTestIncompleted()

пытаюсь написать тест план, вот хочу описать стратегию типо.

Забей на супер-точность в некритичных аспектах.

Я на текущем месте пришёл, когда надо было тестировать api. Ручками протаивают на момент прихода коммутатор с изменениями(но и то не всегда), пишу сразу метод с корректными и некорректными запросами

В целом, апи так резко не меняется. Каждый роут независим от других

благодарю

и без кейсов ну вообще стремно писать тесты

Вообще норм, придумал кейсы - записал их сразу в виде автотестов, а не в экселе

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

сущности уже разделили, на этапе написания документации, внес предложение, его приняли распихали. в этом плане у нас всё хорошо.

Вообще норм, придумал кейсы - записал их сразу в виде автотестов, а не в экселе

Или можно писать кейсы рядом с автотестами: По ним автоматизировать в будущем. И даже если не автоматизировать - всегда есть кейсы по которым проходил ты вручную и кто-то сможет пройти в будущем

ERROR: S client not available

ну без тест-кейсов не будет это точно.

Я вижу проблему в бумажной документации, Ее надо поддерживать

бумажную нафиг-нафиг

Даже javadoc к методу не правят при изменениях в методе

А вы говорите описание кейса где-то рядом

если нада - распечатать класс файлы или конфлюенс или тестрейл какойнить)

Эм

Но никто не запрещает, верно?

Законом не запрещено

Но я могу и фигню советовать))) Я просто БДД-еретик, поэтому....

люблю сценарии сплетенные с реализацией)

Есть один способ узнать, будет ли это работать - попробовать.

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

И аналогично проверить без этой штуки

Все привет! Ребят, есть у кого опыт удачного внедрения и пользования по сей день robotframework для автоматизаци проекта?

Всем привет! Разворачивал ли кто ферму из тестового стенда мобильных устройств для прогона авто тестов?

Есть необходимость развернуть под иСО и Андроид, есть ли понимание в необходимом кол-ве устройств и спеке машины на которой собственно это все дело будет прогоняться

?

@here Коллеги, привет. Есть вопрос: наверняка кто-то из вас сталкивался с задачей как-то измерять скорость своих веб-приложений. Расскажите как? Какой инструментарий используете? Хочется что-то вроде Я.Шутилки.

Скорость веб-приложения это что такое?

Что мерять-то хотите?

Скорость загрузки страницы для клиента. С момента перехода на страницу и момента завершения рендеринга страницы.

Это 2 этапа - 1) Скорость загрузки бэкенда 2) Скорость рендера страницы.

Первое мы меряли профайлинговыми утилитами под наш язык и фреймворк (php symfony), учитывая пинг до сервера еще

Второе можно попрофилировать в консоли разработки хрома или firefbug, там диаграмма ганта строится.

самая примитивная мерялка в ФФ встроена http://i.prntscr.com/599f6a5855a947bfb3a58d80139c71cd.png

в общем то в хроме в консоли в нетворке пишет время загрузки

никаких инструментов дополнительных не надо

Ну вообще неплохо бы построить графички для полного анализа, например для пхп есть xhprof который выдает всякие картиночки

https://i.onthe.io/shpzkl4nkbfc60nfp.3542e223.png типа таких