Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Регистрация Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Блоги > С миру по строчке

Рейтинг: 5.00. Голосов: 3.

Тестирование кода. Разворачиваем проект с помощью Gradle.

Запись от СлаваRa размещена 01.11.2015 в 05:33
Обновил(-а) СлаваRa 01.11.2015 в 15:21

Для многих пишущих на ActionScript3 тема тестирования покрыта мраком. Многие хотят использовать тесты, но не знают как начать... поэтому наша цель - создать проект, который не зависит от платформы и редактора, легко разворачивается и пригоден для многократного использования.

В прошлой статье мы разворачивали проект с помощью Apache Ant, в этот раз мы возьмем более современный инструмент - Gradle, если он у Вас не установлен, то необходимо его скачать, распаковать и добавить в переменные окружения путь_к_папке_куда_он_был_распакован/bin.

Первым делом создадим файл содержащий локальные настройки проекта
gradle.properties
Код:
// Путь к flex sdk
FLEX_HOME = 
// Путь к Flash player в котором будут запущены тесты
FLASH_PLAYER_EXE = 
// Версия плеера, этот параметр используется при компиляции
TARGET_PLAYER = 19.0
// URL до архива с тестовым фреймворком, вынужденная мера, т.к. ни в одном из доступных репозиториев
// нет последних версий библиотек
URL_FLEXUNIT = http://www.eu.apache.org/dist/flex/flexunit/4.2.0/binaries/apache-flex-flexunit-4.2.0-4.12.0-bin.zip
// Путь к директории временных файлов
TMP_DIR = tmp
// Путь к библиотекам, которые необходимы для тестирования
LIB_FLEXUNIT = lib/flexunit
Обратите внимание на то, что кавычки для значений констант ставить не надо!
При использовании системы контроля версий такие файлы добавляются в игнорлист, а в систему контроля версий добавляется gradle.properties.sample - это необходимо чтобы иметь возможность настраивать проект локально


Далее необходимо создать скрипт, который будет запускать тестирование
build.gradle
Код:
buildscript {
    repositories {
        mavenLocal()
        mavenCentral()
        jcenter()
    }
    dependencies {
        classpath 'org.gradlefx:gradlefx:1.3.0'
        classpath 'de.undercouch:gradle-download-task:2.0.0'
    }
}
apply plugin: 'gradlefx'
apply plugin: 'de.undercouch.download'
repositories {
    mavenLocal()
    mavenCentral()
}
dependencies {
    test fileTree(dir: "$LIB_FLEXUNIT/flexunit", include: '*.swc')
    test fileTree(dir: "$LIB_FLEXUNIT/flexunit", include: '*.jar')
}
flexHome = FLEX_HOME
frameworkLinkage = 'none'
type = 'swc'
srcDirs = ['src']
testDirs = ['test/src']
flexUnit {
    command = FLASH_PLAYER_EXE
    additionalCompilerOptions = [
        "-target-player=$TARGET_PLAYER",
        '-incremental=true'
    ]
}
task downloadFlexUnit(type: de.undercouch.gradle.tasks.download.Download) {
    src URL_FLEXUNIT
    dest new java.io.File(TMP_DIR, "flexunit.zip")
}
task downloadAndUnzipFlexUnit(type: Copy) {
    if (!file("$LIB_FLEXUNIT/flexunit").exists()) {
        dependsOn downloadFlexUnit
        from zipTree(downloadFlexUnit.dest)
        into LIB_FLEXUNIT
    }
}
test.dependsOn downloadAndUnzipFlexUnit
Обратите внимание, на то что путь к исходному коду обязателен, как и его физическое наличие, даже для пробного проекта, в данном случае это папка src в корне проекта

Наш тестовый проект готов, но для полноты картины в файле gradle.properties установим путь до flex sdk в константу FLEX_HOME, а в константу FLASH_PLAYER_EXE путь до flash плеера и создадим первый тест в test/src
SimpleTest.as
Код AS3:
package {
	import org.flexunit.asserts.assertTrue;
	public class SimpleTest {
 
		[test]
		public function alwaysTrue():void {
			assertTrue(true);
		}
	}
}
После чего откроем командную строку в директории проекта и выполним команду gradle test, результатом которой должен быть лог
Код:
...
[ant:flexunit]                                                                           
[ant:flexunit] Suite: SimpleTest                                                         
[ant:flexunit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,037 sec 
[ant:flexunit]                                                                           
[ant:flexunit] Results :                                                                 
[ant:flexunit]                                                                           
[ant:flexunit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,037 sec 
[ant:flexunit]                                                                                                                                                                    
BUILD SUCCESSFUL
Исходники к статье

зы
подход со скачиванием zip архива с тестовым фреймворком совсем не хороший, и я по возможности постараюсь залить библиотеки в maven репозиторий, но в данный момент времени на это нет(
Всего комментариев 24

Комментарии

Старый 01.11.2015 12:00 Psycho Tiger вне форума
Psycho Tiger
 
Аватар для Psycho Tiger
Шикардос! Осталось объяснить флешерам, зачем им нужны тесты. Это, по моему опыту, самое сложное
Старый 01.11.2015 14:19 F10 вне форума
F10
Цитата:
зачем им нужны тесты.
Флеш это все таки вижуал. Для меня покрытие тестами GUI до сих пор не освоенный навык.
Здесь мало синхронного кода, нужно ждать все события вида "добавили на сцену" и т.п. Почти любое гуи пишется так, что бы работало только при фактическом отображении на экране - а в условии запуска его тестом - это непросто сымитировать.
В том же FlexUnit это пытаются упростить через сервисы вроде StageMediator (или как он там называется) и то он не всегда помогает.
Старый 01.11.2015 14:39 СлаваRa вне форума
СлаваRa
 
Аватар для СлаваRa
Возьмите любую соц. игру, и вы поймете, что это не только GUI.
Посмотрите на тот же Starling и Feathers это GUI библиотеки, так вот они покрытыми тестами.
Если вам нужны интеграционные тесты взаимодействия данных gui и пользовательских действий - то это материал для целой статьи, а не комментария к этой
Обновил(-а) СлаваRa 01.11.2015 в 14:58
Старый 01.11.2015 17:32 alexandrratush вне форума
alexandrratush
 
Аватар для alexandrratush
Цитата:
Флеш это все таки вижуал.
А как же модели из того же MVC? Можно же их хотя бы покрыть тестами. Конечно если флешка состоит из 10 классов, то тестировать там особо нечего.
СлаваRa, спасибо за Gradle, попробую запустить. До этого все руки не доходили. Как там с Maven? Будет статья?
Старый 01.11.2015 21:44 СлаваRa вне форума
СлаваRa
 
Аватар для СлаваRa
Цитата:
Как там с Maven? Будет статья?
Ну раз есть спрос, то будет, хоть я и не сторонник maven

Цитата:
Конечно если флешка состоит из 10 классов, то тестировать там особо нечего.
Ой не факт, тестирование - это не только прогон тестов, это и "культура" написания кода, и способ решения задач, постараюсь написать про это позже
Старый 01.11.2015 22:57 GBee вне форума
GBee
 
Аватар для GBee
Цитата:
Осталось объяснить флешерам, зачем им нужны тесты. Это, по моему опыту, самое сложное
Угу, сколько не пытался понять, зачем тратить на них время и как вообще их правильно писать все упирается в пример подобного кода:

Цитата:
Код AS3:
package {
	import org.flexunit.asserts.assertTrue;
	public class SimpleTest {
 
		[test]
		public function alwaysTrue():void {
			assertTrue(true);
		}
	}
}
И тонны воды вокруг.

Цитата:
Ой не факт, тестирование - это не только прогон тестов, это и "культура" написания кода, и способ решения задач, постараюсь написать про это позже
Буду ждать.
Старый 01.11.2015 23:19 alexandrratush вне форума
alexandrratush
 
Аватар для alexandrratush
Цитата:
Угу, сколько не пытался понять, зачем тратить на них время и как вообще их правильно писать все упирается в пример подобного кода:
В умных книжках пишут, что покрытие кода тестами защищает от ошибок при изменении кода в будущем, и позволяет этот код менять не боясь что станет еще хуже. И когда вы садитесь рефакторить или оптимизировать код, который был написан год назад, то без тестов это самоубийство, лучше уже все переписать с нуля.
Старый 02.11.2015 00:13 СлаваRa вне форума
СлаваRa
 
Аватар для СлаваRa
Цитата:
Угу, сколько не пытался понять, зачем тратить на них время и как вообще их правильно писать
Я сейчас выбираю на примере чего лучше показать TDD, вариант, которые есть у меня:
- написать небольшой фреймворк
- написать небольшую игру
- может быть предложенный вариант

что выбираем?
Старый 02.11.2015 00:52 alexandrratush вне форума
alexandrratush
 
Аватар для alexandrratush
Игру.
Старый 02.11.2015 00:56 illuzor вне форума
illuzor
 
Аватар для illuzor
СлаваRa, игру.
Старый 02.11.2015 10:22 F10 вне форума
F10
Игру.
Фреймворки как правило более структурированы, их легче покрыть тестами.
Старый 02.11.2015 12:51 Tails вне форума
Tails
 
Аватар для Tails
Да, примерчик бы из практики не помешал.
Старый 02.11.2015 20:06 СлаваRa вне форума
СлаваRa
 
Аватар для СлаваRa
ну давайте, чтобы интереснее было выбираем игру:
- монополия
- lines 97
Старый 02.11.2015 22:30 GBee вне форума
GBee
 
Аватар для GBee
Цитата:
ну давайте, чтобы интереснее было выбираем игру:
- монополия
- lines 97
В чем подвох? Почему не сапер?
Я за линии, в монополии сплошная логика.
Старый 02.11.2015 23:12 СлаваRa вне форума
СлаваRa
 
Аватар для СлаваRa
мне с детства нравятся две этих игры)) подвоха нет
Старый 03.11.2015 06:01 kemsky вне форума
kemsky
Тесты писать сравнительно легко, а вот полностью автоматизировать их выполнение не очень.
Конечно, если можно зафиксировать локально сдк, плеер, либы, конфиги - то достаточно в идее нажимать кнопку выполнить тесты. Минус очевидный - всем в команде надо сетапить одинаковое окружение. Второе - нету инфы о покрытии кода тестами, что очень-очень полезно, иначе не видно все ли протестировано. Третье - нету автоматических тестов при комитах в систему контроля версий.

Недавно как раз заморочился с тестами (поборол, но не до конца, жалко времени). Плагин flexmojos для мавена позволяет автоматизировать все кроме флешплеера, для него отдельный скрипт, а именно:
1. сборку
2. выполнение юнит тестов
3. отчет по покрытию кода тестами
4. генерацию документации

Github и Travis CI(система непрерывной интеграции) дружат из коробки, что позволило автоматически деплоить артефакты из тревиса в релизы на гитхабе, тоесть при создании тэга все будет автоматически проверено, все отчеты будут подготовлены и артефакты задеплоены, вот это дело! Плюс ничего не надо настраивать в идее и докачивать локально. К сожалению, flexmojos полумертвое, но пока работает.

GradleFx выглядит поживее,современнее и наверняка гибче, покрытия кода похоже нет. Gradle не обязательно качать - есть gradlew.
Старый 03.11.2015 13:00 GBee вне форума
GBee
 
Аватар для GBee
Цитата:
автоматически деплоить артефакты из тревиса в релизы на гитхабе
вижу русские предлоги
Старый 03.11.2015 13:15 СлаваRa вне форума
СлаваRa
 
Аватар для СлаваRa
@kemsky, это вы сейчас вообще к чему?

Цитата:
а вот полностью автоматизировать их выполнение не очень.
Это довольно простой процесс, если хотите я могу осветить и этот момент

Цитата:
Тесты писать сравнительно легко
Сравнительно с чем?

Ну и по комментарию, вы заметку то читали? она про то как развернуть проект, который будет работать локально без IDE и со своими настройками, речи про CI или степень покрытия не велось, т.к. не относится в теме статьи. Такое ощущение, что вы просто выписали все что примерно знаете.
Старый 03.11.2015 15:55 kemsky вне форума
kemsky
Это Вы не читали комментарий)

Развернуть проект можно автоматически, не скачивая флекс, не устанавливая переменные окружения, не скачивая грейдл, не занимаясь распаковкой и настройкой всего этого, бонус - полная поддержка в иде (если захочется подебажить ничего дополнительно делать не нужно). Непрерывная интеграция тоже идет бонусом - минимум настроек и конфигурирования.

Тестирование и покрытие связаны напрямую, без покрытия вы не видите, что протестировали, а что нет.
Старый 03.11.2015 16:25 СлаваRa вне форума
СлаваRa
 
Аватар для СлаваRa
- добавить таски автоинстал sdk не проблема, но это не имеет отношения к статье, астройка flexHome предполагается в gradlefx из коробки, поэтому ручная установка этого параметра, по-моему не преступление
- gradlew хорошее решение для CI, но не очень подходящее для локальной работы
- не все IDE поддерживают gradle
- CI не идет из коробки и не может быть бонусом, т.к. это отдельный сервис, и отдельная тема
- степень покрытия тестами, это может быть хороший показатель, но и без него видно что покрыто, плюс она, степень покрытия, не говорит о правильности и нужности тестов и т.д., но и это тоже отдельная тема
- flexmojos имеет отношение к maven, но не gradle, да и не поддерживается довольно давно.
...

цель статьи создать проект, который не зависит от платформы и редактора
по этому мнение, что в комментарии вы написали все, что примерно знаете, у меня остается
Старый 03.11.2015 16:38 kemsky вне форума
kemsky
Не вижу противоречия, поэтому повторяться не буду, дело ваше.
Старый 03.11.2015 17:04 СлаваRa вне форума
СлаваRa
 
Аватар для СлаваRa
ну например,

Цитата:
не скачивая грейдл
Цитата:
- есть gradlew.
gradlew не берется из воздуха, для его генерации необходим установленный gradle, если вы конечно не настолько суровы чтобы писать его руками.
Целью статьи, была минимальным кол-вом текста, добиться 1 конкретного результата, получить тестовый проект на любой машине, не забивая голову читателя гитхабом, ide, ci, travis, flexmojos и т.д.
я не собирался мешать все и вся в одну кучу, как и для какой CI системы настроить проект я опишу в других статьях в ближайшее время
Старый 03.11.2015 19:20 Psycho Tiger вне форума
Psycho Tiger
 
Аватар для Psycho Tiger
Знаю, что оффтоп, но метрика покрытых LOC меня всегда смущала.
Например, дотошные юнит тесты на все самые важные моменты (оставляя "простой" и боилерплейт код нетронутыми) даст ощутимо меньший эффект покрытия, чем десяток интеграционных/e2e. При этом эти интеграционные тесты дают почти ничего, т.к. покрываются, по большей части, самые примитивные и очевидные кейсы, мол, что "приложение не развалиться, на случай если вы его даже не запускали".
Хорошее покрытие критически важных моментов, особенно тех, что сложно протестировать вручную сильно важнее.

То, что тесты бегут в CI это замечательно, но с претензией на такую развёртку, я уверен, практикуется и ревью кода, и пул реквесты. Если Трэвис/Магнум/Дженкинс/Кто-то ещё не могут (хотя Слава сказал, что могут и я ему верю) – то запустить тесты локально у того, кто делает ревью кода перед мерджем это небольшая проблема. Запустил тесты, затем код читать. Или вообще заставлять их прогонять перед пушем – вообще отвал башки! Корпоративная этика.
Старый 05.11.2015 17:24 carrotoff вне форума
carrotoff
 
Аватар для carrotoff
В 21 веке можно не заставлять, ну по крайней мере, если использовать гитхаб

Можно настроить интеграцию вашего CI-сервера с гитхабом так, чтобы при создании пулл-реквеста запускалась определенная билд-конфигурация, которая прогоняла нужные вам тесты:
- code style
- юнит или интеграционные тесты
- любые другие проверки

По результатам билда сервер пушит сообщение на гитхаб с помощью commit status api, ну и человек, проводящий ревью будет уверен, что ваш пул реквест не поломал проект, ну или наоборот - увидит, что все сломалось и пристыдит вас.

Вот так выглядят данные статусы на гитхабе
 

 


Часовой пояс GMT +4, время: 13:44.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2019, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.