[valenterry]

What's your definition of "pure function". Apparently not "pure function" in the sense of "pure functional programming", because if that were so, your claim would just be wrong. Counterexample: "printToConsole: IO[null]": is a pure function but still not easy to test.

[e___ric]

The definition of "pure function" I'm familiar with from functional programming has no side effects including I/O. Assuming 'printToConsole' is performing I/O, you're describing a impure function.

[valenterry]

Then you have not understand what (pure) functional programming is and how it works.

I recommend you to have a look at Haskell, probably the most famous language for enforcing only pure functions in your program. And I took this example from Haskell.

Here is a good starting point for this concrete example: > https://stackoverflow.com/questions/59035420/understanding-p...

Quote (from the course 'Haskell Fundamentals Part 1' mentioned in the post):

> This example helps illustrate that putStrLn is not a function with side effects.

The answers explain the concept quite well.

[jerf]

While there is an important sense in which even IO values in Haskell are still pure values, it is not helpful in the case of testing.

    $ ghci
    GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
    Prelude> putStrLn "hello" == putStrLn "hello"
    
    <interactive>:1:1: error:
        • No instance for (Eq (IO ())) arising from a use of ‘==’
        • In the expression: putStrLn "hello" == putStrLn "hello"
          In an equation for ‘it’: it = putStrLn "hello" == putStrLn "hello"

If you want to test your IO code, and you should, you still have to test them from the perspective of them actually executing in the real world. There's no way to test them as pure values. The snippet above is only the beginning of your problems if you wanted to do that, but it a plenty sufficient problem on its own. In addition to the obvious problem that it points out that IO values are already not comparable to each other in the naive sense, there's also the more philosophical problem that the IO values are your programs, so even if you could run the test I show above, on more complicated expressions, your tests would be asserting that you wrote the program you thought you wrote, not that the program you wrote does what you think it should do.

[valenterry]

I agree, that was my point.

You probably replied to the wrong person.