Linee guida / best practice su quali tratti / categorie dare ai test

Question

Linee guida / best practice su quali tratti / categorie dare ai test

#1 da (1 voti)
#2 da (1 voti)

0

Esiste uno standard su quali caratteristiche / categorie dare ai test?

Ecco un esempio:

using Xuint;

public class XUnitTest1
{
    [Fact]
    [Trait("Category", "CI")]
    public void TestMethodX1() { ... }

    [Fact]
    [Trait("Category", "CI")]
    public void TestMethodX2() { ... }

    [Fact]
    [Trait("Category", "CI")]
    [Trait("Runningtime", "Short")]
    [Trait("Priority", "2")]
    [Trait("Owner", "Terje")]
    public void TestMethodX3()
    {
        var sut = new SomeClasses.VerySimpleMath();
        int result = sut.Add(2, 3);
        Assert.Equal(result, 5)
    }
}

Immagino che questo sia usato principalmente per ridurre il tempo di esecuzione quando alcuni sono lunghi ma esiste uno standard? Dovresti preoccuparti di iniziare a dare tratti / categorie fin dall'inizio o solo quando i test impiegano più tempo a correre o quando è necessario? Di che tipo o di tratti / categorie di solito finisce la gente?

tests

posta mateoc 02.06.2015 - 05:26

fonte

2 risposte

1

Potresti voler usare i tratti per

Test in esecuzione selettivi. Ad esempio, utilizzo un tratto Integration in modo che il mio runner di prova della macchina di sviluppo non tenti costantemente di eseguire test DB. Potresti anche utilizzare un tratto di Nonessential per segnalare che, se un test fallisce, non impedisce alla generazione di passare
Metriche, così puoi (a colpo d'occhio) vedere quanti test coprono un particolare modulo, quanti di questi sono test di integrazione, ecc.

risposta data 02.07.2015 - 11:56

fonte

Leggi altre domande sui tag tests

Chiamata API per accedere da un link nell'email I diagrammi di contesto hanno cardinalità?

score 1 · Accepted Answer

Non chiedere "best practice". (in particolare non qui, dal momento che le persone si faranno prendere sul serio.)

Lo sviluppo del software è un gioco mentale. Le cose che facciamo, lo facciamo perché rendono più facile ragionare sul nostro codice per noi stessi. Se non fai a mente il comportamento di un professionista di successo senza capire i suoi problemi e perché questo comportamento è una soluzione per loro, non acquisirai la sua esperienza.

Questo è molto diverso dalle altre carriere. Per diventare un saltatore con l'asta di successo, devi possedere molta comprensione e motivazione, ma devi anche praticare i movimenti più e più volte, instancabilmente. In questo campo, è utile copiare il comportamento di un campione; richiede davvero molto tempo per interiorizzare i movimenti necessari per creare una volta di successo, e più spesso li ripeti, meglio è.

Creare software non è così. Non esiste una sequenza di movimenti che ti porti al successo; non vi è alcun esercizio quotidiano che possa affinare la tua abilità se lo ripeti senza stancarsi. (Sospetto che parte del successo del meme "design pattern", e il più recente meme "Code Kata", sia dovuto alla speranza sbagliata tra i principianti che esiste una cosa del genere.)

Perché, quindi do abbiamo schemi di progettazione, linee guida del codice o best practice? Sono regolarità che i professionisti che hanno risolto determinati problemi hanno notato e li hanno considerati utili hanno descritto e nominato nella speranza che anche altri possano trarne profitto. A volte funziona. Ma funziona bene solo se hai effettivamente lo stesso problema che aveva l'autore. Se si applica una soluzione che ha servito qualcun altro in una situazione diversa, non funzionerà affatto. Per capire quale soluzione utile copiare, devi capire il problema che l'autore ha, quale problema hai e se la loro natura è abbastanza simile da riapplicare la soluzione.

Ritorno dallo sfogo alla domanda: quale problema speri di risolvere con i tratti dei test? (Confesso che non ne ho mai usato nessuno, e non avevo mai nemmeno sentito parlare di quelli usati prima di chiederlo.)

Le tue suite di test sono troppo lente e vuoi selezionare i sottoinsiemi dei tuoi test per risparmiare tempo? Vi consiglio vivamente di non farlo; una suite di test dovrebbe essere eseguita completamente, dal momento che non si sa mai dove o quando gli effetti imprevisti di una modifica infrangeranno parte del codice esistente. Vuoi imporre un ordinamento su di loro? Non è una buona idea; i test devono essere abbastanza indipendenti da comportarsi esattamente allo stesso modo indipendentemente dall'ordine in cui vengono eseguiti.

Hai appena saputo della funzione e ora pensi "Hmm, mi chiedo quali utili cose posso fare con quello?" In tal caso dovresti memorizzare la conoscenza e aspettare con calma una situazione in cui i tratti possono fare qualcosa di utile per te. Se hai un problema, cioè i tuoi test non stanno facendo quello che ti serve, dicci qualcosa di più sul problema, in modo che lo capiamo e forse possiamo consigliarti.