Pull to refresh
16
0
Алексей Махов @LionAlex

Пользователь

Я про вот этот комментарий


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

Я бы просто не стал отделять тестирование от разработки.


Что вы имеете ввиду под формулировкой — такие же тесты?

Функциональные e2e. Апи или UI – не так важно.


Запускаем через Teamcity.

В тимсити только кнопка нажиматся, главная магия всегда не в нем :)

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


А что за UI тесты на котлине? Graphwalker+Android или ещё что-то?


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


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

часто стек автоматизации подбирают под стэк разработки

Да, это хороший аргумент. Но в данном случае как раз джавы/котлина в стеке нет

Есть, но в андроиде, тут же речь не о нем, как я понял.


Почему вы считаете, что компилируемый язык плохо подходит для тестов?

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

В остальном мы используем обычные инструменты для тестирования: API тесты связкой Kotlin+JUnit+RestAssured

Чем обусловлен выбор этого стека? Во-первых, компилируемый язык плохо подходит для тестов, во-вторых, джавы в холде на техрадаре.

Тимур в одном из ответов объясняет: чтобы тупо найти свой ноут среди кучи таких же.
Ну и просто на конфах дают кучу наклеек, некоторые из них реально крутые, надо же куда-то пристроить :)

На самом деле он крут в своей простоте, но к нему надо привыкнуть.
И есть опенсорсные движки, приближенные к тому, к чему мы все привыкли

Ну во-первых, это красиво :)
И не надо гошный template использовать, зато можно использовать PHP как движок шаблонов.

Ну серебрянной пули не существует.
По нашему опыту, тот же настроенный k8s с шаблонами всех конфигов в скелете сервиса позволяет достаточно легко и быстро распиливать монолит на сервисы и деплоить их в "облако". Проблем по стабилизации, конечно, дофига, но разработчикам сервисов удобно. 30 секунд и твой сервис работает. И никакой беготни по админам/девопсам/еще кому-то.

banuchka смотрели ли на какие-нибудь системы управления контейнерами типа Kubernetes? Есть ли планы по внедрению или какие-то аргументы почему оно вам не подходит?

Ну в вашем стеке уже есть как минимум PHP, Java/Scala, C, Go. То есть его использование не добавляет зоопарка.


А "узкоспециализированые" это какие? Ну то есть какие задачи для Го, а какие – нет, с вашей точки зрения?

Насколько широко вы используете Go, где и для чего, почему ровно столько и не больше/меньше и планируете ли увеличивать или уменьшать его использование в своих проектах?


Судя по всему, он бы отлично лег на задачи A-Team, например.


Как жизнь с Protobuf? Не слишком ли много времени на возню с ним уходит при отладке/тестировании/и т.д.?

Телефон в виде картинки – попытка защититься от парсинга телефонов пользователей.

Такая подойдет?
image

По поводу канареек:
Когда их подселили, их сразу же нарекли Багом и Фичей. Баг сбежал из клетки в первый же вечер и его ловили всем офисом по всему четырнадцатому этажу.

Не таскали, привозил поставщик ланч-боксы. А сейчас готовят прямо тут.

Все так, на подземном паркинге

Information

Rating
Does not participate
Location
Ярославская обл., Россия
Date of birth
Registered
Activity