Я пытаюсь проверить статический java-метод в пассивной структуре SPOCK с использованием Maven.Как проверить статические java-методы в пассивной структуре SPOCK?
Вот ява класс
public class DataController {
private DataInterface userService;
public void setUserService(DataInterface userService) {
this.userService = userService;
}
public static int addNumber(){
int a = 10;
int b = 20;
return a+b;
}
}
Вот тест SPOCK в заводной
@PrepareForTest([DataController.class])
class BasicMockStaticTest extends Specification {
@Rule PowerMockRule powerMockRule = new PowerMockRule();
def "When mocking static"() {
setup :
PowerMockito.mockStatic(DataController.class)
when :
Mockito.when(DataController.addNumber()).thenReturn(30);
then :
DataController.addNumber() == 30
}
}
и фрагмент ПОМ файла
<dependencies>
<!-- Spock Framework basic dependencies: -->
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.3.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.spockframework</groupId>
<artifactId>spock-core</artifactId>
<!-- The version have to be compatible with Groovy -->
<version>1.0-groovy-2.3</version>
<scope>test</scope>
</dependency>
<!-- To use Hamcrest matchers: -->
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
<version>1.3</version>
<scope>test</scope>
</dependency>
<!-- To mock classes: -->
<dependency>
<groupId>cglib</groupId>
<artifactId>cglib-nodep</artifactId>
<version>3.1</version>
<scope>test</scope>
</dependency>
<!-- Use with cglib to mock classes without default constructor: -->
<dependency>
<groupId>org.objenesis</groupId>
<artifactId>objenesis</artifactId>
<version>2.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>1.5</version>
</dependency>
<!-- Power mock dependencies -->
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-module-junit4</artifactId>
<version>1.5.4</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-module-junit4-rule</artifactId>
<version>1.5.4</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-classloading-xstream</artifactId>
<version>1.5.4</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<testSourceDirectory>E:\Workspace\Mars\rg\Spock\src\test\groovy</testSourceDirectory>
<pluginManagement>
<plugins>
<!-- GMavenPlus plugin -->
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<goals>
<goal>addSources</goal>
<goal>addTestSources</goal>
<goal>generateStubs</goal>
<goal>compile</goal>
<goal>testGenerateStubs</goal>
<goal>testCompile</goal>
<goal>removeStubs</goal>
<goal>removeTestStubs</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Only required if names of spec classes don't match default Surefire patterns (`*Test` etc.) -->
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.6</version>
<configuration>
<useFile>false</useFile>
<includes>
<include>**/*Test*.*</include>
<include>**/*Spec*.*</include>
</includes>
У меня есть 4 тестовых случаев в заводной папка, 3 проходят, но этот статический метод теста дает ошибку как
When mocking static(BasicMockStaticTest) Time elapsed: 0.104 sec <<< ERROR!
java.lang.IllegalStateException: Extension API internal error: org.powermock.api.extension.proxyframework.ProxyFrameworkImpl could not be located in classpath.
at org.powermock.modules.junit4.rule.PowerMockClassloaderExecutor.registerProxyframework(PowerMockClassloaderExecutor.java:60)
at org.powermock.modules.junit4.rule.PowerMockClassloaderExecutor.forClass(PowerMoc kClassloaderExecutor.java:50)
at org.powermock.modules.junit4.rule.PowerMockRule.apply(PowerMockRule.java:31)
at org.spockframework.runtime.extension.builtin.MethodRuleInterceptor.intercept(MethodRuleInterceptor.java:37)
at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:87)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103)
at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Я запускаю тест mvn для проверки этих юнитов, я попытался изменить версию cglib-nodep от 3.1 до 2.2.2, но это не сработало.
Я проверил в пути компоновки Java следующие баночка файлы включены
powermock-module-junit4-1.5.4
powermock-module-junit4-common-1.5.4
powermock-reflect-1.5.4
powermock-module-junit4-rule-1.5.4
powermock-classloading-base-1.5.4
powermock-classloading-xstream-1.5.4
powermock-api-support-1.5.4
powermock-core-1.5.4
groovy-all-2.3.1.jar
spock-core-1.0-grovy-2.3.jar
Я также добавил powermock-Mockito-релиз-полный 1.5.4, но после того, добавив, что ни один из тестов не прибежал и сборки было но это не было моим намерением.
Я подозреваю, что некоторые из зависимостей отсутствуют или некоторые из существующих конфликтуют, но не могут двигаться вперед.
Может кто-нибудь сказать, что не так, я могу двигаться вперед с тестовым случаем, даже если он терпит неудачу, я исправлю его, но сначала мне нужно удалить ошибку.
На боковой ноте я также попробовал groovyMock, но он дал исключение nullpointer для статического метода, затем я искал и обнаружил, что статический метод не работает с groovyMock.
Я пробовал лучшие результаты ссылок Google с помощью популярных блогов и учебников, но ни один из них не работает.
Почему вы пытаетесь издеваться над 'DataController'? Разве это не класс, который вы хотите проверить? – tddmonkey
Нашел решение с groovymock, и да, вы были правы, я издевался над неправильным классом. Мне нужно было высмеять класс обслуживания, контроллер использовал методы класса обслуживания. –