Комментарии 14
Русский текст в названиях тестов использовали только для примера, или для разработки тоже?
Спасибо за интересную статью. Но мне кажется, что тема использования всей мощи ScalaTest в ней не до конца раскрыта. С вашего позволения я рискну дополнить статью парой ссылок для заинтересованных читателей. По первой детально описывается DSL ScalaTest, по второй рассматривается вопрос написания с его помощью property based тестов.
Благодарю за замечание! Действительно, фреймворк очень мощный, и статья охватила лишь малую долю возможностей. С вашего позволения, добавил еще ссылки на документацию и на пару книг. На странице ScalaTest можно посмотреть, какие еще плюшки есть у фреймворка.
Testing in Scala хороша. Я бы еще обязательно добавил к ней ScalaCheck: The Definitive Guide. ScalaCheck — реально мощнейший и очень простой в использовании инструмент, который очень легко интегрируется в ScalaTest. Грех им не пользоваться.
Интересно было бы узнать, в каких случаях ScalaCheck лучше обычных юнит-тестов?
Всегда когда можно придумать property-based тест. Типичные примеры — валидация, сериализация/десериализация, сжатие, шифрование. Но при желании можно найти применение и в других областях. Так например проперти бейзед тестами доказывают корректность распределенных алгоритмов. Находят инвариант который всегда должен выполняться. И потом пишут тест в стиле — неважно что происходит с системой, для любой последовательности событий этот инвариант держится. Почему лучше обычных тестов — кода меньше, самих тестов в сотни раз больше. Больше покрытие, больше багов ловится, больше КПД программиста. Часто проверяются такие граничные случаи о которых программист и не подумал бы при написании теста вручную. Например что если передать на вход методу в качестве double значение NaN или + бесконечность и такого рода вещи.
Хочу отметить, что при создании SBT-проекта лучше не выбирать «Use auto import». Эта опция заставит среду перечитывать все проектные файлы практически на каждое изменение файла. Если в вашей сборке больше нескольких проектов, это будет делаться оооочень долго — например, в сборке на ~80 проектов обновление зависимостей делается около пяти минут. Лучше отключить эту опцию и запускать обновление вручную, через боковую панель. В конце концов, зависимости у проектов обычно обновляются не очень часто.
libraryDependencies += «org.scalatest» % «scalatest_2.11» % «3.0.0-M7». Это последняя на момент написания статьи версия.
Советовать людям ставить пререлизы идея плохая. Последняя стабильная версия 2.2.4. Кстати писать можно «org.scalatest» %% «scalatest» % «2.2.4» Так подтянется версия библиотеки под ту версию scala которая указана в проекте.
Импортируем нужные библиотеки и в начале класса определим метод “get” для получения текста страницы и создадим экземпляр «FirefoxDriver».
И создаём implicit value c драйвером для использования selenium dsl который есть в scalatest. Наверно это нужно было указать, а то тем кто не знает будет не сильно понятно куда делся браузер.
Конечно как-то странно при разборе библиотеки видеть мини экскурсы в язык и кучу скриншотов которые съели почти всё. Но радует само наличие статьи, а то про scalatest мола что есть в рунете.
Спасибо за замечания, с Вашего позволения добавил уточнение про браузер.
Целью создания статьи является не столько обзор фремворка, сколько инструкция по применению. Как начать пользоваться ScalaTest. Понятно, что для специалистов, которые работают c java, для которых среда разработки Idea как родная, а проблемы с кодировкой давно решены и изучены, большая часть статьи — это очевидные вещи. Для новичков же начать пользоваться технологией не всегда так просто, непонятно, как подступиться ко всему этому хозяйству.
К примеру, на странице scalatest.org/user_guide/running_your_tests описано 8! способов запуска тестов. И неочевидно, какой из них лучше использовать.
Изначально статья — это немного причесанная пошаговая инструкция для сотрудника отдела тестирования в нашей компании, как сделать тест для проверки определенной функциональности. Для разработчика она избыточна.
Целью создания статьи является не столько обзор фремворка, сколько инструкция по применению. Как начать пользоваться ScalaTest. Понятно, что для специалистов, которые работают c java, для которых среда разработки Idea как родная, а проблемы с кодировкой давно решены и изучены, большая часть статьи — это очевидные вещи. Для новичков же начать пользоваться технологией не всегда так просто, непонятно, как подступиться ко всему этому хозяйству.
К примеру, на странице scalatest.org/user_guide/running_your_tests описано 8! способов запуска тестов. И неочевидно, какой из них лучше использовать.
Изначально статья — это немного причесанная пошаговая инструкция для сотрудника отдела тестирования в нашей компании, как сделать тест для проверки определенной функциональности. Для разработчика она избыточна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация мониторинга и интеграционного тестирования информационной системы с использованием Scalatest. Часть1