Il takeaway da questo è per Fail Fast .
Non abbiamo il codice, né abbiamo molti esempi di prefissi che sono o non sono prefissi di test branch in base al codice. Tutto ciò che abbiamo è questo:
- 089 - 100 = > ramo di prova
- 10B, 10C = > ramo di prova
- < 088 = > presumibilmente rami reali
- > 100 = > presumibilmente rami reali
Il fatto che il codice consenta numeri e stringhe è più che un po '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 saranno trattati come rami reali.
Questo probabilmente significa che il prefisso è memorizzato come una stringa ma in alcuni casi viene trattato come un numero. Ecco il codice più semplice che riesca a pensare che riproduca 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 ed è compresa tra 89 e 100, è un test. Se non è un numero, è un test. Altrimenti non è un test.
Se il codice segue questo modello, nessun test unitario sarebbe stato rilevato al momento della distribuzione del codice. Ecco alcuni test unitari di esempio:
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 prova. User @ gnasher729 sopra dice che le regole aziendali sono cambiate ed è quello che mostra l'ultima affermazione sopra. A un certo punto, l'affermazione dovrebbe essere passata a isFalse , ma ciò non è accaduto. I test unitari vengono eseguiti allo sviluppo e al momento della compilazione, ma in un secondo momento.
Qual è la lezione qui? Il codice ha bisogno di un modo per segnalare che ha ricevuto input inaspettati. 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 di ritorno indica se il codice è stato in grado di analizzare un prefisso dalla stringa data o meno. Se il valore restituito è true, il codice chiamante può utilizzare la variabile isTest out per verificare se il prefisso di ramo è un prefisso di test. Se il valore restituito è falso, il codice chiamante deve riportare che il prefisso specificato non è previsto e la variabile isTest out non ha significato e deve essere ignorata.
Se stai bene 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 rilevare l'eccezione. In entrambi i casi, il codice dovrebbe avere un modo di segnalare al chiamante che non si aspettava uno strPrefix che non poteva essere convertito in un numero intero. In questo modo il codice fallisce rapidamente e la banca può trovare rapidamente il problema senza il grave imbarazzo della SEC.