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

Гейзенбаг — новая конференция по тестированию от JUG.ru Group - 1

Мы проводим много разных конференций для разработчиков: Java, .NET, JavaScript, iOS/Android, – и в каждой из них акцент всегда ставится на технический хардкор и отсутствие воды в докладах. Кроме того, мы уже больше года опрашиваем наших участников, каких конференций не хватает в России. И вот результат: 10 декабря в Москве состоится первая в своем роде глубоко техническая конференция по тестированию Гейзенбаг 2016 Moscow.

Обратите внимание: Гейзенбаг — это именно конференция «по тестированию», а не «для тестировщиков». Мы приглашаем на конференцию:

  • тестировщиков,
  • программистов, разрабатывающих тесты для своего кода (или думающих об этом),
  • специалистов по автоматическому тестированию
  • специалистов по нагрузочному тестированию
  • тимлидов, которые думают о том, чтобы повысить эффективность тестирования в своих проектах.

Итак, какую техно-жесть мы готовим для вас? Смотрите под катом.
Читать полностью »

PVS-Studio and NUnitДовольно часто при обсуждении средств статического анализа для C# проектов программисты пишут о том, что в этом нет необходимости, потому что с помощью юнит-тестирования они отлавливают большинство ошибок. Я решил проверить, насколько хорошо протестирован один из самых известных юнит-тест фреймворков — NUnit, и посмотреть найдёт ли там что-нибудь наш анализатор.
Читать полностью »

image

Приветствую уважаемых жителей Хабрахабра!

Не так давно я стал замечать, что мой код становится громоздким и даже в рамках одного контроллера мне все сложней удержать в голове то, что в нем происходит. Как следствие, на выходе не всегда ожидаемый результат, что я хотел реализовать, так как мозг “замылился” и я легко могу упустить существенную деталь. А после, ручной анализ кода, работа с отладчиком и так далее… Да что уж говорить, доходило до абсурда, при сборке приложения xcode падал замертво и я даже не успевал понять, что случилось в приложении! Нужно было что то менять и думать над архитектурой, так как я не хочу всю свою карьеру писать плохоподдерживаемый код…

Кому интересен вопрос архитектуры приложения, добро пожаловать под кат!Читать полностью »

Недалекое прошлое: этюд о проблемах автоматизации тестирования - 1
Изображение с сайта familyexpert.ru

На фоне постоянных разговоров о глобальной информатизации, стремительном развитии ИТ-сферы и, в частности, технологий разработки программного обеспечения, возникают размышления о гармоничности этого развития. Если разработка ПО семимильными шагами движется в сторону DevOps, автоматизации инструментария и продолжает движение, правда уже не так активно, в сторону Agile, то куда движется автоматизированное тестирование?

Хотя самому факту автоматизации тестирования в прогрессивных компаниях СНГ можно было найти подтверждение, но это подтверждение, на поверку, оказывалось формальным. Как говорится, и «да, и нет». По крайней мере, так было несколько лет назад. Читать полностью »

На одном из наших недавних проектов мы столкнулись с серьёзной проблемой. Веб-приложение, которое мы разрабатывали, должно было использовать внутренюю базу данных финансовой организации. Из соображений безопасности, доступ был очень сильно ограничен: любые изменения необходимо было делать при помощи хранимых процедур, а читать данные — только при помощи представлений. Таким образом, приложение должно было выполнять сложные манипуляции данными, не имея никакого представления об их структуре. Основной загвоздкой для нас было то, что наше приложение попадало в зависимость от больших и сложных процедур, для которых не существовало автоматизированных тестов.

Погуглив немного, мы обнаружили, что в штатном инструментарии Oracle SQL Developer [1] есть функционал для создания автоматизированных тестов. Мы тут же приступили к его изучению. И хотя тесты для самой сложной процедуры пришлось создавать уже после её написания, этот инструментарий всё же помог нам устранить несколько ошибок, а также существенно облегчил процесс расширения функционала и рефакторинга. Ниже я приведу пример использования TDD для построения хранимых процедур, а также поделюсь опытом в работе с инструментарием.

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

Итак, в нашей прошлой статье мы рассмотрели как можно быстро и просто настроить среду для тестирования плейбуков и ролей Ansible. Это всё, конечно, очень хорошо и удобно, но почему бы нам не автоматизировать весь процесс внесения изменений в инфраструктуру от написания плейбука до внесения изменений на сервера?

image

Напомню несколько условий, при которых мы будем выполнять тестирование конфигураций:

1. Вся конфигурация хранится в git-репозитории;
2. Jenkins периодически опрашивает git-репозиторий с нашими ролями/плейбуками на предмет внесённых изменений;
3. При появлении изменений Jenkins запускает job с тестированием конфигурации. Тесты состоят из двух этапов:
3.1 Kitchen-CI берёт обновленный код из репозитория, запускает полностью свежий docker-контейнер, заливает в них обновлённые плейбуки из репозитория и запускает Ansible локально, в docker-контейнере;
3.2 Если первый этап прошёл успешно, в docker-контейнере запускается serverspec и проверяет, корректно ли встала новая конфигурация;
4. Если в Kitchen-CI все тесты прошли успешно, то Jenkins инициирует заливку новой конфигурации.

В идеале, весь процесс от написания плейбука и коммита в репозиторий до внесения изменений на сервера, должен проходить без нашего участия. Сильно углубляться в установку Jenkins и подробно расписывать о пайплайнах в данной статье не планируется. Первое делается без проблем из стандартных репозиториев, а второе — сугубо индивидуальное.
Читать полностью »

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

Это рспек.

Привет, меня зовут Леонид, и я работаю в команде, использующей Ruby on Rails, в компании Align Technology.
На работе мы используем рельсы в связке с RSpec, и сегодня я поделюсь нашим опытом о том, как облегчить себе жизнь при помощи собственных тегов в тестах.

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

Ansible: тестируем плейбуки (часть 1) - 1

Думаю, любой системный администратор, использующий Ansible для управления своим зоопарком серверов задавался вопросом о проверке корректности описания конфигурации своих серверов. Как же не бояться вносить изменения в конфигурации серверов?
В серии статей, посвященных DevOps, мы расскажем об этом.

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

Часть 1

Сегодня поговорим о создании UI smoke-теста для сайта с использованием фреймворков Cucumber и Selenide. Статья рассчитана на junior, который совсем ничего не знает про данные фреймворки. Опытный junior найдет во второй части интересные моменты, до которых я доходил пару месяцев.
Статья состоит из двух частей:

  • в первой описано создание нашего теста простейшим способом – чтобы запускалось и при этом никаких сложных вещей из фреймворков не использовалось. Только создадим описание фичи (.feature файл) и класс описания степов с использованием Selenide.
  • во второй части в тот же самый тест добавим всякие интересные штуки от Selenide, посмотрим, как создавать красивые отчеты, которые будут содержать текст фич (мн.ч от слова «фича»).

Фреймворки

Selenide – фреймворк (а точнее библиотека), обертывающий Selenium. Чем он отличается, прекрасно описано автором, Андреем Солнцевым. Главное отличие – Selenide позволяет сократить кучу строчек кода при написании UI тестов, что является одной из главных задач при создании тестов/написании кода, ибо Вы должны заботиться о том тестере, который придет после Вас и должен будет разбирать Ваше творение.

Cucumber – это фреймворк, реализующий подход BDD/TDD. Я не претендую на глубокое теоретическое знание BDD/TDD, пока что для меня они суть одно и тоже.

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


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