Come marcare / tracciare le caratteristiche nel codice?

Non sono sicuro che tu stia chiedendo funzionalità di alto livello, diciamo qualcosa su cui lavori per un paio di giorni o di livello basso.

Per il primo, se si dispone di un bug / funzionalità / sistema di tracciamento delle attività, ad es. JIRA, puoi abbinare automaticamente le modifiche al codice / codice con la funzione includendo l'ID dell'attività al messaggio di commit, ad es. [FOO-312] Add basic user data

Tuttavia, penso che tu suggerisca di collegare dichiarazioni specifiche, i loro requisiti e i loro test; per favore correggimi se sbaglio.

es. se dovessi controllare (a) il nome non è nullo, (b) l'età è maggiore di 18 e (c) il paese è in EU, sotto il tuo sistema suggerito dovresti scrivere qualcosa come:

// fx aaa
if isNull(name) { throw ...}
// fx aab
if age < 18 { throw ...}
// fx aac
if inEU(country) { throw ...}

// fx aaa
testRejectNullName ... 
// fx aab
testRejectChildern ...
// fx aac
testRejectNonEU ...

aaa: we need a name for the package
aab: customers have to be of age
aac: we only ship to EU

Ora per questo specifico esempio suggerisco di raggruppare tutto sotto un unico metodo di validazione e tenerne traccia - alla fine, a meno che non creiamo astrazioni, non importa quanto perdiamo, finiremo con un oceano intrattabile di poco Caratteristiche.

Ma supponiamo che ciò non sia possibile e che ci siano specifiche molto precise. È vero che avere dei buoni nomi può fare molto per rendere più facile trovare tutto e usando i commenti puoi spiegare perché abbiamo questa restrizione. Tuttavia, a volte non è una soluzione ideale, soprattutto se la persona che sta cercando tali informazioni non è tecnica, ad es. un product manager.

In questo caso, suggerirei di utilizzare alcune specifiche, come ad esempio Cetriolo (solo fornendogli un esempio, nemmeno sicuro se puoi usarlo in C #), per avere una configurazione leggibile (anche da persone non tecniche) che possa essere abbinata al tuo codice e ai test di unità reali. Ovviamente, richiede più lavoro, quindi spetta a te decidere quale livello di dettaglio devi coprire con esso.

Un'altra cosa da tenere a mente è che i test di corrispondenza con specifiche istruzioni / righe di codice suona un po 'dubbioso. Se è veramente una condizione indipendente, suggerirei di estrarla con un metodo diverso (e il nome di quel metodo potrebbe aiutare a capire il codice) altrimenti rischi di rendere i test troppo specifici e inflessibili.

// fx abc
  if (string.IsNullOrEmpty(value)) { throw new ArgumentNullException...}

Per favore, non farlo. Questa è una tecnica che è stata inventata nel millennio precedente e che è meglio lasciare in quel millennio precedente. Segui questo rigorosamente e il codice diventa rapidamente illeggibile. Ciò sconfigge uno degli scopi principali del codice, che è quello di renderlo comprensibile a un lettore umano. (Se questo non era uno scopo primario dovremmo semplicemente controllare il codice dell'oggetto.)

Ogni moderno sistema di gestione delle revisioni sarà in grado di dire a chi dare la colpa o la lode per ogni singola riga di codice nella base di codice. Subversion, git, Mercurial, bazaar, ClearCase e molti altri sistemi di gestione delle revisioni forniscono comandi che fanno esattamente questo.

Qualsiasi moderno sistema di gestione delle modifiche sarà in grado di tracciare le richieste di modifica (una segnalazione di errore è una richiesta di modifica) alle interpretazioni di tali richieste di modifica. Le richieste di modifica alle modifiche alla base di test sono una relazione molti-a-molti, così come la mappatura da casi di test a codice.

Questa relazione multi-dimensionale, molti-a-molti non è qualcosa che dovrebbe essere affidata agli umani per mantenere. Mentre noi umani siamo molto bravi in alcune cose, non siamo così bravi con gli altri. Questa è una di quelle cose che rientrano nella categoria degli "altri". Noi umani non siamo bravi in questo. Il software dannoso ha spento le luci su decine di milioni di persone, ha fatto esplodere razzi e ha inviato dosi letali di radiazioni nelle persone.

Invece, fidati di questo sugli strumenti moderni del 21 ° secolo che possono farlo automaticamente. I risultati sono piuttosto sorprendenti nelle organizzazioni che combinano correttamente un moderno sistema di gestione delle revisioni, un moderno sistema di gestione delle modifiche e un moderno sistema di gestione dei requisiti (se necessario).

Avevi ragione, i tre codici lettera e le tabelle excel non erano un buon metodo per tenere traccia dei requisiti.

Ho sperimentato con altri sistemi e ne ho ricavato. Divido i test in UsesCases e ErrorHandling. Questo mi consente di concentrarmi meglio su ciò che sto testando e posso evitare convenzioni di denominazione strane in modo che ogni test abbia un nome abbastanza chiaro e significativo. Ecco un esempio:

Diciamo che voglio testare questa classe:

class FileParser
{
    public static List<string> Parse(string fileName) { ... }
}

quindi vorrei creare questi test:

namespace FileParserTests
{
    [TestClass]
    public class Parse_UseCases
    {
        [TestMethod]
        public void ParsePlainTextFile() { ... }

        [TestMethod]
        public void ParseXmlFile() { ... }
    }

    [TestClass]
    public class Parse_ErrorHandling
    {
        [TestMethod]
        public void NullOrEmptyFileName() { ... }

        [TestMethod]
        public void FileDoesNotExist() { ... }

        [TestMethod]
        public void UnsupportedFileType() { ... }
    }
}

Non sei sicuro se questo è esattamente ciò che stai ottenendo, ma in Visual Studio puoi farlo con // todo commenti. Cioè

//todo test this function
private void test()
{
}

Questo verrà visualizzato nel pannello "Elenco attività" (Visualizza - Elenco attività) sotto il menu a discesa "Commenti". Traccia solo i commenti che iniziano con '// todo', che è molto utile.