Дополнение тестовых батарей JUnit динамическими языками JVM

Question

Я хочу начать перенос серии подробных модульных тестов (большие jsons, не встраиваемые в стандартную Java, много проверок полей bean-компонентов) на более выразительный язык (например, Clojure, Groovy, Jython).

По моему опыту, языками, которые должны дополнять стандартный исходный код Java, являются Clojure и Groovy. Возможно, Rhino или BeanShell можно было бы использовать здесь, но у меня нет опыта работы с ними ...

Любые другие предложения приветствуются:

Мои требования:

1) Язык должен работать в том же окружении, что и мой код Java EE.

2) Язык должен иметь возможность встраивать большой многострочный текст в строки.

3) Модульные тесты языка должны запускаться как обычные тесты JUnit для задач / целей ANT и junit.

4) Модульные тесты языка должны быть в состоянии вызывать обычный код и работать с зависимостями в моей базе исходного кода (то есть он должен иметь доступ к классам на моем пути к классам, как в моем обычном тестовом пакете junit) изначально, без проблем .

Мои вопросы:

1) Можно ли писать исходный код на одном языке, а также писать тесты junit на другом языке junit, и если да, то есть ли примеры этого?

2) Если да, какой язык (языки) лучше всего удовлетворяют требованиям 1-3 выше.

Кроме того, любой значимый комментарий о достоинствах этого предложения "напишите в java, junit tests in *" был бы полезен.

Спасибо!

Answer 1

Когда-то я искал библиотеку для тестирования, которая соответствует тем же требованиям, а некоторые вроде

• та же структура от модульного тестирования, интеграционного тестирования и сквозного тестирования
• упрощенное и интуитивно понятное тестирование на основе данных
• BDD вид тестирования
• Переход должен быть прогрессивным (т. Е. Мы являемся магазином Java, и если кто-то не хочет использовать преимущества Groovy, он все еще может использовать Java)

И spock - это мощный фреймворк, отвечающий всем требованиям. Мы можем смешать JUNIT и Spock вместе. Спок генерирует отчеты в том же формате, что и Junit и т. Д.

Примеры

1. интеграционное тестирование: плагин Spock Grails, Spring и Unitils
2. сквозное тестирование пользовательского интерфейса: Геб + Спок
3. Сквозное приложение к интерфейсам приложений, таким как веб-сервисы и т. Д .: HttpBuilder + http://groovy.codehaus.org/GroovyWS + Спок

Answer 2

Я пишу множество тестов на easyb , языке BDD на основе Groovy. JRuby и RSpec - еще один отличный вариант. Почему существует требование, чтобы тесты запускались «как тесты JUnit», и что именно это означает?

Если это фактическое требование, вы ограничиваете выразительность своих тестов (я не большой поклонник JBehave). Groovy - мой предпочтительный язык при создании проекта на реальном языке Java +, хотя я использую JRuby для интерфейсов командной строки приложения.

Поддержка аннотаций в Groovy является первоклассной и беспроблемной, IMO - это простой выбор для простоты принятия для написания тестов JUnit, более или менее, как вы пишете их на Java, но в Groovy.

Answer 3

Вы используете IDE? Если это так, то извините, что я скучный старый пердун, но я бы посоветовал сохранить ваши тесты на Java.

Причина этого в том, что IDE, по моему опыту, не имеют или плохо поддерживают работу с гетерогенными кодовыми базами. Подумайте о переименовании метода в коде вашего приложения. В любой приличной среде IDE вы делаете это как рефакторинг, и все сайты вызовов в коде Java изменяются в соответствии с новым именем. Однако звонить на сайты на других языках не буду (насколько я знаю). Если ваши тесты не в Java, это означает, что теперь у вас есть куча неработающих тестов, которые нужно найти и исправить. Только потому, что вы переименовали метод! Многие виды рефакторингов поднимут эту проблему. Вы также можете страдать от невозможности совместного использования отладчика в тесте и коде приложения, выполнения анализа покрытия кода или выполнения других полезных действий.

Использование нетипизированного языка, такого как Javascript или Groovy, как он обычно используется, также по своей сути означает, что ваши тесты не могут делать утверждения о типах и, следовательно, не могут тестировать весь спектр вещей, которые могут пойти не так в Java , Например, в тесте Java я могу написать:

List<CharSequence> words = foo.getWords();

И чтобы этот тест даже компилировался, getWords должен возвращать List<CharSequence>. Если кто-то изменит его на List<String>, тест прекратится. Это позволяет использовать тест для обеспечения разработки API.

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

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

Я не знаю точно, что включает в себя ваша "большая проверка полей bean-компонентов", но если она проверяет значения в полях bean-компонентов, возможно, глубоко вложенных, то некоторые простые служебные методы могут сильно помочь. Возможно, вы могли бы прочитать спецификации полей и их ожидаемые значения из файлов свойств, а затем рефлексивно извлечь и проверить их?