I "test" devono essere tenuti fuori dalla principale pipeline di fusione?

Question

I "test" devono essere tenuti fuori dalla principale pipeline di fusione?

#1 da (6 voti)
#2 da (0 voti)

2

A tutti sappiamo a volte ad es. l'unione può andare storta.

Se i nostri test [unità / integrazione] si trovano nello stesso repository dell'unione, c'è un punto debole che se i test si sono fusi in modo errato e non appaiono nel codice finale, allora "non sappiamo cosa non so ".

Il progetto di test dell'unità dovrebbe essere invece un articolo separato completo?

In molti modi direi di no perché potrebbe sporcare un ramo principale con test di funzionalità che non sono ancora rilevanti.

In linguaggi compilati, la compilazione fallirà se il codice reliant del test manca, quindi aiuterà in una certa misura. Ma forse un linguaggio non compilato è migliore in quanto sarebbe molto specifico quando si esegue il test.

Qualcuno ha un flusso di lavoro che è possibile sapere quali funzionalità potrebbero essere unite in modo errato?

unit-testing scm

posta Alex KeySmith 19.06.2014 - 11:47

fonte

2 risposte

Leggi altre domande sui tag unit-testing scm

Processo di reimpostazione della password Le classi non dovrebbero chiamare altre classi? [chiuso]

score 6 · Answer 1

I test unitari sono codice come tutto il resto. Quindi, se unisci il tuo codice e i tuoi test di unità dipendono dalla versione o revisione del codice non di test (che di solito è il caso), devi sempre unire i tuoi test insieme a tutto il resto. Ciò include la risoluzione di eventuali conflitti di unione, se si verificano.

Se i conflitti di fusione della tua suite di test non vengono risolti, perdi la possibilità di compilarlo ed eseguirlo (o in una lingua non compilata: la suite di test potrebbe portare risultati errati o crash in fase di esecuzione) - è proprio questo vale la seccatura? Ritardare la risoluzione di un conflitto di unione non è mai utile, più a lungo si attende, più diventa difficile. Il codice di prova non è quindi diverso da qualsiasi altro tipo di codice. E se la risoluzione dei conflitti di unione dei test richiede un tale sforzo da considerare l'omissione della risoluzione come opzione seria, c'è qualcosa di molto, molto sbagliato nel tuo flusso di lavoro.

score 0 · Answer 2

Test e codice dovrebbero fondersi contemporaneamente.

Considera il caso opposto. Cosa succede se un conflitto di unione perde le nuove righe di codice? Se hai ancora il vecchio test, quindi non lo sapresti mai.

La modifica della regressione diventa il tuo record che ti aspetti che il comportamento cambi, e dovresti seguire il codice mentre si unisce.