Рекомендации по включению модульных тестов в библиотеку

Question

Я работаю над общей библиотекой кода для ActionScript 3.0, которая называется as3lib который включает в себя несколько расширений основного API и некоторые полезные функции.Я написал несколько модульных тестов (используя FlexUnit), чтобы убедиться, что все работает правильно.

Каков наилучший способ организовать эти тесты в библиотеке? В настоящее время у меня есть весь мой код в src/ и мои тесты в test/ но я настроил вторичный проект Flex для запуска модульных тестов.Я также вручную добавляю и удаляю тестовые файлы из библиотеки, когда хочу запустить тесты.

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

Answer 1

Способ, которым мы сделали это в моей компании, заключается в том, что мы фактически включаем оба в исходный каталог, и тогда у нас есть два файла mxml приложения, которые мы используем.Одним из них является набор для тестирования, который включает в себя все соответствующие ссылки на классы модульного тестирования, другим является основное приложение.У нас также есть две структуры пакетов внутри папки src:одна структура пакета com.., а другая tests.com...Убедитесь, что ВСЕ исходным кодом для модульных тестов являются ВСЕГДА в пакете тестов - таким образом, вы можете использовать только одно игнорирование SVN, и вы также можете убедиться, что ваши тесты не создают зависимых и жестко запрограммированных отношений с другими проектами.

Есть два способа, которые мы используем, чтобы убедиться, что исходные файлы test.com не включены.Система автоматической сборки ссылается только на основное приложение, и поскольку оно импортирует только из com., mxmlc.exe будут включены только файлы для основного приложения.При локальной сборке внутри eclipse вы можете управлять процессом сборки, нажав на маленькую стрелку рядом с надписью Debug и выделив пункт "Упорядочить избранное". Когда вы нажмете "Добавить", вы сможете выбрать все файлы .mxml корневого уровня, которые ссылаются на класс Application.Обязательно добавьте базовое приложение и новый файл приложения для модульного тестирования.Когда вы затем нажимаете "ОК", стрелка теперь позволяет вам выполнять отладку либо как основного приложения, либо как вашей платформы модульного тестирования.

Кроме того, мы также используем FlexUnit в качестве нашей платформы тестирования.Мне это нравится.

Answer 2

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

Answer 3

У нас есть отдельные каталоги src иtests на верхнем уровне наших библиотек.Наши приложения представляют собой очень тонкую оболочку библиотечных проектов, поэтому им не нужны никакие тесты.У нас также есть проект приложения FlexUnit для запуска тестов из FlexBuilder.

Мы используем maven для нашей основной системы сборки, а плагин Sonatype Flex запускает все наши модульные тесты во время сборки, даже на нашем сервере Continuum на базе Linux.По умолчанию Maven ищет тесты в каталоге «tests», что является хорошим оправданием для выбора этого места.

Answer 4

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

1. Разделение интересов.Во-первых, у вашей библиотеки одно назначение, у тестов — другое.Хотя для работы тестов необходима библиотека, библиотека не имеет реальной пользы для тестов. Примечание Я не говорю, что тесты бесполезны, это далеко не так.Тесты предназначены для проверки работоспособности библиотеки, но в производственной среде тесты бесполезны.

2. Меньше раздувания, меньше файлов.Тесты не всегда тривиальны.Но даже если бы они все были такими, они все равно использовали бы дисковое пространство.Поскольку тесты в любом случае не используются в производственной среде, это бессмысленно.Кроме того, разделение тестов на новый проект делает структуру файла намного чище.

3. Среды CI, как правило, проще настраивать, когда нет тестов.

Хотя, по крайней мере, вторую проблему можно решить с помощью директив компилятора, это ненужная работа, когда гораздо проще просто разделить их.Тестирование библиотеки или приложения, которое может потребовать от вас использования одного и того же пространства имен (кто-нибудь из внутренних классов?), также не является проблемой, поскольку ваш проект тестов может отражать пространства имен.Очевидно, что это приводит к необходимости предотвращения конфликтов имен в пространствах имен, но это тривиально.

С точки зрения поддержки Flash Builder было бы здорово разделить все на два проекта.Все, что вам нужно сделать для создания нового теста, — это щелкнуть правой кнопкой мыши по классу, который вы хотите протестировать, попросить создать новый тест и убедиться, что вы выбрали свой проект тестов вместо текущего в появившемся диалоговом окне.Это действительно главная причина, почему мне и членам моей команды было трудно оправдать написание тестов, когда мы перешли к TDD, слишком много накладных расходов, чтобы просто начать.При нынешнем состоянии IDE это до смешного просто и полезно.

Однако, как и в любой технике, здесь есть предостережения.Во-первых, не очевидно, что тесты находятся в другом проекте, если это не задокументировано.Наличие тестов в одном проекте эффективно решает эту проблему.С другой стороны, эту проблему легко решить, настроив maven или другие инструменты управления зависимостями, которые могут быть в вашей среде.Другая проблема заключается в том, что если в вашем проекте тестов есть структура пакета, которая отражает структуру библиотеки или приложения, синхронизация этих структур потребует некоторых затрат на обслуживание.Хотя это не такая уж большая проблема и ее довольно легко решить с помощью сценариев, о ней все же стоит упомянуть.

Во всяком случае, я так делаю.