Тестирование в Лиспе

Question

Я новичок в Лиспе и изучаю Схему через видеоролики SICP. Одна вещь, которая, кажется, не покрыта (по крайней мере, в тот момент, когда я нахожусь), это как проводить тестирование в Лиспе.

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

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

(Конечно, это очень грубое описание, и объекты можно использовать вертикально или даже как строительные блоки DSL.)

Мне было интересно, влияет ли это на тестирование лучших практик. Таким образом, вопрос является двойным:

1. Каковы лучшие практики при тестировании в Лиспе? Являются ли модульные тесты такими же фундаментальными, как и в других языках?
2. Каковы основные тестовые среды (если таковые имеются) для Лисп? Есть ли насмешливые рамки? Конечно, это будет зависеть от диалекта, но мне были бы интересны ответы для Scheme, CL, Clojure или других Lisps.

Answer 1

Вот конкретный ответ Clojure, но я ожидаю, что большая часть его будет в равной степени применима и к другим Лиспам.

Clojure имеет собственную среду тестирования, называемую clojure.test . Это позволяет просто определять утверждения с помощью макроса «is»:

(deftest addition
  (is (= 4 (+ 2 2)))
  (is (= 7 (+ 3 4))))

В целом, я считаю, что модульное тестирование в Clojure / Lisp соответствует рекомендациям, подобным тестированию для других языков. Это примерный принцип: вы хотите написать сфокусированные тесты, которые подтверждают ваши предположения о конкретном фрагменте кода.

Основные различия / особенности, которые я заметил в тестировании Clojure:

• Поскольку Clojure поощряет функциональное программирование, обычно бывает проще писать тесты, потому что вам не нужно слишком беспокоиться о изменяемом состоянии - вам нужно только подтвердить, что вывод исправить для данного ввода и не беспокоиться о большом количестве кода настройки и т. д.
• Макросы могут быть полезны для тестирования - например, если вы хотите сгенерировать большое количество тестов, которые программно следуют подобному шаблону
• Часто бывает удобно провести тест в REPL , чтобы быстро проверить ожидаемое поведение. Затем вы можете скопировать тестовый код в правильный модульный тест, если хотите.
• Поскольку Clojure является динамическим языком , вам может потребоваться написать несколько дополнительных тестов, которые проверяют тип возвращаемых объектов. Это было бы ненужным в статически типизированном языке, где компилятор мог бы обеспечить такие проверки.

Answer 2

RackUnit - это инфраструктура модульного тестирования, входящая в Racket , язык и реализацию, которые выросли из Scheme.Его документация содержит главу о его философии: http://docs.racket -lang.org / rackunit / index.html .

Answer 3

Мне известны две среды тестирования для Common Lisp: Stefil (в двух вариантах: hu.dwim.stefil и более ранняя версия stefil), FiveAM и lisp-unit.Поиск в списке библиотек quicklisp также обнаружил "unit-test", "xlunit" и monkeylib-test-framework.

Я думаю, что Stefil и FiveAM используются чаще всего.

Вы можете получить все из quicklisp.

Обновление: Только что увиденное в блоге Владимира Седача: Eos , который, как утверждают, является раскрывающимсязамена FiveAM без внешних зависимостей.