(Replying to PARENT post)

>Anything you could unit test without mock objects

You can unit test without mock objects because you're following functional patterns.

๐Ÿ‘คcarlmr๐Ÿ•‘2y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

... or working in an environment or on a problem for which functional patterns apply.

Suppose you are writing a "CRUD" app that writes to a relational database, how do you apply functional programming to that? The whole point of an application like that is that it makes side effects.

In some cases you can break those problems down into functional pieces. Consider Python drivers for a product like

https://www.arangodb.com/

One major problem is that you want drivers that work synchronously and asynchronously, the structure of the average api call is something like

   def query(parameters):
      encoded_parameters = encode_parameter(parameters)
      url = generate_rest_url(configuration, parameters)
      response = do_post(url, encoded_parameters)
      return decode_response(response)
To make that async all you have to do is stick "async" before the def and put an "await" before the do_post. 95% of the API calls have a structure like the above. Most of the complexity lives in encode_parameter(), generate_rest_url() and decode_response() are all perfectly functional functions that are easy to test. Code gen the API stubs and you get sync and async switching almost for free. Contrast that to the option of mocking do_post.
๐Ÿ‘คPaulHoule๐Ÿ•‘2y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

Not necessarily. For an easy counter example, build a Sierpiล„ski triangle. Easy to unit test. Easier to build using imperative code than functional. (This goes for a ton of fractals, honestly.)
๐Ÿ‘คtaeric๐Ÿ•‘2y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

Could you elaborate a little bit more? These days i write a lot of go code and i end up using mock objects for different interfaces to write unit tests. Is there another way to do this?
๐Ÿ‘คashishmax31๐Ÿ•‘2y๐Ÿ”ผ0๐Ÿ—จ๏ธ0