Разделение классов JUnit в специальный пакет тестов?
Я учусь, понятие Разработки через тестирование посредством чтения статей Craftsman (нажмите Craftsman под Темой), рекомендуемый в ответе на мой предыдущий вопрос, "Демонстрационный проект для изучения JUnit и надлежащей разработки программного обеспечения". Я люблю его до сих пор!
Но теперь я хочу сесть и попробовать его сам. У меня есть вопрос, что я надеюсь, будет нуждаться только в простом ответе.
Как Вы организуете свои тестовые классы JUnit и свой фактический код? Я говорю главным образом о структуре пакета, но любые другие знаменитые понятия были бы полезны также.
Вы помещаете тестовые классы в org.myname.project.test.* и нормальный код в org.myname.project.*? Вы исправляете тестовые классы вместе с нормальными классами? Вы предпочитаете снабжать префиксом имена классов Тест, а не снабжать суффиксом их?
Я знаю, что это походит на вид вещи, о которой я не должен волноваться столь же скоро, но я - очень центральный организацией человек. Я - почти вид человека, который проводит больше времени, выясняя методы для отслеживания то, что быть сделанным вместо фактического добивания цели.
И у меня есть проект, который в настоящее время аккуратно делится в пакеты, но проект стал путаницей. Вместо того, чтобы пытаться осуществить рефакторинг все и тесты записи, я хочу запуститься новый, тесты сначала и так далее. Но сначала я должен знать, куда мои тесты идут.
править: Я полностью забыл о Знатоке, но кажется, что большинство Вас использует его! В прошлом у меня был определенный вариант использования, где Знаток полностью сломался на мне, но Муравей дал мне гибкость, в которой я нуждался, таким образом, я закончил присоединенный к Муравью, но я думаю, возможно, что я просто проявлял неправильный подход. Я думаю, что дам Знатоку другую попытку, потому что она кажется, что будет подходить к разработке через тестирование.
3 ответа
Я предпочитаю помещать тестовые классы в тот же пакет, что и тестируемые классы проекта, но в другой физический каталог, например:
myproject/src/com/foo/Bar.java
myproject/test/com/foo/BarTest.java
В проекте Maven это будет выглядеть так:
myproject/src/main/java/com/foo/Bar.java
myproject/src/test/java/com/foo/BarTest.java
Главное в этом то, что мои тестовые классы могут получать доступ (и тестировать!) к классам и членам пакета.
Как показано в примере выше, мои тестовые классы имеют имя тестируемого класса плюс Test в качестве суффикса. Это помогает быстро находить их - не очень забавно пытаться искать среди пары сотен тестовых классов, имя каждого из которых начинается с Test...
Update, вдохновленный комментарием @Ricket: таким образом тестовые классы (обычно) появляются сразу после своего тестируемого приятеля в алфавитном списке имен классов по проекту. (Забавно, что я получаю от этого пользу день за днем, сам того не осознавая...)
Update2: Многим разработчикам (включая меня) нравится Maven, но, похоже, есть как минимум столько же тех, кому он не нравится. IMHO он очень полезен для "мейнстримных" Java-проектов (я бы отнес к этой категории около 90% проектов... но остальные 10% - это все еще значительное меньшинство). Его легко использовать, если вы можете принять конвенции Maven; однако если нет, он превращает жизнь в жалкую борьбу. Maven кажется сложным для понимания многим людям, привыкшим к Ant, так как он, очевидно, требует совершенно иного образа мышления. (Сам я, никогда не использовавший Ant, не могу сравнить эти два подхода). Одно можно сказать наверняка: он делает модульное (и интеграционное) тестирование естественным, первоклассным шагом в процессе, что помогает разработчикам внедрить эту важную практику.
Я помещаю свои тестовые классы в тот же пакет, что и тестируемый продукт но в другую папку с исходным кодом или проектом. Такая организация тестового кода позволяет мне легко компилировать и упаковывать его отдельно, чтобы производственные jar-файлы не содержали тестовый код. Это также позволяет тестовому коду получить доступ к приватным полям и методам пакета.
Я использую Maven . Структура, которую продвигает Maven: -
src/main/java/org/myname/project/MyClass.java
src/test/java/org/myname/project/TestMyClass.java
т.е. тестовый класс с именем Test, добавленным к имени тестируемого класса, находится в структуре каталогов, параллельной основному тесту.
Одно из преимуществ наличия тестовых классов в одном пакете (хотя и не обязательно в каталоге) заключается в том, что вы можете использовать методы области действия пакета для проверки или внедрения ложных тестовых объектов.