L'asporto da questo è Fail Fast .
Non abbiamo il codice, né abbiamo molti esempi di prefissi che sono o non sono test di prefissi di ramo in base al codice. Tutto ciò che abbiamo è questo:
- 089 - 100 => ramo di prova
- 10B, 10C => ramo di prova
- <088 => rami presumibilmente reali
- > 100 => rami presumibilmente reali
Il fatto che il codice consenta numeri e stringhe è più che strano. Naturalmente, 10B e 10C possono essere considerati numeri esadecimali, ma se i prefissi sono tutti trattati come numeri esadecimali, 10B e 10C non rientrano nell'intervallo di test e verrebbero trattati come rami reali.
Questo probabilmente significa che il prefisso è memorizzato come una stringa ma trattato in alcuni casi come un numero. Ecco il codice più semplice che mi viene in mente che replica questo comportamento (usando C # a scopo illustrativo):
bool IsTest(string strPrefix) {
int iPrefix;
if(int.TryParse(strPrefix, out iPrefix))
return iPrefix >= 89 && iPrefix <= 100;
return true; //here is the problem
}
In inglese, se la stringa è un numero compreso tra 89 e 100, è un test. Se non è un numero, è un test. Altrimenti non è un test.
Se il codice segue questo modello, nessun test unit avrebbe rilevato ciò al momento della distribuzione del codice. Ecco alcuni esempi di test unitari:
assert.isFalse(IsTest("088"))
assert.isTrue(IsTest("089"))
assert.isTrue(IsTest("095"))
assert.isTrue(IsTest("100"))
assert.isFalse(IsTest("101"))
assert.isTrue(IsTest("10B")) // <--- business rule change
Il test unitario mostra che "10B" deve essere trattato come un ramo di test. L'utente @ gnasher729 sopra afferma che le regole aziendali sono cambiate ed è quello che mostra l'ultima affermazione sopra. Ad un certo punto quell'asserzione avrebbe dovuto passare a un isFalse, ma ciò non è accaduto. I test unitari vengono eseguiti in fase di sviluppo e di costruzione, ma successivamente in nessun momento.
Qual è la lezione qui? Il codice ha bisogno di un modo per segnalare che ha ricevuto input imprevisti. Ecco un modo alternativo per scrivere questo codice che sottolinea che si aspetta che il prefisso sia un numero:
// Alternative A
bool TryGetIsTest(string strPrefix, out bool isTest) {
int iPrefix;
if(int.TryParse(strPrefix, out iPrefix)) {
isTest = iPrefix >= 89 && iPrefix <= 100;
return true;
}
isTest = true; //this is just some value that won't be read
return false;
}
Per coloro che non conoscono C #, il valore restituito indica se il codice è stato in grado di analizzare un prefisso dalla stringa specificata. Se il valore restituito è true, il codice chiamante può utilizzare la variabile isTest out per verificare se il prefisso del ramo è un prefisso di test. Se il valore restituito è falso, il codice chiamante dovrebbe segnalare che il prefisso specificato non è previsto e che la variabile isTest out è insignificante e deve essere ignorata.
Se sei d'accordo con le eccezioni, puoi farlo invece:
// Alternative B
bool IsTest(string strPrefix) {
int iPrefix = int.Parse(strPrefix);
return iPrefix >= 89 && iPrefix <= 100;
}
Questa alternativa è più semplice. In questo caso, il codice chiamante deve intercettare l'eccezione. In entrambi i casi, il codice dovrebbe avere un modo per segnalare al chiamante che non si aspettava uno strPrefix che non potesse essere convertito in un numero intero. In questo modo il codice fallisce rapidamente e la banca può trovare rapidamente il problema senza l'imbarazzo della SEC.