Unit testing requires writing tests first then code, on the other hand in F# (and most of the functional languages) some codes are extremely short as follows:
let f = getNames >> Observable.flatmap ObservableJson.jsonArrayToObservableObjects<string>
let jsonArrayToObservableObjects<'t> = JsonConvert.DeserializeObject<'t> >> Observable.ToObservable
And the simplest property-based test I ended up for the latter function is :
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 ]
Regardless of the arrange part, the test is more than the function under test, so it's harder to read than the function under test!
- What would be the value of testing when it's harder to read than the production code?
On the other hand:
- The composition of two functions is another function by itself which can be considered as a unit.
- I wonder whether the functions which are a composition of multiple functions are safe to not to be tested?
- Should they be tested at integration and acceptance level instead?
- And what if they are short but do complex operations?