Should we TDD in statically typed languages, even in Elm?
Yesterday I offered an opinion on Bob Martin's video The Future of Programming. The comments went off on a tangent and ended up with the attention of a moderator. In amongst that I learned there had been a kerfluffle online earlier about another Bob Martin missive - Type Wars.
Ok, so bear with me.
The crux of that debate is the characterisaton of innovation in language as a battle of ideas that began between those that want no types and liked C and those that want types and perhaps if they are old enough liked Pascal, or more lately Java and C#. It seems in his world you had to choose your camp and defend it ... unless you switched sides.
Back to reality
What I do like in the article is what matches my experience, that in the Ruby world with dynamic typing the ultimate is to do TDD. Unit tests rule and drive you crazy. However over in the static typing C# world people seem happy with a lot of after-the-fact unit test creation. Although that can then become a drudgry task for some and risks not being done well.
I don't see a battlefront at all. It simply makes sense that if you are not getting help from a compiler and perhaps write all your software in a code editor, as many Ruby folk do, then you you need to have as comprehensive as possible unit tests. Hence TDD, which by definition gives you a certain amount of unit tests for every function.
If you are getting shit loads of help from your compiler and your IDE, as you do in C# and Visual Studio, and even more so in Elm, then you will need less from your unit tests.
I still admire those that TDD in languages such as C# but the reality I have seen is that very few judge it necessary to acquire those skills.
That said I came across this debate about a library in strictly typed Elm targetted at TDD. And this also.
Sidetrack
For those outside of the Elm community the contents of that debate might seem odd. Someone who loves TDD wants to have a testing library focused on it and puts in his own efforts to create it. The supporters of an existing testing library aren't happy it seems because it breaks a community desire to focus efforts for maximum impact.
I have long been bemused by those in the Elm community that push that there should only be one library per language function. Nothing wrong though with throwing some good questions in to really test if someone knows what is around and is committed!
The bottom line though is that if someone wants to go and write a library that overlaps another then that's their perogative. If it gets community support then let it be on the library's merits. You can just imagine whose sides people would have been on when Einstein came up with his reletavity ideas.
I hope what I saw at Elm Europe 2019 heralds a more open thinking future. Two groups forking the compiler and a leader of the community kicking off his own language development.
Create a whole new thing - Great! You may cause a revolution or you may influence evolution of the existing dominant tool.
Back to TDD
Now, looking at the idea of a testing library for Elm focused on TDD. As someone who has only dabbled in TDD in Ruby, the question of the value of TDD in Elm is what I am left with.
Elm, like Ruby, is a language that can just be loads of fun to program in, in quite a playful way. As well as being a solid choice for bigger projects, it is great for your own startup and for experiemental greenfield projects. A function may only last 10 minutes before you refactor things and it disappears. Elm also has the bonus of a compiler that really helps you along to write your code and refactor.
TDD would seem to be more suitable when the thing you are building is well defined. You can nail down at the outset what you intend to create. Then it's quite a mechanical thing to write the code to meet the tests.
Is TDD though just the articulation of the process you are doing in your head anyway, slowed down? You have identified a need for a function, you have in your head what you want out of that function and you write the function.
Some people advocate writing code incrementally, which is a form of transitory testing as you create using dummy values and function calls. Is that the same process again from an other view?
Let's assume you end up writing all your tests anyway. What I want to know is. Does doing TDD, particularly with statically typed languages, take some of the immediacy and fun out of the process? Or once you are good at it, is it a seamless experience with the same level of enjoyment?
Top comments (0)