Модульный тест в игре! Приложение Framework, не требующее тестового игрового сервера

Один из вариантов запуска моих тестов в моем Play! приложение, выполнив команду play auto-test.

Один из способов, с помощью которого Play идентифицирует тесты для запуска, состоит в том, чтобы найти все тестовые классы с суперклассом play.test.UnitTest (или другим эквивалентом Play). Расширение тестового класса UnitTest, по-видимому, связано с некоторыми накладными расходами, как показано в этом фрагменте, выплевываемом в консоль:

INFO   info, Starting C:\projects\testapp\.
WARN   warn, Declaring modules in application.conf is deprecated. Use dependencies.yml instead (module.secure)
INFO   info, Module secure is available (C:\play-1.2.1\modules\secure)
INFO   info, Module spring is available (C:\projects\testapp\.\modules\spring-1.0.1)
WARN   warn, Actually play.tmp is set to null. Set it to play.tmp=none
WARN   warn, You're running Play! in DEV mode
INFO   info, Connected to jdbc:h2:mem:play;MODE=MYSQL;LOCK_MODE=0
INFO   info, Application 'Test App' is now started !

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

Если у меня есть тестовый класс, который не расширяет UnitTest, то он не выполняется командой play auto-test. Есть ли способ заставить команду play auto-test выполнять все тесты независимо от того, расширяю ли я UnitTest Play?

Изменить:кто-то на самом деле поднял билет именно по этому вопросу


java testing playframework-1.x
person digiarnie    schedule 16.06.2011    source источник

Ответы (3)


arrow_upward
2
arrow_downward

короткий ответ: нет. Чуть более длинный ответ: нет, если вы не измените код в фреймворке. Автотест — это задача Ant, которая настраивает сервер и запускает тестирование, но не использует задачу ant, поэтому не обнаружит (по умолчанию) ваши «обычные» модульные тесты.

У вас есть два варианта: либо вы добавляете дополнительную задачу в Ant-файл Play для запуска модульных тестов через задачу (вам также нужно будет включить соответствующие jar-файлы), либо вы редактируете код, используемый для запуска тестовой среды Play.

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

person Pere Villega    schedule 16.06.2011
comment
Что ж, у меня есть несколько тестов, которые могут проверить классы, не требующие каких-либо игровых функций. Допустим, у меня есть математический класс, в котором есть метод с именем int add(int left, int right). Идея добавления двух чисел не должна требовать, чтобы у меня была тестовая среда. - person digiarnie; 17.06.2011
comment
@digiarnie Я понимаю, но идея тестирования состоит в том, чтобы запустить их все сразу, чтобы убедиться, что все в порядке, так что в этом сценарии это имеет смысл :) - person Pere Villega; 17.06.2011
comment
Я не уверен, что вы пытаетесь сказать там. Моя проблема в том, что автоматический тест не запускает все тесты, если я не расширяю UnitTest. Как вы сказали, идея тестирования состоит в том, чтобы запустить их все одновременно. автоматический тест воспроизведения игнорирует тесты, не расширяющие UnitTest (или какой-либо другой суперкласс воспроизведения)... - person digiarnie; 18.06.2011
comment
Хорошо, я имею в виду, что у вас есть код, который вы используете в Play. Вы хотите запустить все тесты этого проекта одновременно. Автотест Play распознает только тесты Play. Но если ваш код используется там, в проекте Play, имеет смысл превратить ваши тесты в Play Tests, так как вы хотите запускать их вместе с другими тестами проекта. Это проще (или должно быть), чем наоборот. Не используя тестовый формат Play в коде, используемом внутри Play, вы нарушаете соглашение о настройке фреймворка, и я не понимаю, почему в данном случае это требование :) - person Pere Villega; 18.06.2011
comment
одна причина: запуск отдельного теста в eclipse занимает вечность, если он должен начать воспроизведение. Было бы отлично, если бы play test нашел другие тесты и включил их по желанию. - person Chris Betti; 05.08.2013
comment
Я обнаружил, что расширение до UnitTest и использование @RunWith(Enclosed.class), например, заставляет его отображаться и запускаться с игровыми модульными тестами, но не использовать средство запуска игровых тестов в вашей среде IDE. Хаки однако... - person Stefan Hendriks; 22.07.2014

arrow_upward
0
arrow_downward

Если эти тесты не требуют Play! особенность, почему бы вам не поместить их в библиотеку? В вашем примере (добавление математики): создайте пакет calculate.jar и соберите его с помощью Ant или Maven после запуска тестов. Таким образом, вы можете использовать свою библиотеку в нескольких Play! проекты (или Spring, Struts,... если хотите.

person Neoh59    schedule 20.06.2011

arrow_upward
0
arrow_downward

Я действительно не понимаю, почему сама проблема вообще дискуссионна. Простые и небольшие юнит-тесты (даже в веб-части вашего проекта) — самое обычное дело. Дополнительные накладные расходы на инициализацию фреймворка значительно замедляют обмен данными, если у вас много тестов. Как видно из заявки, текущий обходной путь заключается в том, чтобы заставить ваши модульные тесты расширять org.junit.Assert вместо play.test.UnitTest.

person jonaskilian    schedule 17.11.2011