Test del mio codice VB.NET?

3

Ho difficoltà a sviluppare approcci di testing unitario per testare sia se il "codice fa quello che voglio che faccia", sia testando "il mio codice funziona".

Ad esempio, sto scrivendo il codice per convalidare l'input che verrà inserito in una tabella del database, quindi ho bisogno di verificare se il mio codice fa quello che voglio che faccia - Viene accettato un input valido, l'input errato viene rifiutato. Ecco alcuni dei codici, in VB.NET:

    'Let's check if we are going to update all the fields that must be updated...
    If record.table.RequiredMustBeSuplied IsNot Nothing Then
        For Each req In record.table.RequiredMustBeSuplied
            If query.UpdateFields(req.Key).value Is Nothing Then
                Throw New ArgumentNullException
            End If
        Next
    End If

Quindi, per il mio test di unità passerei una query senza i campi di aggiornamento appropriati e mi aspetto che si tradurrebbe in un ArgumentNullException e un test corrispondente che passi. Il problema che mi succede più avanti noterò un bug e capisco che il mio codice non funziona correttamente. Ad esempio, il codice corretto in questo caso era:

    'Let's check if we are going to update all the fields that must be updated...
    If record.table.RequiredMustBeSuplied IsNot Nothing Then
        For Each req In record.table.RequiredMustBeSuplied
            If query.UpdateFields(req.Key).value Is Nothing Then
                Throw New ArgumentNullException
            End If
        Next
    End If

Quindi, sono stato in grado di verificare i problemi che conosco (campi mancanti) ma non un problema che non conosco (la differenza tra dbnull e niente). Il testing delle unità non è molto efficace nel trovare questi tipi di errori, oppure esiste un approccio che qualcuno potrebbe suggerire?

    
posta JEC 07.08.2012 - 23:56
fonte

2 risposte

5

I test unitari dovrebbero essere costruiti sulla base dei requisiti e dei vincoli che conosci. Saranno sempre completi come i tuoi processi mentali. La cosa meravigliosa, tuttavia, è che quando incontri un bug che non avevi previsto o testato, puoi creare un nuovo test unitario che copra quel caso anche prima di implementare la correzione, e quindi non dovrai mai più preoccuparti di quel bug . (usa TDD per la vittoria)

    
risposta data 08.08.2012 - 00:17
fonte
0

Le tue specifiche dovrebbero riguardare le condizioni note nelle risorse del sistema, come lo schema e le regole aziendali. Tuttavia, come fanno molti sviluppatori, il passaggio al codice non richiede tempo per studiare la progettazione del database o persino i requisiti specifici. Ciò rende la costruzione di casi di test completi inclini all'errore perché l'attività di sviluppo si confonde con l'attività di progettazione. Di solito domina la programmazione poiché consuma gran parte dello sforzo e del tempo. Il mio punto è che puoi evitare molti problemi se ti prendi il tempo per progettare e specificare il problema a portata di mano prima della codifica.

    
risposta data 08.08.2012 - 10:39
fonte

Leggi altre domande sui tag