Come posso testare una classe Singleton con DUnit?

Question

O è meglio usare un altro modello di disegno?

Answer 1

Risposto a una domanda simile qualche giorno fa qui, beffardo un Singleton . Il post originale è per C # .Net per quanto riguarda la derisione del comportamento di un singleton, ma dovrebbe comunque essere applicato.

Per quanto riguarda il modello singleton, non c'è nulla di sbagliato in sé - in molti casi vogliamo centralizzare la logica e i dati. Tuttavia, c'è una differenza molto grande tra un singleton e una classe statica. Costruire il tuo singleton come una classe statica codifica tale implementazione per ogni consumatore nella tua applicazione - il che rende molto difficile il testing delle unità!

Quello che vuoi fare è definire un'interfaccia per il tuo singleton, esponendo i metodi che i tuoi consumatori potranno usare. A loro volta, i consumatori sono passati un riferimento a una classe di implementazione da parte di chiunque li istanzia [in genere si tratta dell'applicazione o di un contenitore se si ha familiarità con Iniezione di dipendenza \ Inversione del controllo].

È questo quadro, chiunque istanzia i consumatori, è responsabile di garantire che una sola istanza stia fluttuando. Non è davvero un grande salto dalla classe statica al riferimento all'interfaccia [come dimostrato nel link sopra], perdi solo la comodità di un'istanza accessibile a livello globale - lo so lo so, i riferimenti globali sono terribilmente seducenti, ma Luke ha voltato le spalle al Lato oscuro, anche tu puoi!

In generale, le migliori pratiche suggeriscono di evitare riferimenti statici e incoraggiano la programmazione contro le interfacce. Ricorda, è ancora possibile applicare il modello singleton con questi vincoli. Segui queste linee guida e non dovresti avere problemi a testare il tuo lavoro :)

Spero che questo aiuti!

---

singleton! = classe statica pubblica , piuttosto singleton == singola istanza

Answer 2

La mancanza di testabilità è una delle principali cadute del modello Singleton classico (metodo di classe statica che restituisce un'istanza). Per quanto mi riguarda, questa è una giustificazione sufficiente per riprogettare qualsiasi codice che utilizza Singletons per usare qualche altro design.

Se hai assolutamente bisogno di avere un'istanza singolare, l'iniezione delle dipendenze e la scrittura su un'interfaccia, come suggerito da Johnny G, è sicuramente la strada da percorrere.

Answer 3

Sto usando il seguente schema quando scrivo un singleton basato su statico che posso prendere in giro. Il codice è Java, ma penso che avrai un'idea. Il problema principale con questo approccio è che devi rilassare il costruttore in pacchetti protetti (che in qualche modo sconfigge un vero singleton). Come nota a margine: il codice si applica alla capacità di deridere il tuo "statico" codice non necessariamente semplicemente chiamandolo

Answer 4

In genere utilizzo i Singleton solo per oggetti Flyweight o oggetti di valore simile. Esaminare un contenitore IoC (come discusso in precedenza) è probabilmente un modo migliore per gestire un oggetto condiviso rispetto a un singleton.

Considera che in Smalltalk (dove hanno avuto origine molti di questi schemi), sia vero che falso erano entrambi in effetti singolari :)

Answer 5

Se devi usare un singleton (e ci sono ragioni per farlo ... ma proverei sempre ad evitarlo se possibile). Consiglierei di usare un contenitore IOC per gestirlo. Non sono sicuro che ce ne sia uno per Delphi o meno. Ma in Java potresti usare Spring, in .NET puoi usare Windsor / Castle. Un contenitore IOC può trattenere Singleton e può registrare diverse implementazioni per i test.

Probabilmente è un argomento troppo grande per entrare qui oltre questo frammento.