Рубрика «tdd» - 4

кдпв

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

Обычный день, обычный релиз: все задачи вдоль и поперек проверены нашим QA-инженером, поэтому со спокойствием священной коровы «закатываем» на stage. Приложение ведет себя хорошо, в логах — тишина. Принимаем решение делать switch (stage <-> prod). Переключаем, смотрим на приборы…

Проходит пару минут, полет стабильный. QA-инженер делает smoke-тест, замечает, что приложение как-то неестественно подтормаживает. Списываем на прогрев кешей.

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

На часах 7:15 утра. Наша техподдержка завалена работой. О нас только что рассказали в передаче «Good Morning America» и множество тех, кто впервые посещает наш сайт, столкнулось с ошибками.

У нас настоящий аврал. Мы, прямо сейчас, до того, как потеряем возможность превратить посетителей ресурса в новых пользователей, собираемся выкатить пакет исправлений. Один из разработчиков кое-что подготовил. Он думает, что это поможет справиться с проблемой. Мы размещаем ссылку на обновлённую версию программы, пока ещё не ушедшей в продакшн, в чат компании, и просим всех её протестировать. Работает!

Наши героические инженеры запускают скрипты для развёртывания систем и через считанные минуты обновление уходит в бой. Внезапно число звонков в техподдержку удваивается. Наше срочное исправление что-то поломало, разработчики хватаются за git blame, а инженеры в это время откатывают систему к предыдущему состоянию.

image

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

GitLab Shell Runner. Конкурентный запуск тестируемых сервисов при помощи Docker Compose - 1

Данная статья будет интересна как тестировщикам, так и разработчикам, но рассчитана в большей степени на автоматизаторов, которые столкнулись с проблемой настройки GitLab CI/CD для проведения интеграционного тестирования в условиях недостаточности инфраструктурных ресурсов и/или отсутствия платформы оркестрации контейнеров. Я расскажу, как настроить развертывание тестируемых окружений при помощи docker compose на одном единственном GitLab shell раннере и так, чтобы при развертывании нескольких окружений запускаемые сервисы друг другу не мешали.

Читать полностью »

image alt

Думаете, как сэкономить на тестировании вашего ПО? Вы не одиноки. Возникает лишь одно маленькое но: если софт не дотестировать, возможны самые негативные сценарии – от дорогостоящей и крайне невыгодной вам доработки приложения на поздних стадиях до потери репутации и ухода клиентов/заказчиков к конкурентам.Читать полностью »

14 декабря на митапе в Санкт-Петербурге я (Артем Соковец) совместно с коллегой, Дмитрием Маркеловым, рассказывал о текущей инфраструктуре для автотестов в СберТехе. Пересказ нашего выступления — в этом посте.

Как мы автоматизировали запуск Selenium-тестов через Moon и OpenShift - 1
Читать полностью »

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

Тогда мне пришла в голову идея, после разбиения пользовательской истории на задачи, попробовать набросать черновики модульных тестов, для классов или методов, которые я упоминаю в задачах. Мне даже не нужно выдумывать пользовательскую историю, я могу взять одну из моей текущей работы. Например:Читать полностью »

В жизни каждого разработчика наступает момент, когда он задумывается над созданием тестовой составляющей для своего детища. Поправлюсь — в жизни каждого хорошего разработчика. Когда ты джуниор и не несешь особой ответственности, имеешь право на уйму ошибок и можешь их исправить в любой момент. Ты не отвечаешь за тот продукт, что создаешь и не имеешь мотивации тратить лишнюю минуту на перепроверку созданного кода. «Да ничего, этот косяк не воспроизведется», «кажется, эта штука работает», «ну как минимум, она делает то что нужно» — если вы желаете перерасти уровень программерских яслей, то придётся свести на нет каждую из этих мыслей.

С развитием собственного опыта программирования, у вас появляются новые всё более и более крутые/крупные клиенты. От некоторых вы даже будете в восторге (от всех, если вы прям везунчик) — и люди хорошие, и оплачивают щедро, и не придирчивы к возникающим проблемам. Давайте рассмотрим один такой простой случай (очень простой, но главное то, что за этим стоит) создания обработчика формы от программиста, не знающего хлопот.
Читать полностью »

Это продолжение истории, которая началась здесь, а продолжалась здесь и здесь.

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

В предыдущей части я остановился на том, что разрабатываемая мной команда реализует поведение, которое можно описать вот таким тестом:

it('execute should return promise', () => {

  request.configure(options);

  request.execute().then((result) => {

    expect(result.Id).toEqual(1);
    expect(result.Name).toEqual('Jack');
  });
});

Читать полностью »

Spock предоставляет 3 мощных (но разных по сути) инструмента, упрощающих написание тестов: Mock, Stub и Spy.

Моки, стабы и шпионы в Spock Framework - 1

Довольно часто коду, который нужно протестировать, требуется взаимодействовать с внешними модулями, называющимися зависимостями (в оригинальной статье используется термин collaborators, который не очень распространён в русскоязычной среде).

Модульные тесты чаще всего разрабатываются для тестирования одного изолированного класса при помощи различных вариантов моков: Mock, Stub и Spy. Так тесты будут надёжнее и будут реже ломаться по мере того, как код зависимостей эволюционирует.

Такие изолированные тесты менее подвержены проблемам при изменении внутренних деталей реализации зависимостей.

От переводчика: каждый раз, когда я использую Spock Framework для написания тестов, я чувствую, что могу ошибиться при выборе способа подмены зависимостей. В этой статье есть максимально краткая шпаргалка по выбору механизма для создания моков.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js