Привет! Меня зовут Ксения Якиль. Я пишу core-сервисы на C и Go в бэкенд-отделе Badoo и Bumble. Наш бэкенд — это высоконагруженная распределённая система, обслуживающая пользователей по всему миру. Она оперирует большими массивами данных и делает всю ту магию, благодаря которой люди находят друг друга.
Эта статья — не теоретическое руководство по написанию тестов и не how-to по использованию инструментария в определенном стеке, а ряд популярных вопросов, иногда даже у многих не сформировавшихся, на которые я постараюсь дать ответы. Источником этих вопросов служат коллеги, люди с обоих сторон в собеседованиях и знакомые, а ответы будут субъективными, краткими и не исчерпывающими, основанными на чужих материалах и своём опыте. Целевая аудитория статьи – разработчики, которые с определенным успехом пишут или хотя бы пытались писать тесты, но испытывают определенные сложности в их написании.
Я старался не привязываться к конкретному языку, чтобы увеличить охват читающих, однако оговорюсь сразу, что работаю в экосистеме PHP с использованием PHPUnit, и поэтому некоторые мои выводы могут быть неподходящими для других экосистем. При подборе вопросов и написанию я ориентировался на множество докладов и статей и пользовался ими как референсом.
Поводом для написания послужила недавняя статья «PHPUnit. Мокаем Doctrine Entity Manager» от trawl, некоторые проблемы из которой я тоже разберу.
Список вопросов:
Предисловие: в университете было получено задание — собрать scrum команду, выбрать проект и работать над ним в течении семестра. Наша команда выбрала разработку веб-приложения (react + flask). В этой статье я постараюсь рассказать, какими тесты должны были быть, и проанализировать, что у нас получилось на бекенде.
Приходя на новый проект, я регулярно сталкиваюсь с одной из следующих ситуаций:
К сожалению, именно к последнему сценарию часто приводят серьезные попытки начать внедрять тестирование при отсутствии соответствующих навыков.
Что можно сделать, чтобы изменить сложившуюся ситуацию? Идея использования тестов не нова. При этом большинство туториалов напоминают знаменитую картинку про то, как нарисовать сову: подключаем JUnit, пишем первый тест, используем первый мок — и вперед! Такие статьи не отвечают на вопросы о том, какие тесты нужно писать, на что стоит обращать внимание и как со всем этим жить. Отсюда и родилась идея данной статьи. Я постарался кратко обобщить свой опыт внедрения тестов в разных проектах, чтобы облегчить этот путь для всех желающих.
Читать полностью »
Про использование Docker и Docker-compose последнее время написано очень много, например рекомендую недавнюю статью на Хабре, если вы до сих пор не прониклись. Это действительно очень удобно, а в связке в ansible особенно. И я его использую везде. От разработки, до автоматического интеграционного тестирования на CI. Про использование в тестировании, тоже писали. Это здорово и удобно. Однако, для локальной разработки, для траблешутинга данных "как в продакшене" или тестирование производительности, на "объёмах близких в продакшену", хочется иметь под рукой образ, содержащий базу, "как в продакшене"!
Соответственно, хочется, чтобы каждый разработчик, приступая к работе над проектом, мог запустить его одной командой, например:
./gradlew dockerRunи приложение поднялось бы сразу со всеми необходимыми связанными контейнерами? А главное чтобы в нём уже были бы данные для большинства кейсов разработки и багфиксинга, стандартные пользователи и большинство работающих сервисов, над которыми сразу можно было бы приступить работать, не тратя времени на экспорт-импорт каких-то там образов или демоданных!
Как приятный бонус, ну разве не здорово иметь базу данных в несколько гигабайт и возможность откатиться к её исходному (или любому другому коммиту) состоянию в течении пары секунд?
Разумеется мы поговорим о написании Dockerfile для такого образа с данными, и некоторых подводных камнях этого процесса.
Канун Нового Года — время чудес. В преддверии нового года мы все вспоминаем год уходящий и строим планы на следующий. И надеемся, что все проблемы останутся в прошлом, а в новом году случится чудо, и мы заживём по-новому.
Какой же Java разработчик не мечтает о чуде, которое осенит его и позволит стать Самым Крутым На Свете Java Программистом.
Хорошие новости: я хочу рассказать как раз о таком чуде.
Имя ему — автоматические тесты!
Привет, читатели!
Хочу поделиться с вами личным опытом в системном интеграционном тестировании. Наша команда занимается разработкой интеграционного слоя, через который связаны все системы в банке. Задач у нас много, времени не хватает, и вопрос тестирования интеграции всегда откладывался.
Как же происходит тестирование интеграции? Самый короткий ответ — никак, хотя у нас больше сотни систем, которые взаимодействуют через интеграционную шину Oracle Service Bus(OSB). У этого продукта есть инструмент OSB Console, который позволяет послать тестовый запрос и отображает полученный ответ. После того как разработчик реализует на шине новый сервис, сервис вручную проверяется через OSB Console. Если проверка успешна, то сервис объявляется работающим и меняется, только если на него начинают жаловаться разработчики внешних систем.
Поддержка используемой нами OSB подходила к концу, и возникла необходимость перехода на новую версию. Хотя сама миграция больших проблем не вызывала, встал вопрос, а как проверить работоспособность смигрированного решения? И тут наша команда в очередной раз задумалась о внедрении автоматического тестирования.
Читать полностью »
Я хочу рассказать об опыте разработки iOS-клиента для социальной сети и бэкенда реализованного с помощью BaaS Parse.com Нижe приведена архитектура, которая у нас получилась, некоторые tips&tricks и размышления по поводу работы с parse.com.
Изначально клиент думал о сервере на RoR, но, видимо, они не рискнули вкладывать сразу много денег. Мы подписали строгое NDA, поэтому ссылку на Appstore я дать не могу.
Читать полностью »
Свою первую программу я писал для интерпретатора Basic. Он запускался при включении машины, а после ввода программу можно было выполнить командой RUN.
Многое изменилось с тех пор. Мы говорим о стеках технологий и целых экосистемах в IT. За выполнение каждой прихоти программиста конкурируют несколько систем/библиотек/расширений/модулей/сервис. А выбрать среди них порой так же сложно, как написать свой велосипед.
К психиатру пришел человек с жалобой на невроз.
— А кем же вы работаете? — интересуется доктор.
— Сортировщиком апельсинов на овощной базе. Передо мной желоб, по которому катятся апельсины. Крупные я должен класть в один ящик, а мелкие — в другой.
— Что же нервного в такой работе?
— Как что? Я целый день должен принимать решения, решения, решения.
Далее немного ироничное руководство для тех, кто не хочет ничего решать, а хочет сразу попасть на уровень профи и использовать все модные технологии, минуя долгий путь исследования и выработки собственных предпочтений.
Итак, для создания rails-приложения нам понадобятся
Читать полностью »
Многие слышали про Selenium WebDriver — один из самых популярных инструментов для написания приёмочных/интеграционных тестов.
Используя Selenium, мы очень быстро заметили, что нам раз от раза приходится писать один и тот же код, чтобы инициализировать браузер вначале, закрыть его в конце, делать скриншоты после каждого упавшего теста и т.д. (пруфлинк).
Поэтому мы решили выделить этот повторяющийся код в отдельную библиотеку. Так на свет появился Selenide.