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?