В этой статье я расскажу об основах внедрения зависимостей (англ. Dependency Injection, DI) простым языком, а также расскажу о причинах использования этого подхода. Эта статья предназначена для тех, кто не знает, что такое внедрение зависимостей, или сомневается в необходимости использования этого приёма. Итак, начнём.
Чем мне нравится экосистема React, так это тем, что за многими решениями сидит ИДЕЯ. Различные авторы пишут различные статьи в поддержку существующего порядка и обьясняют почему все "правильно", так что всем понятно — партия держит правильный курс.
Через некоторые время ИДЕЯ немного меняется, и все начинается с начала.
А начало этой истории — разделение компонент на Контейнеры и неКонтейнеры (в народе — Тупые Компоненты, простите за мой франзуский).
30 ноября в московском офисе Mail.Ru Group пройдёт митап, полностью посвящённый мобильному тестированию. Мы подготовили его совместно с организаторами октябрьской конференции AppsConf по многочисленным просьбам от сообщества. Программа и регистрация – под катом.
Читать полностью »
Многие используют SoapUI для того, чтобы тестировать как сам API, так и приложения, обращающиеся к API. Довольно гибкий инструмент, позволяющий, например, экспортировать swagger файл API и сгенерировать Mock-service на его основе.
Не так давно у нас в компании я столкнулся с похожей задачей, но с нетривиальными условиями. Исходные данные: необходимо протестировать серверное приложение, которое получает на вход задачу, в процессе выполнения обращается к АПИ, каждый последующий запрос зависит от ответа АПИ. Логика вшита в приложение. То есть своеобразный черный ящик, где нужно протестировать множество выходов из сценария, когда вход в сценарий один.
Ниже я предлагаю пример решения, которое позволило достаточно просто встроить его в регрессионную инфраструктуру, а также имеющее запас для масштабирования, в случае увеличения покрытия диапазона сценариев и их сложности.Читать полностью »
01 августа мы запустили открытое бета-тестирование мобильной онлайн игры Cats vs Pigs: Battle Arena.
Несмотря на то, что мы нигде не афишировали начало тестирования, не рассылали пресс-релизов и не покупали трафик — в течение недели после релиза по данным GameAnalytics игру установило около 2000 пользователей.
Зная, что многие разработчики очень заинтересованы в росте органического и вирального трафика для своих игр, мы решили поделиться опытом самостоятельной работы в области ASO и в области подготовки к лончу открытой беты Google Play, позволившим получить позитивные результаты уже на самой ранней стадии жизненного цикла проекта.
У большинства из нас найдётся знакомый, который недоволен выбранной профессией и воспринимает походы на работу как обязаловку и повинность. А возможно, что вы и есть тот самый недовольный. Возникает вопрос: «Что же с этим делать?». В этой статье я хочу рассказать, как сам преодолел такую сложность. Забегая вперёд, скажу, что усилия себя оправдали: вместо того, чтобы обречь себя на судьбу конструктора на заводе, я работаю QA-инженером в IT-компании. Может быть, это послужит кому-то мотивацией.
Приложение для Tarantool — это, по сути, набор хранимых процедур, используемых как API. Данные обрабатываются на стороне хранилища, что позволяет значительно повысить производительность. Однако поддержка хранимых процедур может превратиться в кошмар.
Может. Но не сегодня.
Сегодня мы рассмотрим вопросы обеспечения качества приложения. В частности, поговорим о тестировании, разберемся, как запуститься в production, как использовать коннекторы, а также поговорим о тонкостях миграции схемы данных.
Эта статья будет полезна тем, кто впервые собрался получать сертификат от Mikrotik, но боятся «неизведанно» и профукать деньги.
Я вчера (14-04-2018) сдал тест на MTCNA на 100% и поделюсь с Вами как я достиг этого.
Представьте что в Роскосмосе решили собрать новую ракету не имея при этом чертежей и четкого понимания как ракета должна быть устроена. Отдельный завод занимается корпусом ракеты, отдельный выпускает двигатели, еще один — сопла. Главный менеджер Роскосмоса сказал что он доверяет профессионалам, и мастерски сделегировал всю работу заводам.
Через год все составные части доставляются в главный сборочный цех, и выясняется, что двигатель не входит в корпус, а сопла начинают плавиться даже при тестовых запусках двигателя.
Чтобы такой фигни не случалось, в реальных проектах всегда есть этап планирования и проектирования, на котором фиксируются спецификации того как части будут взаимодействовать между собой и какими характеристиками ни должны обладать.
При разработке ПО мы не можем себе позволить долгий этап проектирования, т.к. за это время потеряется бизнес-ценность того что мы пытаемся разработать — нас тупо обойдут конкуренты.
Поэтому команды, разрабатывающие составные части программы(модули) зачастую вынуждены работать не до конца понимая как их модуль будет взаимодействовать с остальными частями.
Как и в случае с ракетой, при попытке выпустить новый релиз приложения, разрабатываемого по частям несколькими командами, может выясниться что какие-то из модулей не совместимы.
В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.
Читать полностью »
Здравствуйте, меня зовут Дмитрий Карловский и это продолжение традиционной рубрики "Почему мы так не любим писать тесты?". Короткий ответ: потому, что получаемые от них бонусы не перевешивают затрачиваемых усилий. Если это так, значит мы делаем что-то не правильно. Давайте разберёмся что же могло пойти не так..
Данная заметка выросла из главы "Заблуждения" лонгрида "Концепции автоматического тестирования", посредством дополнения новыми заблужениями и аргументами.
