Scalatest — это фреймворк для тестирования приложений, поддерживающий разные стили написания тестов и легко интегрирующийся с другими инструментами для JVM, включая IDE и maven.

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

Существует множество решений для автоматизации тестирования. Каждое их них имеет свои особенности, преимущества, недостатки, различаются порогом вхождения, удобством применения, эффективностью, универсальность, кругом задач, для которых хорошо подходит. Для задачи автоматизации интеграционного тестирования и мониторинга систем для одного из проектов удачным решением оказалось применение связки «Scala» + «ScalaTest» + «SBT»

В предыдущей статье Реализация мониторинга и интеграционного тестирования информационной системы с использованием Scalatest мы говорили о создании проекта в Idea и написании простых тестов. В этой части мы рассмотрим некоторые особенности работы фреймворка, а также приемы для решения задач, возникающих в ходе написания тестов.
Более детально остановимся на специфике запуска тестов, разберем детали формирования отчетов, особенности работы с Selenium, а также обратим внимание на таймауты, ожидания, вызовы команд операционной системы, формирование jar файла с тестами

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

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

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

Юрий Бадальянц на РИТ++ рассказал, как в 2ГИС тестируют связку из большого числа сервисов и целого зоопарка технологий. Под катом дополненная и актуализированная под тщательным присмотром спикера версия этого доклада: какие варианты пробовали, к чему пришли, какие проблемы теперь вам не придется решать. Будет про Docker, Testcontainers, а также про Scala.

In this article, I would like to propose an alternative to the traditional test design style using functional programming concepts in Scala. This approach was inspired by many months of pain from maintaining dozens of failing tests and a burning desire to make them more straightforward and more comprehensible.

Even though the code is in Scala, the proposed ideas are appropriate for developers and QA engineers who use languages supporting functional programming. You can find a Github link with the full solution and an example at the end of the article.

В одном из старых проектов в кучу были навалены ассерты из JUnit, kotlin.test и AssertJ. Это было не единственной его проблемой: его вообще писали как письмо Дяди Федора, а времени остановиться и привести к единому виду не было. И вот это время пришло.

В статье будет мини-исследование про то, какие ассерты лучше по субъективным критериям. Хотел сначала сделать что-то простое: накидать набор тестов, чтобы быстренько копипастом клепать варианты. Потом выделил общие тестовые данные, некоторые проверки автоматизировал, и как поехало все… В результате получился небольшой розеттский камень и эта статья может пригодится вам для того, чтобы выбрать библиотеку ассертов, которая подойдет под ваши реалии.

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