Normalmente le lingue non vengono testate, ma le implementazioni sono spesso testate in modo molto approfondito: come infrastruttura di base, devono funzionare. Tuttavia, l'unità di test di una lingua è difficile dal momento che non possiamo testare una funzionalità in isolamento. Non c'è modo di delimitare la "unità". Le diverse caratteristiche di una lingua hanno interazioni ricche e complicate e un programma valido richiesto per un caso di test tocca necessariamente molte cose che non sono l'obiettivo di quel test specifico.
Tali test sono test di integrazione: viene eseguito un intero programma e si prevede che produca un particolare output. Spesso, l'infrastruttura del linguaggio include un test runner personalizzato per gestirlo. Per esempio. il formato del risultato del test TAP è stato originato con i primi casi di test dell'interprete Perl.
La fonte principale di nuovi casi di test è spesso test di regressione: un utente ha riscontrato un problema e vogliamo accertarci che non debba mai essere riparato di nuovo. Alcune lingue sono effettivamente definite dalla loro implementazione di riferimento (ad es. Ruby, Perl, Python). Il linguaggio è ciò che fa l'implementazione di riferimento. Questo rende i test un po 'inutili. Tuttavia, è possibile utilizzare una suite di test completa per creare implementazioni alternative compatibili.
Molte lingue sono definite da una specifica. Una specifica non può essere verificata o verificata direttamente. Di solito, il linguaggio esiste già almeno in prototipi o implementazioni di riferimento prima che sia formalizzato. Un contro-esempio interessante è Perl6, in cui la specifica (informale) è stata tradotta in una suite di casi di test prima dell'esistenza di qualsiasi implementazione. Ciò ha permesso di monitorare in modo molto visibile i progressi delle potenziali implementazioni. Si vedeva subito quali caratteristiche linguistiche dovevano ancora essere implementate. Java ha anche una suite di test canonica, ma è più legata al marchio Java che alle specifiche del linguaggio Java.
Per i parser, il test fuzz può essere molto prezioso. Questo non mette alla prova la lingua, ma si assicura che l'implementazione si comporti bene e usi la programmazione difensiva. Qui, l'input per l'implementazione è mutato casualmente. Di solito, queste modifiche dovrebbero portare a una sintassi illegale, quindi ci aspettiamo un messaggio di errore e un'uscita pulita. Se viene attivato un errore nell'implementazione, quell'input del test viene salvato per la revisione umana in quanto probabilmente indica un possibile errore.