Qualsiasi modello che promuova un approccio funzionale (ad esempio lo si passa da qualche valore, esso restituisce un valore e non causa effetti collaterali) sarà semplice da testare. Qualsiasi modello che causa effetti collaterali o stato persiste sarà difficile da testare, a meno che non sia possibile rilevare tutti gli effetti collaterali e provarli. Ecco perché le interfacce utente sono difficili da testare; hai bisogno che un essere umano guardi lo schermo per vedere gli effetti collaterali.
Singleton non è facile da testare perché persiste nello stato, cioè tutte le funzioni che esegui su di esso non sono idempotenti (i tuoi risultati potrebbero cambiare ogni volta). I database sono allo stesso modo; per testarli unitamente, è necessario avvolgere i test nelle transazioni in modo da poterli eseguire nuovamente dopo il test.
Quindi vai giù nella lista dei modelli e valuta ciascuno su questa base. Ad esempio, il pattern Abstract Factory è testabile, perché puoi verificare quale tipo restituisce. RAII dovrebbe essere testabile perché puoi verificare la durata di un oggetto verificando se è nullo. La raccolta dei dati inutili non è necessariamente verificabile allo stesso modo, poiché non si sa sempre quando il garbage collector deciderà di effettuare una raccolta.