тесты подколенного сухожилия всегда проваливаются - PullRequest
43 голосов
/ 11 марта 2012

Я использую Hamcrest 1.3 для проверки моего кода. Это просто кубик. Я пытаюсь проверить это, чтобы убедиться, что сгенерированное число меньше 13. У меня был оператор print, в котором было напечатано, какое сгенерированное число было. Сгенерированное число всегда было меньше 13, но тест всегда не удался. Что-то я делаю не так?

Это код, который я тестирую.

import java.util.Random;

public class Die {
    private int numSides;
    Random rand;

    public Die(int numSides){
        this.numSides = numSides;
        rand = new Random(System.currentTimeMillis());
    }

    public int roll(){
        return rand.nextInt(numSides) + 1;
    }
}

А это мой тестовый код.

import static org.hamcrest.Matchers.*;
import static org.hamcrest.MatcherAssert.assertThat;

import org.junit.Test;

public class DieTest {
    @Test
    public void testRoll() {
        Die x = new Die(12);    
        assertThat(x.roll(), is(lessThan(13)));
    }
}

Редактировать: Это трассировка стека сбоев.

java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(Unknown Source)
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at DieTest.testRoll(DieTest.java:12)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Ответы [ 20 ]

0 голосов
/ 31 мая 2017

Я вошел в свойства сборки для проекта и изменил JUNIT с версии 4 на версию 3, и теперь он работает нормально.

Интересно, что у меня все еще есть версия 4 в моем pom.xml, поэтому я склонен думатьчто это проблема затмения (я смог собрать и запустить свои тесты через терминал просто отлично).

0 голосов
/ 08 мая 2017

Это решило мою проблему:

Замените $ ECLIPSE_HOME \ plugins \ org.hamcrest.core_1.3.0.v201303031735.jar на Maven или libc hamcrest-core-xx.jar вашего проекта (очевидно, переименовав его в то же имя, что и eclipse jar)

0 голосов
/ 07 мая 2017

моя среда Mac OS + eclipse, я обнаружил, что org.hamcrest.core_1.3.0.v201303031735.jar находится в моем JUnit 4, поэтому я не могу сделать это дальше, чем junit.jar.

, поэтому я удаляю его из пути ~ / .p2 / pool / plugins /, затем обновляю проект, все работает.

0 голосов
/ 16 июня 2019

Если вы используете Maven:

Шаги:

  1. Добавить последнюю зависимость Hamcrest в POM, отсюда https://mvnrepository.com/artifact/org.hamcrest/hamcrest-all

  2. Добавьте последнюю зависимость JUnit в POM, отсюда https://mvnrepository.com/artifact/junit/junit

  3. Удалите все библиотеки JUnit из пути сборки.

Как показано здесь

и здесь

После того, как вы выполнили все вышеперечисленные шаги, обновите ваш проект и запустите.
0 голосов
/ 28 ноября 2014

У меня была та же проблема, что и здесь.Я полагаю, что проблема сводится к JAR-файлу junit4.

Если в редакторе eclipse pom вы посмотрите на иерархию junit4, вы увидите, что она зависит от hamcrest-core (т.е. hamcrest-core по умолчанию будет задействован при компиляции).В своем коде модульного теста я использую коллекцию Hamcrest Matchers (org.hamcrest.collection).Они не включены в основной jar, и я установил зависимость от hamcrest-all в pom.Это дублирует включение ядра hamcrest и, по-видимому, оставляет вас открытым для несоответствия версий с зависимостью junit hamcrest-core и, следовательно, исключением безопасности.Я удалил зависимость hamcrest-all и заменил ее на hamcrest-library, и исключение ушло.

Если вы используете только базовый hamcrest, вам не следует устанавливать свою собственную зависимость и полагаться на версию, которую использует junit.В качестве альтернативы, как предлагается в другом комментарии, используйте junit-dep, чтобы убрать зависимость junit, а затем включите hamcrest-all.

0 голосов
/ 19 декабря 2017

Я сделал следующее:

Сначала в файле pom я исключил hamcrest-core из зависимости junit и использовал вместо него hamcrest-all. Во-вторых, я удалил из пути сборки затмение JUNIT, поскольку оно перекрывает maven. Порядок не повлиял на мои банки, так как плохая банка была исключена.

0 голосов
/ 08 мая 2018

У меня была точно такая же проблема. Я создал новый проект, и он решил мою проблему.

0 голосов
/ 01 апреля 2016

У меня недавно была эта проблема с затмением и Junit.

Чтобы решить эту проблему, я сделал это:

1 - Загрузите самую последнюю банку для хамкрестов отсюда: https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/hamcrest/

2- Перейдите в папку установки eclipse: eclipse / plugin / и найдите org.hamcrest ... jar

3 - сделать резервную копию баночки шага 2 и заменить ее банкой шага 1 (переименуйте ее так же, как банку шага 2).

4 - перезапустить затмение

После этого моя проблема была решена.

0 голосов
/ 05 июля 2019

Удалена библиотека JUNIT 4 из вкладки библиотек в Eclipse -> Путь сборки Java, и она заработала.

0 голосов
/ 26 августа 2016

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

Например:

  • Помещение JAR Hamcrest перед JAR JUnit в classpath будет работать в ситуациях, когда версия JUnitиспользуется (более старая версия) содержит классы Hamcrest
  • Наложение версии Hamcrest, используемой Eclipse для внутреннего использования, на «стандартную» версию, которая была переименована для соответствия внутренней версии, может работать, если никакой другой комплект подключаемых модулей Eclipse не использует информацию манифеста воригинальный внутренний JAR

В моем случае вышеуказанный симптом был вызван внутренним JAR Hamcrest, предоставленным Eclipse, и когда я попытался заменить его «стандартной» переименованной версией, все, что связано сНе удалось загрузить JUnit при запуске Eclipse.После того, как я вернулся к исходной внутренней версии, SecurityException вернулся.Решение, которое работало для меня, состояло в том, чтобы удалить манифест в JAR, используя 7-Zip.Это фактически «неподписанный» JAR, и теперь моя конкретная конфигурация работает.

...