Il test case per Restful API con database di connessione è Unit test o Integration Test

From my knowledge, unit test doesn't connect with external services likes database, files,

Hai ragione. Stai descrivendo un test di integrazione. Integra tutti o alcuni componenti nel sistema e li testa.

how to write an actual unit test for restful api ?

In realtà non collaudi l'API restful perché è troppo grande. Invece unità testare le unità che compongono l'api riposante. Con la maggior parte delle API restful, si scrivono semplici funzioni e quindi si configura il framework per richiamare le funzioni assegnate a un percorso specifico. Quindi unit test quelle funzioni.

Ad esempio nella mia API REST, l'autorizzazione è una preoccupazione che viene gestita nella funzione endpoint. Ho una funzione come questa (pseudocodice):

def insertBusiness(...)
  if !auth.authenticated
    return Unauthenticated
  if !auth.getPermissions.contain(ADMIN)
    return Unauthorized
  else
    bll.insertBusiness(...)
    return Created

Questa funzione è configurata nel mio framework REST per essere eseguita quando una richiesta POST viene fatta su /businesses per esempio.

È utile test delle unità di scrittura per coprire questa funzione. Gli oggetti bll e auth devono essere derisi - altrimenti questo sarebbe un test di integrazione. Ecco alcuni esempi di casi di test:

1. Quando auth.authenticated restituisce false, insertBusiness deve restituire Unauthenticated
2. Quando auth.getPermissions non contiene ADMIN , insertBusiness deve restituire Unauthorized
3. Quando auth.authenticated genera un'eccezione, insertBusiness deve generare un'eccezione
4. Quando auth.getPermissions genera un'eccezione, insertBusiness deve generare un'eccezione
5. Quando auth.authenticated restituisce null (se il tipo è annullabile o deselezionata), insertBusiness deve generare un'eccezione
6. auth.getPermissions restituisce null (se il tipo è annullabile o deselezionata), insertBusiness deve generare un'eccezione
7. Quando bll.insertBusiness genera un'eccezione, insertBusiness deve generare un'eccezione
8. Quando un utente autenticato con autorizzazioni ADMIN , insertBusiness deve restituire Created

Questi test non sono implementati effettuando richieste REST attraverso il framework (anche in questo caso si tratterebbe di un test di integrazione). Sono implementati effettuando chiamate direttamente su insertBusiness

Per quello che vale, è un test di integrazione. La differenza importante è che richiede un tempo di esecuzione più lungo, quindi non viene eseguito più volte al giorno durante lo sviluppo ma prima dell'accettazione in produzione.

La vera domanda con un test è se fornisce informazioni utili sullo stato del sistema che vale la pena eseguire il costo di esecuzione adesso. Quindi i test unitari migliori sono veloci e forniscono un feedback rapido, e i test di integrazione tendono a essere eseguiti meno spesso in quanto sono più lenti, ma se tutti i test di integrazione richiedessero meno di un secondo per essere eseguiti non si perderebbe nulla eseguendoli su ogni build.

Di solito eseguiamo un test di regressione / integrazione delle nostre API REST usando Python, principalmente perché è quello che la maggior parte dei nostri utenti usa per connettersi all'API per scrivere sul nostro sistema. Vengono creati utilizzando l'unit test framework ed eseguiti come parte del processo UAT, oppure quando abbiamo apportato una modifica riteniamo che potrebbe causare un problema.

I test dell'API REST vengono eseguiti dopo che i test delle unità per i componenti su cui opera l'API vengono eseguiti (simili a quelli descritti da @Samuel). Lo scopo di testare l'API è assicurarsi che non si interrompano gli script scritti dagli utenti dell'API. Poiché lo scopo dell'API è quello di integrare tra lo script degli utenti esterni e il resto del sistema, è possibile simulare il sistema, ma dal momento che vengono eseguiti meno spesso come test di regressione / integrazione, non viene eseguita tale ottimizzazione.