This is a subject dear to my heart

[...] The first (and most) important?thing I have noticed is that types play in part the role tests would have in other languages, in the sense that I use the compiler to provide feedback when I code, for example using so-called "holes" that can be filled somewhat automatically by the compiler. In essence, the compiler's output is just like another output of the dev environment, like tests,?leading me to needed?changes. This is particularly true when refactoring: changing a type, or a type's structure, leads to compiler errors to fix, then to test errors, then to more tests to introduce?behavior.

The way I write code is usually very outside-in, starting from a high level function with some type, and then zooming in refining the type. I go back and forth between types and tests in this process. This might be supported in different ways depending on the language, and it's one of the reasons I have grown interest over the past few years with Idris (and dependently typed languages in general) as they promise to offer more opportunity to design code incrementally through a dialogue with the compiler.

Another types have changed the way I do TDD is that I try hard to write property-based tests instead of example based tests. Writing a property first, then letting the failing examples drive the implementation provides a great feedback loop that has the advantage of forcing you to cover a lot of cases you wouldn't usually care to cover.

Also, in Haskell especially, having a strict separation of pure and impure code has a strong effect on the way I design and write code: Because the compiler has a much easier task when working on pure functions, I try very hard to stay in the pure world which means pushing back effects to edges of the code, which of course leads naturally to port/adapters like "architecture".

Last but not least, working in an expressive type system makes it possible to have your code's language closer to your domain's, expressing "constraints" from the domain directly in the types rather than laboriously test-driving some encoding. Here is an example I have used recently in a conference which you might find interesting (unfortunately in French):

[...] It's about representing a French SSN. I have tried to provide a strong case for better types by comparing a String-based representation with a strongly-typed one, with associated tests.?

Not what you asked, but when I was writing two (relatively simple) front ends in Elm, I deliberately didn’t write tests, relied on the compiler. I was disappointed in the results, as I found more problems after I was “done” than I’m used to. Most of them seemed to be faults of omission - “code not complex enough for the problem”. In theory, TDD isn’t about those, so shouldn’t cause me to realize them more quickly. In practice, it seems to, for me.

I worked a little on a Haskell project, mainly as a product owner and writing some tests for untested code. Not enough to have any conclusions, except that Haskell is a really nice language for writing tabular-style tests because of (1) relative lack of parentheses, (2) infix two-argument functions using backticks, and (3) precedence rules that didn’t seem to work against me. I forget the details, but I had a number of tests like:

f 1 2 3 `gives` 5

(Maybe that would require parens?)

Elixir is OK for tabular tests because of the pipe operator, but it’s not as good:

?

My own experience isn't interesting as caml was one the first language I've learnt (25 years ago) and don't realise if changes I notice are due to the language itself or the paradigm.

So I'm curious too, what have you noticed JB ?

I never want test doubles, but I also rarely want end-to-end tests. Of course, there are no "stubs" in FP, but merely functions that return hardcoded values.

I never want test doubles, but I also rarely want end-to-end tests. Of course, there are no "stubs" in FP, but merely functions that return hardcoded values.

How do you test your edges ? your monads ?

As for edges, I presume you mean the point of integration with something outside of the system? I write Learning Tests for the thing outside the system, which are usually integrated tests, and then at the point of integration I choose whether to integrate with the real thing or with a function that invokes the real thing.

Except for IO monads are values like anything else, at least in Haskell so “testing monads” usually amounts to testing functions.

For fine grained tests I try to avoid IO and use either the Handler pattern to group all IO actions together, or a custom implementation of a type class if I use mtl style.