JUnit по сравнению с [закрытым] TestNG
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
8 ответов
Я использовал обоих, но я должен согласиться с Justin Standard, что Вы не должны действительно рассматривать перезапись Ваших существующих тестов ни к какому новому формату. Независимо от решения это довольно тривиально для выполнения обоих. TestNG стремится намного более настраиваться, чем JUnit, но в конце они оба работа одинаково хорошо.
TestNG имеет аккуратную функцию, где можно отметить тесты как конкретную группу, и затем легко запустить все тесты определенной группы или исключить тесты конкретной группы. Таким образом можно отметить тесты, которые работают медленно как в "медленной" группе и затем игнорируют их, когда Вы хотите быстрые результаты. Предложение из их документации состоит в том, чтобы отметить некоторое подмножество как тесты "регистрации", которые должны быть запущены каждый раз, когда Вы регистрируете новые файлы. Я никогда не видел такую функцию в JUnit, но с другой стороны, если у Вас нет его, Вы ДЕЙСТВИТЕЛЬНО не пропускаете его.
Для всех его требований высокой конфигурации, я действительно сталкивался с угловым случаем пару недель назад, где я не мог сделать то, что я хотел сделать... Мне бы хотелось помнить, каково это, но я хотел поднять его так, Вы знаете, что это не прекрасно.
самым большим преимуществом, которое имеет TestNG, являются аннотации... который JUnit, добавленный в версии 4 так или иначе.
Несколько дополнений к ответу Mike Stone:
1) самая частая вещь я использую группы TestNG для, когда я хочу выполнить единственный метод тестирования в наборе тестов. Я просто добавляю этот тест к группе "phil" и затем выполняю эту группу. Когда я использовал JUnit 3, я прокомментирую записи для всех методов, но тот, который я хотел выполнить в методе "комплекта", но затем буду обычно забывать не комментировать их перед регистрацией. С группами у меня больше нет этой проблемы.
2) В зависимости от сложности тестов, перемещая тесты от JUnit3 до TestNG может быть сделан несколько автоматически с sed и созданием базового класса для замены TestCase, что статический импорт все TestNG утверждает методы.
у меня есть информация о моей миграции от JUnit до TestNG здесь и здесь .
Самые большие карты ничьей TestNG для меня включают ее тестовые группы поддержки, и что еще более важно - тестовые зависимости группы (отмечающий тест, поскольку зависеть группы заставляет тесты просто пропускать выполнение, когда зависимая группа перестала работать).
другие карты большого преимущества TestNG для меня включают тестовые параметры, поставщиков данных, преобразователи аннотации и больше, чем что-нибудь - вибрирующее и быстро реагирующее пользовательское сообщество.
, Пока на поверхности нельзя было бы думать, все функции TestNGs выше не могли бы быть необходимы, после того как Вы начинаете понимать, что гибкость приносит к Вашим тестам, Вы зададитесь вопросом, как Вы справились с JUnit.
(правовая оговорка - я не использовал JUnit 4.x вообще, так не может действительно прокомментировать усовершенствования или новые возможности там).
Приблизительно год назад у нас была та же проблема. Я потратил когда-то, рассмотрев, какое перемещение было лучше, и в конечном счете мы поняли, что TestNG не имеет никаких 'уничтожающих функций'. Это хорошо, и имеет некоторые функции JUnit 4, не имеет, но нам не нужны они.
Мы не хотели, чтобы люди чувствовали себя, неловко пишущий тесты при узнавании TestNG, потому что мы хотели, чтобы они продолжали писать много тестов.
кроме того, JUnit является в значительной степени фактическим стандартом в мире Java. Нет никакого достойного инструмента, который не поддерживает его от поля, можно найти много справки в сети, и они добавили много новых опций в прошлом году, которое показывает, что это живо.
Мы решили придерживаться JUnit и никогда не оглядывались назад.
Сначала я сказал бы, не переписывайте все свои тесты только для удовлетворения последнему популярному товару. Работы Junit3 отлично и введение аннотаций в 4 не покупают Вас очень (по-моему). Намного более важно, чтобы Вы парни запись тесты, и это казалось, что Вы делаете.
Использование вообще кажется самым естественным и помогает Вам сделать свою работу.
я не могу прокомментировать TestNG b/c, я не использовал его. Но я рекомендовал бы unitils, большая обертка для JUnit/TestNG/DBUnit/EasyMock, независимо от которого маршрута Вы следуете. (Это поддерживает все упомянутые выше разновидности)
Также еще одно преимущество TestNG поддерживает параллельного тестирования. В нашу эпоху мультиядер это важно, я думаю.
я также использовал обе платформы. Но я использующий hamcrest для assertations. Hamcrest позволяет Вам, легко пишут, что Ваши собственные утверждают метод. Таким образом вместо
assertEquals(operation.getStatus(), Operation.Status.Active);
можно записать
assertThat(operation, isActive());
, Который дает Вам возможность использовать более высокий уровень абстракции в Ваших тестах. И это делает Ваши тесты более устойчивыми.
Я хотел поделиться тем, с чем столкнулся сегодня. Я обнаружил, что встроенный параметризованный бегун в Junit4 довольно груб, по сравнению с TestNG (я знаю, что у каждого фреймворка есть свои сильные стороны, но все же). Аннотация Junit4 @parameters ограничена одним набором параметров. Я столкнулся с этой проблемой при тестировании допустимого и недопустимого поведения для функциональности в том же тестовом классе. Таким образом, будет использован первый общедоступный статический аннотированный метод, который он найдет, но он может найти их в любом порядке. Это заставляет нас писать разные классы без необходимости. Однако TestNG предоставляет чистый способ предоставить разные типы поставщиков данных для каждого метода. Таким образом, мы можем протестировать один и тот же блок кода действительным и недопустимым способом в одном и том же тестовом классе, помещая действительные / недопустимые данные отдельно. Я пойду с TestNG.
Приветствую всех вышеупомянутых. Я лично обнаружил, что мне больше нравится в TestNG:
@BeforeClassдля TestNG происходит после создания класса, поэтому вы не ограничены только возможностью вызова статических методов ваш класс в нем.Параллельные и параметризованные тесты, может быть, мне просто не хватает жизни ... но я просто получаю удовольствие от написания одного набора тестов Selenium, принимая имя драйвера в качестве параметра. Затем определим 3 параллельные тестовые группы, по одной для драйверов IE, FF и Chrome, и наблюдаем за гонкой! Изначально я сделал 4, но слишком много страниц, над которыми я работал, по той или иной причине ломают драйвер
HtmlUnit.
Да, наверное, нужно найти ту жизнь. ;)