Service Fabric Injection Testing and Dependency Injection

Question

Non riesco a testare un servizio/attore affidabile semplicemente chiamando il suo costruttore e testando i suoi metodi. var testService = new SomeService(); genera una eccezione NullReferenceException. Quindi, cosa posso fare con il servizio distribuito.

Capisco che gli SF Reliable Services/Actors implementati non siano classi .NET standard, e il test di unità di S/A schierato potrebbe essere una strana idea.

Ad ogni modo sto provando a fare un tentativo.

Ad esempio. Ho appena distribuito un servizio, che nel test ho creato un oggetto Proxy e aggiunto elementi nella coda di input del servizio. Quindi devo affermare che il conteggio della coda di input = 1. E funziona se ho appena distribuito un servizio e nessun altro client/servizio/attore ha utilizzato la coda di input. Ma la prossima volta che questo test fallirà questo è il problema. Ho bisogno di fare in modo che il Servizio smetta di funzionare con altri utenti, di rilasciarlo e di testarlo. A tale scopo posso creare alcune proprietà TestMode e alcuni metodi come PropareoForTests/TestingCompleted e chiamarli dal client di test prima e dopo il test.

È una cattiva idea farlo in quel modo. Forse ci sono delle linee guida per i test unitari di SF? Grazie.

UPDATE:

Mentre indaga Service Fabric Web Reference Application example ho trovato questa stringa TODO:

/// TODO: Temporary property-injection for an IServiceProxyWrapper until constructor injection is available. 

Vuol dire che SF servizi migliorerà sia il supporto DI? E gli attori?

Answer 1

In realtà è possibile testare Servizi e Attori affidabili nello stesso modo in cui testare qualsiasi altra classe in .NET! Sono speciali solo perché usano determinati hook nella piattaforma sottostante, ma a parte questo puoi istanziare normalmente la tua classe di servizio o attore e chiamare i metodi su di essa.

Attualmente, i servizi affidabili sono un po 'più facili da testare l'unità perché il gancio principale nella piattaforma, lo State Manager, è un'interfaccia che si può collegare tramite il costruttore.

Ad esempio, la classe di servizio potrebbe essere simile a questo:

EDIT: aggiornato con l'API versione GA (2.0.135)

class MyService : StatefulService 
{ 
    public MyService (StatefulServiceContext context, IReliableStateManager stateManager) 
     :base (context, stateManager) 
    { 
    } 

    public void MyMethod() 
    { 
    // do stuff.. 
    } 
} 

Quindi è possibile verificare la classe di servizio in questo modo:

[TestMethod] 
public TestMyMethod() 
{ 
    MockReliableStateManager stateManager = new MockReliableStateManager(); 
    MyService target = new MyService(stateManager); 

    target.MyMethod(); 
    // validate results and all that good stuff 
} 

Abbiamo un esempio di lavoro completa di servizi effettivi con un sacco di dipendenze che sono unità di testate disponibili su GitHub: https://github.com/Azure-Samples/service-fabric-dotnet-management-party-cluster

Questo esempio ha anche IReliableStateManager e IReliableDictionary e può essere utilizzato come punto di partenza per i propri test di unità.

Answer 2

Per beffardo il manager stato nel Attori affidabili, si può fare qualcosa di simile:

private readonly IActorStateManager _stateManager; 

public MyActor(IActorStateManager stateManager = null) 
{ 
    _stateManager = stateManager ?? this.StateManager; 
} 

In realtà, il StateManager non è ancora inizializzato in questo momento. Siamo in grado di farlo quando OnActivateAsync si chiama:

private IActorStateManager _stateManager; 

// Unit tests can inject mock here. 
public MyActor(IActorStateManager stateManager = null) 
{ 
    _stateManager = stateManager; 
} 

protected override async Task OnActivateAsync() 
{ 
    if (_stateManager == null) 
    { 
     _stateManager = StateManager; 
    } 
} 

Basta fare in modo di utilizzare sempre _stateManager nel resto del codice, invece di this.StateManager.