Beh, tecnicamente parlando, un assert viene normalmente compilato da build di release in modo da non vederli operare in codice in esecuzione in produzione. Detto questo, puoi ancora inserirli nel codice dell'applicazione come una sorta di test di unità in linea in modo che funzionino ancora mentre il codice è in esecuzione in fase di sviluppo / test.
Normalmente i test di unità eseguono bit di codice dell'applicazione e quindi controllano che alcune cose siano vere usando le asserzioni. Detto questo, a volte c'è un motivo per usare un'asserzione all'interno del codice dell'applicazione perché, cosa più importante, un test unitario può fallire da un assert nel codice di test unitario o un assert nel codice dell'applicazione da testare .
Considera che scrivi un test unitario che esegue una sequenza forzata di operazioni sulla tua applicazione che, a tuo avviso, potrebbe teoricamente causare l'accadimento di cose brutte. Potresti non avere un modo semplice, dal test dell'unità dell'oscilloscopio, per sondare le classi dell'applicazione per verificare se qualcosa sta andando storto e potrebbe esserci un'alternativa più semplice nell'aggiungere direttamente l'asserzione nel codice dell'applicazione.
A volte scrivo test unitari senza un'asserzione nel test unitario stesso, semplicemente per tentare (e, si spera, fallire) di richiamarne uno che inserisco nell'applicazione.
E una nota finale: le asserzioni non sono le stesse delle eccezioni. Le eccezioni sono utilizzate per comportamenti (rari) ancora attesi e questo può ancora essere testato poiché è possibile scrivere test unitari per prevedere eccezioni. Le asserzioni vengono utilizzate per un comportamento imprevisto impossibile e quindi associate al concetto centrale di test delle unità.