Статическое тестирование для Scala

В Scala есть несколько хороших библиотек для тестирования (Specs, ScalaTest, ScalaCheck). Однако благодаря мощной системе типов Scala важные части API, разрабатываемые в Scala, выражаются статически, обычно в форме нежелательного или недопустимого поведения, которое предотвращается компилятором.

Итак, как лучше всего проверить, предотвращает ли что-то компилятор при разработке библиотеки или другого API? Неприятно комментировать код, который должен быть некомпилируемым, а затем раскомментировать его для проверки.

Надуманный пример списка тестирования:

val list: List[Int] = List(1, 2, 3)
// should not compile
// list.add("Chicka-Chicka-Boom-Boom")

Обрабатывает ли одна из существующих библиотек тестирования такие случаи? Есть ли подход, который люди используют, который работает?

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

should {
  notCompile(<code>
    val list: List[Int] = List(1, 2, 3)
    list.add("Chicka-Chicka-Boom-Boom")
  </code>)
}

Или что-то вроде сценария типа expect, вызываемого интерпретатором.


person Mitch Blevins    schedule 07.12.2009    source источник


Ответы (1)


Я создал несколько спецификаций, выполняющих некоторые фрагменты кода и проверяющих результаты интерпретатора.

Вы можете ознакомиться с Фрагменты. Идея состоит в том, чтобы хранить в некотором org.specs.util.Property[Snippet] код для выполнения:

val it: Property[Snippet] = Property(Snippet(""))
"import scala.collection.List" prelude it // will be prepended to any code in the it snippet
"val list: List[Int] = List(1, 2, 3)" snip it // snip some code (keeping the prelude)
"list.add("Chicka-Chicka-Boom-Boom")" add it  // add some code to the previously snipped code. A new snip would remove the previous code (except the prelude)

 execute(it) must include("error: value add is not a member of List[Int]") // check the interpreter output

Основным недостатком, который я обнаружил при таком подходе, была медлительность интерпретатора. Я пока не знаю, как это можно ускорить.

Эрик.

person Eric    schedule 07.12.2009
comment
Это маленький кусочек потрясающего. Спасибо, что прочитали мои мысли! - person Mitch Blevins; 07.12.2009