开云体育

This is a subject dear to my heart and I have had some experience doing various forms TDD in Haskell in the past years, after more than 10 years trying to practice in Java.

I even proposed a session on this very topic entitled "Type and Test Driven Development" at this year's DDDEurope but had to pull it back for personal reasons.

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.?