Powermock, Mockito nullpointerexception al llamar a super() JDialog

Question

Obtengo una NullPointerException cuando intento probar algunos métodos en un objeto JDialog. Tengo para inicializar una versión simulada del padre del diálogo, así como otra clase que se utilizará (además de llamar a un método estático El código es el siguiente:.

@RunWith(PowerMockRunner.class) 
@PrepareForTest(ControlFileUtilities.class) 
public class StructCompDlgTest 
{ 
    @Before 
    public void setUp() throws Exception 
    { 
    controlFrame = org.mockito.Mockito.mock(ControlFrame.class); 
    structCmpDlg = new StructureCompareDialog(controlFrame); 
    serverPipeline = org.mockito.Mockito.mock(ServerPipeline.class); 
    } 
... 
} 

El código que se pidió la construcción del diálogo está aquí:

StructureCompareDialog(IControlFrame controlFrame) 
{ 
super((Frame) controlFrame, "title", true); 
... 
} 

cuando el super constructor se llama puede que lo consiga un NullPointerError en java.awt.Window.addOwnerWindow (Window.java:2525)"

void addOwnedWindow(WeakReference weakWindow) { 
    if (weakWindow != null) { 
    synchronized(ownedWindowList) { ***<<------ offending line*** 
     // this if statement should really be an assert, but we don't 
     // have asserts... 
     if (!ownedWindowList.contains(weakWindow)) { 
     ownedWindowList.addElement(weakWindow); 
     } 
    } 
    } 
} 

Sé que estoy mezclando statics y swing GUI en un remolino tóxico, pero no tengo otra opción. Me dieron la instrucción de juntar algunas pruebas unitarias con el código existente. No tengo idea de qué está pasando mal.

Gracias

Answer 1

Parece complicado! Esencialmente usted va a tener que encontrar todos los métodos que están siendo llamados en controlFrame como parte del constructor, y luego espolvorear algunas llamadas a

when(controlFrame.methodCalled()).thenReturn(somethingSensible); 

Si este es el aspecto de una tarea difícil, ¿qué hay de tratar para crear una implementación predeterminada de IControlFrame que cree como parte de su prueba setUp() y usar esa instea de un simulacro.

Tuve un problema similar hace un tiempo en el que estaba intentando probar la unidad de un oyente JMS de primavera. Correcta o incorrectamente, obtuve una solución de trabajo creando mi propia implementación predeterminada de DefaultMessageListenerContainer que me daba problemas similares a los que está describiendo. Mi solución implicó extender la aplicación real con mi propia versión específica de prueba que se veía así

/** 
* Empty mocked class to allow unit testing with spring references to a 
* DefaultMessageListenerContainer. The functionality on this class should never be 
* called so just override and do nothing. 
*/ 
public class MockDefaultMessageListenerContainer extends DefaultMessageListenerContainer { 

    public MockDefaultMessageListenerContainer() { 
    } 

    public void afterPropertiesSet() { 
    } 

    @Override 
    protected Connection createConnection() throws JMSException { 
     return null; 
    } 
} 

En mi ejemplo, yo era capaz de conseguir mis pruebas de funcionamiento mediante el paso posterior un valor null para el método CreateConnection problemmatic(). Tal vez el mismo enfoque puede ayudarte.

Answer 2

El ownedWIndowList es transient en la clase java.awt.Window. ¿Se está serializando su instancia del JDialog? Si es así, puede que tenga que utilizar el método readObject(java.io.ObjectStream) desde la interfaz Serializable para volver a inicializar el ownedWIndowList

Answer 3

no sé lo que su IControlFrame parece, pero pasando una burlado Frame a super() no funciona. Tenía que crear instancias de mi propia versión:

private class EmptyControlFrame extends JFrame implements IControlFrame { 

    @Override 
    public JFrame getFrame() { 
     return null; 
    } 

    // return null for any other overrides from IControlFrame 
} 

Luego, en su configuración():

controlFrame = new EmptyControlFrame();