Lo schema progettuale Humble Objects viene utilizzato per rendere più semplice il testing di determinati comportamenti. Esso consiste nel separare i comportamenti che sono difficili da verificare da quelli più facili da verificare. Esso funziona così: si suddividono i comportamenti in due classi. Una classe è "umile", ovvero contiene quei comportamenti difficilmente verificabili ridotti all'essenziale. L'altra classe, invece, contiene la logica verificabile eliminata dalla classe umile. Per esempio, testare la GUI è parecchio difficoltoso, poiché dovremmo scrivere dei test che si occupano di analizzare gli elementi visualizzati a schermo. Tuttavia possiamo separare il comportamento che si occupa di far visualizzare gli elementi a schermo, il quale rappresenta la parte difficile da testare, dal comportamento che si occupa di formattare gli elementi da far visualizzare, il quale rappresenta la parte verificabile. Questo si traduce in due classi: il Presenter e la View.
La View rappresenta il nostro oggetto umile che è difficile da testare. Il codice di questo oggetto viene mantenuto il più semplice possibile. Esso si occuperà solo di far visualizzare i dati a schermo. Il Presenter è l'oggetto testabile. Il suo compito è quello di accettare i dati dall'applicazione, formattarli per la presentazione e inserirli all'interno di un ViewModel che poi verrà utilizzato dalla View per recuperare le informazioni già formattate e stamparle a video. In questa maniera, la parte che andremo a testare sarà semplicemente la logica che si occupa di formattare i dati, ovvero il Presenter. Per esempio, se l'applicazione vuole far visualizzare una data, passerà al Presenter un oggetto Date. Il Presenter si occuperà di formattare la data nel formato appropriato e la inserirà all'interno di un oggetto ViewModel che poi verrà utilizzato dalla View per stampare la data a video. Se l'applicazione vuole far visualizzare un importo in rosso, passerà al Presenter un oggetto Currency. Il Presenter lo formatterà mettendo le cifre decimali, il simbolo di valuta e settando una proprietà boolean nel ViewModel per indicare se l'importo è negativo o meno, così da consentire alla View di stampare correttamente l'importo a video.
Per consentire ai casi d'uso di interagire con il database vengono utilizzati i gateway per il database. Questi gateway sono delle semplici interfacce che consentono all'applicazione di interrogare i dati contenuti nel database. Per esempio, se l'applicazione desidera recuperare gli utenti connessi ieri utilizzerà l'interfaccia UserGateway, la quale espone il metodo getLastNamesOfUsersWhoLoggedInAfter. Questa interfaccia verrà poi implementata da una classe contenuta nel livello del database, la quale userà del codice SQL per recuperare l'informazione richiesta dal caso d'uso. Tale classe rappresenta l'oggetto umile. L'Interactor, ovvero l'oggetto del caso d'uso, non è umile, pertanto può essere sottoposto a test.
Un altro utilizzo dello schema Humble Objects si ha durante la comunicazione con i servizi esterni. La classe che si occuperà di comunicare con il servizio esterno rappresenta il nostro oggetto umile. Essa riceve dal servizio una Response __(in formato json ad esempio) e la passerà ad un'altra classe (un Builder) che si occuperà di parsare il json e restituire una struttura dati. Quindi i nostri test non si occuperanno di testare la comunicazione con il servizio esterno, ma bensì la classe Builder che si occupa del parsing e della creazione della struttura dati.