Concorso di test unitario

Does anyone have any suggestions on how we could better determine the winner of this competition?

L'unica cosa che ha senso per me è il voto - ogni sviluppatore può assegnare alcuni punti ad ogni altro test di sviluppo (eccetto il proprio). Forse 3 punti per il test che pensa sia quello "più efficace", 2 punti per il secondo e uno per il terzo. Il test con il maggior numero di punti vince. Può dare risultati migliori quando l'assegnazione del punto viene eseguita senza sapere in anticipo chi ha scritto il test particolare.

Come bonus, riceverai tutti i tuoi test revisionati.

So if you wrote a unit test like this...

for (int i = 0; i < 100; i++) {
 assertTrue(i*i, square(i));
}

you would be given 100 points.

Darei a questa persona 0 punti (anche se il test stava testando qualcosa di realmente rilevante), perché le asserzioni all'interno di un loop hanno poco senso e test con più assert (specialmente in una forma di un loop o di una mappa) sono difficili da lavora con.

Il problema è essenzialmente quello di avere una metrica che non può essere [facilmente] ingannata. Una metrica basata esclusivamente sul numero di asserzioni è esattamente uguale a quella degli sviluppatori paganti per LOC scritta. Come nel caso di pay-by-LOC che porta a un codice enorme e impossibile da mantenere, la tua politica aziendale effettiva porta a test inutili e probabilmente scritti male.

Se il numero di asserzioni è irrilevante, anche il numero di test è irrilevante. Questo è anche il caso di molte metriche (comprese quelle combinate) che si potrebbero immaginare per questo tipo di situazioni.

Idealmente, applicheresti un approccio sistemico. In pratica, questo può difficilmente funzionare nella maggior parte delle società di sviluppo software. Quindi posso suggerire alcune altre cose:

1. Utilizzare le coppie di recensioni per i test e avere qualcosa di simile al numero di WTF al minuto metrica.

2. Misura l'impatto di questi test nel tempo sul numero di bug . Questo ha diversi vantaggi:

   • Sembra giusto,
   • Può essere effettivamente misurato se raccogli abbastanza dati sulle segnalazioni di bug e il loro destino,
   • Ne vale davvero la pena!

3. Utilizza la copertura della filiale , ma combinala con altre metriche (oltre a una recensione). La copertura della filiale ha i suoi vantaggi, ma testare il codice CRUD solo per ottenere un voto migliore non è il modo migliore per passare il tempo degli sviluppatori.

4. Decidi insieme quali sono le metriche che vuoi applicare per il momento (tali decisioni potrebbero non essere gradite o addirittura essere possibili in alcune aziende e team). Riesamina e modifica spesso le metriche, selezionando quelle che diventano più pertinenti e assicurati che tutti comprendano chiaramente cosa viene misurato e come.

Suppongo che il tuo datore di lavoro organizzi questo giorno di test unitario per darti incentivi per trovare bug, per ottenere una maggiore copertura del codice e anche per avere più test, utili per sempre.

Quindi, penserei che avrebbe senso che il vincitore dovesse essere lo sviluppatore che trova la maggior parte dei bug, o lo sviluppatore i cui test raggiungono il maggiore aumento della copertura del codice.

Un test ti farebbe guadagnare un punto se causasse l'apertura di una nuova voce nel tuo sistema di segnalazione di bug / bug / difetti. Se una voce è già aperta per quel problema, non conta. Inoltre, come suggerito nei commenti, i bug nel tuo codice non contano; solo i bug nel codice di altre persone dovrebbero contare. Sfortunatamente, questo approccio non offre una gratificazione immediata perché potrebbero essere necessari alcuni giorni prima che tutti i test falliti vengano setacciati e vengano aperti i problemi corrispondenti. Inoltre, questo potrebbe non funzionare sempre; con la maturazione del sistema, potrebbe diventare estremamente raro scoprire bug aggiungendo test.

L'aumento della copertura del codice potrebbe fornire una misurazione più obiettiva del miglioramento rappresentato dai nuovi test. Innanzitutto, la copertura totale del codice dovrà essere registrata il giorno prima della competizione. Quindi, ogni sviluppatore dovrà mostrare in qualche modo l'aumento della copertura del codice risultante dai soli test, senza tenere conto dell'aumento della copertura del codice risultante da test scritti da altri sviluppatori. Ciò significa che probabilmente avrai bisogno di un arbitro che andrà alla macchina di ogni sviluppatore e registrerà la nuova copertura del codice prima che i test di chiunque siano stati effettuati.

Per inciso, prendere in considerazione la copertura del codice offre una giusta ricompensa alle persone che scrivono test reali, invece di fare cose stupide come nell'esempio che hai fornito nella domanda.