La composizione delle funzioni e le tubazioni devono essere testate?

4

Il test delle unità richiede prima la scrittura dei test e poi il codice, mentre in F # (e la maggior parte dei linguaggi funzionali) alcuni codici sono estremamente brevi come segue:

let f = getNames
>> Observable.flatmap ObservableJson.jsonArrayToObservableObjects<string>

o:

let jsonArrayToObservableObjects<'t> =
    JsonConvert.DeserializeObject<'t[]> 
    >> Observable.ToObservable

E il test più semplice basato sulle proprietà che ho concluso per quest'ultima funzione è:

 testList "ObservableJson" [
        testProperty "Should convert an Observable of 'json' array to Observable of single F# objects" <| fun _ -> 
            //--Arrange--
            let (array , json) = createAJsonArrayOfString stringArray

            //--Act--
            let actual = jsonArray
                         |> ObservableJson.jsonArrayToObservableObjects<string> 
                         |> Observable.ToArray 
                         |> Observable.Wait


            //--Assert--
            Expect.sequenceEqual actual sArray
    ]

Indipendentemente dalla parte organizzata, il test è più della funzione sotto test, quindi è più difficile da leggere rispetto alla funzione sotto test!

  • Quale sarebbe il valore del test quando è più difficile da leggere rispetto al codice di produzione?

D'altra parte:

  • La composizione di due funzioni è un'altra funzione di per sé che può essere considerata come un'unità.
  • Mi chiedo se le funzioni che sono una composizione di più funzioni siano sicure di non essere testate?
  • Dovrebbero invece essere testati a livello di integrazione e accettazione?
  • E se sono brevi ma eseguono operazioni complesse?
posta Mohsen 22.01.2018 - 07:08
fonte

1 risposta

5

What would be the value of testing when it's harder to read than the production code?

Quando eseguiamo il test delle unità eseguiamo il non codice di verifica, verificiamo il comportamento .

Lo stiamo facendo per due motivi:

  1. Documenta il comportamento implementato.
  2. Rileva modifiche (indesiderate).

Inoltre: non è la dimensione del test (unità) che lo rende difficile o facile da leggere.

Il punto importante di un test unitario è che verifica una singola ipotesi sul comportamento dell'unità testata. La leggibilità del test sta nel modo in cui descrive questo assunto.

The composition of two functions is another function by itself which can be considered as a unit.

La dimensione di un'unità è un punto critico. Ma non c'è un limite difficile per questo. Mi piace la definizione di Roy Osherove che ha dichiarato: Un'unità è qualsiasi parte del codice dell'applicazione che ha lo stesso motivo per cambiare.

I wonder whether the functions which are a composition of multiple functions are safe to not to be tested?

Dipende. C'è qualche logica dietro questa combinazione o è semplice concatenamento? Il primo avrebbe bisogno di alcuni test, il secondo no.

Should they be tested at integration and acceptance level?

Entrambi i tipi di test hanno obiettivi diversi:

  • I test di integrazione mirano alla collaborazione delle unità a livello tecnico. Ciò significa che trova problemi nel cablaggio dell'applicazione e se le API delle unità si adattano. Questo è esattamente il punto in cui "la chiamata sequenziale" è testata.

  • I test di accettazione verificano la conformità dell'applicazione con i requisiti scritti. A quel livello, non ci interessano le unità di cemento.

And what if they are short but do complex operations?

Come ho già detto, verifichiamo comportamento , quindi le dimensioni non contano quando decidiamo di testare (unit-) una funzione.

    
risposta data 22.01.2018 - 08:21
fonte

Leggi altre domande sui tag