Я программирую главным образом в scala и Java, с помощью scalatest в scala и junit для поблочного тестирования. Я хотел бы применить те же самые тесты к нескольким реализациям того же интерфейса/черты. Идея состоит в том, чтобы проверить, что интерфейсный контракт осуществляется и проверять принцип замены Лисков.
Например, при тестировании реализаций списков, тесты могли включать:
Каковы лучшие практики?
Похоже, это может быть работа для общих тестов. Общие тесты - это тесты, которые используются разными объектами фикстур. То есть один и тот же тестовый код запускается на разных данных. ScalaTest поддерживает это. Найдите в документации по вашему любимому стилю «общие тесты», которые представляют тесты как функции (Spec, WordSpec, FunSuite, FlatSpec и т. Д.). Примером является синтаксис для FlatSpec:
он должен вести себя как emptyList
См. Sharing Tests в документации FlatSpec
Контрактные тесты легко выполнить с помощью JUnit 4, здесь видео Бена Рэди.
В Java / JUnit я обычно справляюсь с этим, имея абстрактный тестовый набор, из которого тесты для конкретного тестового класса наследуют все тесты и имею метод установки, создающий экземпляр реализации. Я не могу сейчас посмотреть видео, опубликованное abyx, но подозреваю, что это общая идея.
Еще одна интересная возможность, если вы не против ввести еще одну среду тестирования, - это использование классов спецификаций JDave .
Я не пробовал использовать ни один из них с Scalatest или с особенностями и реализациями Scala, но должно быть возможно сделать что-то подобное.
Для Scala настоятельно рекомендуется использовать ScalaCheck. Все эти контракты выражаются в виде однострочных спецификаций в ScalaCheck. При запуске ScalaCheck случайным образом сгенерирует настраиваемое количество выборок входных данных и проверит соблюдение всех спецификаций. Речь идет о наиболее семантически плотном способе создания модульных тестов.