In F# (and most of the functional languages) some codes are extremely short as follows:

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

or :

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?
• And what if they are short but do complex operations?