2011-09-06 14 views
55

Estoy tratando de estrellarme entre la pared de ladrillo entre Mockito y yo. Me he arrancado de mis casillas tratando de obtener las declaraciones de importación importadas para las cosas de Mockito. Uno pensaría que alguien se acaba de lanzar una mesa diciendo que anyInt() proviene de org.mockito.Matchers y cuando () proviene de org.mockito.Mockito, etc., pero eso sería demasiado útil para los recién llegados, ¿no?Encontrar instrucciones estáticas de importación para las construcciones de Mockito

Este tipo de cosas, especialmente cuando se mezcla con más declaraciones de importación que terminan en una miríada de asteriscos, no siempre es muy útil:

import static org.junit.Assert.*; 
import static org.mockito.Mockito.*; 

Sí, me conocen y han estado tratando de utilizar el Eclipse Ventana -> Preferencias-> Java -> Editor-> Content Assist -> Favoritos mecanismo. Ayuda, pero no golpea la uña en la cabeza.

Cualquier respuesta a esta pregunta sería apreciada.

Muchas gracias, Russ

+0

sentimos a tirar de la comunidad en torno a: Mi post original También hice otra pregunta, pero descubrí que había algo mal en mi código, debido a que faltaba un paréntesis, así que eliminé ese bit. –

+0

¿Está buscando una trampa? ¿Es probable que podamos preparar uno? ¿Qué es deficiente acerca de la API? http://mockito.googlecode.com/svn/branches/1.6/javadoc/index.html?org/mockito/Matchers.html –

+2

Entonces, debes entender que evito religiosamente el asterisco en las declaraciones de importación porque al ver ese tipo de Lo que está en la parte superior del código solo significa que es imposible saber de dónde viene un símbolo y, por lo tanto, no hay forma de averiguar qué JAR incluir en mi proyecto. La búsqueda de Javadoc en el navegador no es demasiado buena para encontrar símbolos. Sí, una hoja de trucos sería muy buena, pero como un colega y yo estábamos discutiendo ahora, este es uno de esos problemas que crees que la comunidad Java ya habría resuelto. Gracias, avísame si haces una. –

Respuesta

15

El problema es que las importaciones estáticas de Hamcrest y Mockito tienen nombres similares, pero devuelven valores comparadores y reales, respectivamente.

Una solución es simplemente copiar las clases de Hamcrest y/o Mockito y eliminar/cambiar el nombre de las funciones estáticas para que sean más fáciles de recordar y menos aparezcan en el autocompletar. Eso fue lo que hice.

Además, cuando utilizo los simulacros, trato de evitar assertThat a favor de otros assertions y verify, p. Ej.

assertEquals(1, 1); 
verify(someMock).someMethod(eq(1)); 

en lugar de

assertThat(1, equalTo(1)); 
verify(someMock).someMethod(eq(1)); 

Si elimina las clases de sus Favoritos en Eclipse, y escribe el nombre largo, por ejemplo, org.hamcrest.Matchers.equalTo y hacer CTRL + MAYÚS + M para 'Agregar importación' y luego autocompletar le mostrará solo los emparejadores de Hamcrest, no cualquier combinación de Mockito. Y puedes hacer esto de otro modo siempre y cuando no combines mixer.

+1

Sí, has encontrado una de mis quejas como una nueva abeja: no estoy seguro de dónde es una interfaz (JUnit, simulacro de marco, Hamcrest, etc.) Paso más tiempo tratando de armar un proyecto de JAR que yo realmente debería tener que (de lo que lo hice en el día localizando las interfaces C de las bibliotecas y archivos de encabezado). –

+0

Puedes ser más elocuente sobre por qué evitas decir eso: no he pensado lo suficiente todavía, pero ahora estoy tratando de entrar en las pruebas de escritura con burlas y la verificación es algo nuevo para mí. Gracias. –

+0

Bien, tengo otra solución para ti. ¡Espero que ayude! –

85

Esto es lo que he estado haciendo para hacer frente a la situación.

Uso las importaciones globales en una nueva clase de prueba.

import static org.junit.Assert.*; 
import static org.mockito.Mockito.*; 
import static org.mockito.Matchers.*; 

Cuando haya terminado de escribir el ensayo y necesario que se comprometan, que acaba CTRL + SHIFT + O para organizar los paquetes. Por ejemplo, es posible que sólo se quedará con:

import static org.mockito.Mockito.doThrow; 
import static org.mockito.Mockito.mock; 
import static org.mockito.Mockito.verify; 
import static org.mockito.Mockito.when; 
import static org.mockito.Matchers.anyString; 

Esto le permite codificar distancia sin ser 'pegado' tratando de encontrar el paquete correcto para importar.

+6

¡lo votaría dos veces si pudiera! – Justin

+0

Para usuarios de Mac, en lugar de CTRL + MAYÚS + O hacer [comando + mayúsculas + O] (https://blog.codecentric.de/en/2012/08/my-top-10-shortcuts-for-eclipse-on -mac-os-x-y-windows-and-how-you-survive-the-change-from-windows-to-mac/# comment-165299) –

+0

¿Cuál es la desventaja de usar permanentemente cosas como 'import static org .junit.Assert. *; 'en sus clases de prueba (no reemplazándolas por' ctrl' + 'shift' +' O' al final)? – mkasberg

0

para IS()

import static org.hamcrest.CoreMatchers.*; 

Para assertThat()

import static org.junit.Assert.*; 

Para cuando() y verificar()

import static org.mockito.Mockito.*; 
Cuestiones relacionadas