4

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>

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

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

When unit testing we do not verify code, we verify behavior.

We are doing it for two reasons:

  1. Document the implemented behavior.
  2. Detect (unwanted) changes.

Also: It is not the size of the (unit-)test that makes it hard or easy to read.

The important point about a unit test is that it verifies a single assumption about the tested unit's behavior. The readability of the test lies in how well it describes this assumption.

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

The size of a unit is a critical point. But there is no hard limit for it. I like the definition of Roy Osherove who stated: A unit is any part of the application code that has the same reason to change.

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

It depends. Is there any logic behind that combination or is it simple chaining? The first would need some testing, the latter would not.

Should they be tested at integration and acceptance level?

Both types of test have different goals:

  • Integration testing aims to the collaboration of the units on a technical level. That means it finds problems in the wiring of the application and if the APIs of the units fit. This is exactly where "sequential calling" is tested.

  • Acceptance testing verifies the compliance of the application with the written requirements. At that level, we don't care about the concrete units.

And what if they are short but do complex operations?

As I already mentioned, we verify behavior, so size does not matter when we decide to (unit-)test a function.

  • So you mean composition of multiple units should generally be tested unless they are obviously doing something simple. yes? – Mohsen Jan 22 '18 at 9:25
  • @Mohsen maybe its just my but yes.... – Timothy Truckle Jan 22 '18 at 13:34
  • 1
    I agree, for what it's worth; and this also gives you the opportunity to explicitly note some edge-case examples in the tests. This isn't so relevant if you insist only on property-based testing, but even if only for documentation purposes, I find it very helpful to list corner cases and explicitly test that the program does the right thing on them. The composition of simple functions with obvious edge cases need not be simple with obvious edge cases. – Patrick Stevens Jan 22 '18 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.