2011-07-03 11 views
10

El libro Crecimiento de software orientado a objetos ofrece varios ejemplos en jMock donde el estado se hace explícito sin exponerlo a través de una API. De veras me gusta esta idea. ¿Hay alguna manera de hacer esto en Mockito?¿Tiene mockito una expresión equivalente a los estados de jMock?

Aquí hay un ejemplo del libro

public class SniperLauncherTest { 
    private final States auctionState = context.states("auction state") 
               .startsAs("not joined"); 

    @Test public void addsNewSniperToCollectorAndThenJoinsAuction() { 
    final String itemId = "item 123"; 
    context.checking(new Expectations() {{ 
     allowing(auctionHouse).auctionFor(itemId); will(returnValue(auction)); 

     oneOf(sniperCollector).addSniper(with(sniperForItem(item))); 
            when(auctionState.is("not joined"));  
     oneOf(auction).addAuctionEventListener(with(sniperForItem(itemId))); 
            when(auctionState.is("not joined")); 
     one(auction).join(); then(auctionState.is("joined")); 
    }}); 

    launcher.joinAuction(itemId); 
    } 
} 

Respuesta

7

he usado un espía para el auto mismo ejercicio:

http://docs.mockito.googlecode.com/hg/latest/org/mockito/Mockito.html#13

he cambiado de simulacro SniperListener en espía de este modo:

private final SniperListener sniperListenerSpy = spy(new SniperListenerStub()); 
private final AuctionSniper sniper = new AuctionSniper(auction, sniperListenerSpy); 

y también creó una aplicación stubbed de SniperListener:

private class SniperListenerStub implements SniperListener { 
    @Override 
    public void sniperLost() { 
    } 

    @Override 
    public void sniperBidding() { 
     sniperState = SniperState.bidding; 
    } 

    @Override 
    public void sniperWinning() { 
    } 
} 

El libro usa los "Estados" de JMock , Pero he usado una enumeración anidado en su lugar:

private SniperState sniperState = SniperState.idle; 

private enum SniperState { 
    idle, winning, bidding 
} 

A continuación, tiene que usar JUnit regulares afirma a probar para el Estado:

@Test 
public void reportsLostIfAuctionClosesWhenBidding() { 
    sniper.currentPrice(123, 45, PriceSource.FromOtherBidder); 
    sniper.auctionClosed(); 
    verify(sniperListenerSpy, atLeastOnce()).sniperLost(); 
    assertEquals(SniperState.bidding, sniperState); 
} 
+1

De esta manera es más limpio que otra respuesta. +1 –

+1

Mucho mejor que el jMock utilizado en el libro (que es genial, pero tiene algunos defectos). Constantemente hacen hincapié en la necesidad de hacer que el código de prueba sea fácil de entender, pero desde ese punto de vista, a juzgar por la perspectiva de mi novato de todos modos, Mockito parece muy superior. –

+1

Sin embargo, 'SniperState' es una elección desafortunada de nombre ... porque el libro presenta su propia clase' SniperState' en p. 154 (y no es un simple 'enum') ... –

7

No es que yo sepa. He usado mockito una cantidad muy grande y no hay nada en el doco similar a lo que he leído en el sitio JMock sobre estados. Si lo tengo correctamente, básicamente limitan el tiempo en el que puede producirse una excepción a la duración de un estado específico de otro objeto. Es una idea interesante, pero estoy luchando por ver las aplicaciones para ella.

En Mockito puede ejecutar el código usando Stubbing with callbacks para hacer el mismo trabajo. En el método de devolución de llamada, puede ejecutar otras validaciones del estado. Alternativamente, puede emplear un Custom argument matcher ya que también se ejecutan en el momento de la llamada.

Ambos le dan acceso al código en el momento de la ejecución, que es el momento en que desea verificar el estado.

Cuestiones relacionadas