Lambda the Ultimate

The advantage is simple: no need to create a test environment, no hidden environmental dependencies or configurations to manage and test. There are many programs to systematically test functions, such as QuickCheck.

I vaguely recall a survey list for this subject on SO or Haskell reddit, but can't recall where.You might have some luck starting with testing in Haskell and following some research paper trails.

Unfortunately, in literature, we generally give analytic arguments and existence proofs of helpful tools. The problem is that people write code in surprising ways in practice, so I'm more swayed by careful empirical methodology.

I've never came across a real experiment testing this. Stefan Hanenberg is probably the closest you get to scientific evaluation of basic functional programming concepts, and the closest he's come is some static typing phenomena. Maybe it has been examined -- if so, he probably cited it :)

If you have an effects type system, then you can statically verify it. This could be a simple "pure" attribute that disallows access to any mutable stores or calling any non-pure functions.

But even then, that would just cover implicit side effects. You probably don't call explicit side effects as side effects since you are explicitly consuming and producing a world value, but its still imperative programming.

Tests on "pure functions" can be run in any order, including concurrently, across any number of machines. If tests aren't "pure", then you have to reason about sequencing and memory state (so perhaps you can't run them on different machines).

Further, if tests are on "pure functions" then it's straightforward to compute the set of implicated tests from a code change. Otherwise you just run all of the tests for each change.

QED.