At first I started to think about where my passion for test names came from. I started being passionate about test names a long time ago when I was working on a project where most tests were run after code was checked in. And the continuous integration server did not have a nice integration into the code base. Hence it was very costly to open up the IDE and search for a test name to look at the test code figure out what was wrong. Instead well names tests with good failure messages made it possible to quickly understand where the problem was and ask the right person to fix the problem.
Today we have better tools. And this scenario is very different than the scenario described in the article I read which is more about understanding failures as you are writing code. Similar to that author I also tend to use placeholder names while writing tests until I know what the test should really look like. And the final step for me is to give the test a name that signals intent so that future developers (including myself) know what the intent of the test was.
So in digesting that article I have come to realize that I should probably be less passionate about the naming of the tests and just continue to be passionate about what is tested and how failures are reported. Those two things are more important to me as I still consider tests to be the ultimate documentation of what I want to code to do. And as such, the name serves little more value than a summary of intent.
In the end this article also served as a good reminder to myself that in software engineering you should never stop learning.
Have a look at Kevlin Henneys videos on Youtube. They are great...
ReplyDeletehttps://www.youtube.com/watch?v=tWn8RA_DEic&list=PLfSbqRtrao26cRtSi4sneNIEeEQZCV5Nx&index=1
I especially like the idea of using a state machine to better understand how to structure tests. Thatäs a brilliant idea!
Delete