Модульные тесты Java, [закрытое] расположение каталога
В некоторых странах можно проверить 112 как действительный телефонный номер, но если Вы засунете код страны перед ним, то это больше не будет допустимо. В других странах Вы не можете проверить 112, но можно проверить 911 как действительный телефонный номер.
я видел некоторые телефоны, которые помещают Q на 7 ключей и Z на 9 ключах. Я видел некоторые телефоны, которые помещают Q и Z на 0 ключах, и некоторых, которые помещают Q и Z на 1 ключе.
код зоны, который существовал вчера, не мог бы существовать сегодня, и наоборот.
В половине Северной Америки (код страны 1), второе правило цифры раньше было 0 или 1 для кодов зоны, но то правило ушло 10 лет назад.
5 ответов
Вы можете поместить тесты в тот же пакет, что и исходные классы, даже если исходный код находится в собственном корневом каталоге:
PROJECT_ROOT
+--- src/
+----test/
Вы можете объявить класс com.foo .MyClass под src и его тест com.foo.MyClassTest под тест .
Что касается доступа к закрытым членам, вы можете использовать отражение для вызова методов (изменяя их доступность через Class.getDeclaredMethod.setAccessible ), или вы можете использовать что-то вроде testng / junit5, чтобы поместить некоторые тесты на основе аннотаций в сам исходный код (я лично считаю, что это плохая идея).
Почему бы не проверить некоторые проекты на java.net , чтобы увидеть, как они организованы вещи, например swinglabs (я боюсь, репозиторий SVN работает довольно медленно)?
Я рекомендую следовать стандартной структуре каталогов Apache Software Foundation , которая дает следующее:
module/
src/
main/
java/
test/
java/
Это позволяет хранить тесты отдельно от исходного кода, но на одном уровне в структуре каталогов. . Если вы прочитаете, как Apache определяет свою структуру, вы увидите, что это помогает разделить и другие проблемы, включая ресурсы, файлы конфигурации, другие языки и т. Д.
Эта структура также позволяет модульным тестам тестировать пакеты и методы защищенного уровня тестируемых модулей, предполагая, что вы помещаете свои тестовые примеры в тот же пакет, что и тестируемый. По поводу тестирования приватных методов - не заморачивался. Что-то еще, общедоступное, пакетное или защищенное, вызывает их, и вы должны иметь возможность получить полное тестовое покрытие, проверяя эти вещи.
Между прочим, ссылка выше относится к Maven, Apache ' стандартный инструмент сборки. Каждый проект Java, который у них есть, соответствует этому стандарту, а также все проекты, с которыми я столкнулся, построены с помощью Maven.
В большинстве случаев это делается следующим образом:
<SOME_DIR>/project/src/com/foo/Application.java
<SOME_DIR>/project/test/com/foo/ApplicationTest.java
Итак, вы держите их отдельно, и вы все равно можете протестировать пакет / защищенную функциональность, потому что тест находится в одном пакете.
Вы не можете тестировать личные данные, если они не объявлены внутри самого класса.
При доставке вы просто упаковываете .class , сгенерированный src, а не тесты
На самом деле имеет смысл разделить ваши производственный и тестовый проекты на 2 отдельных объекта, но иметь одинаковую структуру пакетов в обоих проектах.
Итак, если у меня есть проект, мой -project 'Я также создаю' my-project-test ', поэтому у меня следующая структура каталогов:
my-project
+--- src/com/foo
my-project-test
+---test/com/foo
Такой подход гарантирует, что зависимости тестового кода не загрязняют производственный код.
По моему личному мнению, пакет является частным и защищенным методы должны быть протестированы так же, как и общедоступные методы. Следовательно, я хочу, чтобы мои тестовые классы были в том же пакете, что и производственные классы.
Вот как мы это настроили, и нам это нравится.
build/
src/
test/build/
test/src/
Весь тестовый код компилируется в свой собственный каталог сборки. Это потому, что мы не хотим, чтобы производственная среда по ошибке содержала тестовые классы.