Questo test dell'unità pratica di test, test di regressione e / o test funzionale?

Questo è fondamentalmente test di integrazione. Non è sicuramente un test unitario poiché stai usando un pezzo aggiuntivo per testarlo (il pitone).

Ogni volta che provi il prodotto finale della tua applicazione - in questo caso un eseguibile in C ++ - ti stai spostando in test di integrazione / funzionali.

loads and executes the executable compiled from the C++ project program, and interacts with the project's executable by http request and response.

Questo non è affatto un test unitario. Il test delle unità sta testando contro le unità all'interno di un pezzo di software, non contro il loro risultato compilato.

Anche i test di regressione non hanno senso, a meno che non siano stati scritti tutti dei test in python a causa di bug e il punto sia quello di impedire a quelli di regredire. Anche se questo termine è strongmente sovraccarico e dipende da ciò che il tuo collega intende con esso, potrebbe essere applicabile (o meno). Se la tua definizione di "test di regressione" è "testing software per trovare bug", allora qualsiasi test può contare. Se è più specifico? Quindi è meno così.

Onestamente, nel complesso sembra che tu stia eseguendo solo test di integrazione API da python. Questa non è necessariamente la migliore idea, probabilmente vorresti fare un certo livello di test unitario all'interno della stessa base di codice C ++.

Non esagerare con la terminologia. Questi termini non sono definiti con precisione e non sono necessariamente esclusivi.

Test dell'unità è sicuramente il termine sbagliato, poiché si riferisce a testare parti più piccole del codice in isolamento. La "unità" non si riferisce necessariamente a una funzione o una procedura, tuttavia potrebbe anche essere una classe o anche più classi. (I test unitari non devono essere scritti nella stessa lingua, purché la lingua sia in grado di chiamare / accedere direttamente al codice nell'unità sottoposta a test, ma di solito lo sarà.)

Ma sia il test funzionale, test di sistema, test di integrazione, test end-to-end e regressione potrebbero essere termini appropriati per quello che stai facendo.

Test di integrazione si riferisce alla verifica dell'integrazione tra unità o sottosistemi, mentre test end-to-end si riferisce alla verifica dell'intero sistema. Ma questi termini sono più appropriati quando si verifica un sistema più grande che consiste in più sottosistemi. Sembra che questo non sia il caso del tuo programma, quindi probabilmente direi solo test di sistema .

Regression è un test specificamente scritto con lo scopo di verificare che le funzionalità esistenti continuino a funzionare correttamente dopo l'introduzione delle modifiche. Questo è diverso che dice scrivere test insieme allo sviluppo per verificare funzionalità nuove e modificate. Quindi test unitari o test di integrazione o test funzionali possono anche essere test di regressione. Fondamentalmente è solo una questione di quando scrivi il test - se scrivi il test dopo che sai già che la funzionalità funziona correttamente, allora è un test di regressione!

Il termine casella bianca e casella di blocco verifica fa riferimento a quanto conoscenza dei dettagli di implementazione hai quando scrivi il test. Se hai scritto tu stesso il programma, probabilmente hai qualche idea su quali sono le parti più complicate del codice e questo potrebbe darti delle idee su quali condizioni testare. Questo è un test white-box, anche se stai solo testando il sistema attraverso le interfacce pubbliche. Se hai scritto il codice da solo, non puoi scrivere test black-box.

Test funzionali si riferisce specificamente ai test per verificare che il programma sia conforme alle specifiche dei requisiti. Quanto del test è funzionale dipende da quanto è scritto in questo documento! I requisiti sono tipicamente scritti ad alto livello, descrivendo ciò che il cliente dovrebbe essere in grado di fare con il sistema piuttosto che come il sistema dovrebbe essere implementato, quindi i test funzionali saranno i test black-box.

La persona che ti ha detto che questo è un test unitario è completamente sbagliato.

I test unitari sono fatti, come tu lo chiami, a "livello di codice sorgente" (anche se direi che è una descrizione abbastanza vaga - dopo tutto, i test eseguono codice e solo il codice compilato può essere eseguito, a meno che non sia interpretato).

I test unitari si basano molto sul derisione, ovvero sulla falsificazione di componenti (dipendenze) di un componente (ad esempio una singola classe) che si desidera testare.

Ciò di cui stai parlando nella tua domanda è qualcosa che chiamo test end-to-end. Non è un test di integrazione, perché quelli sono ancora fatti senza l'uso di un programma esterno. Sia l'integrazione che i test unitari vengono solitamente eseguiti utilizzando uno specifico framework di test e runner di test per la piattaforma a portata di mano.

Altri termini che possono essere applicati per questo caso: test di sistema, test di accettazione (a seconda di quali metriche sono state validate).