Here’s a fun list; programming languages which don’t have unit testing built into their standard compiler/runtime tool-sets or standard libraries.
• Java/JDK (It includes 33 other binaries and tools however. 🙃)
• PHP (PHP Unit, like JUnit is a framework and does not come with the language)
• Node/JS — Nope. Most active language and testing is an after thought. —
• C++ (No standard or standard library tooling)
Well, then who the heck does?
• Python has a in its standard library unittest API, though it’s a bit limited.
• Golang has go test, built in to the compiler tool-chain that’s quite nice. Has no assert statement though which annoys me bit
• Rust has various macros to assist in testing and it is built into cargo
• Ruby has a Test standard library package.
1 Its not in the design of the language, it’s not going to be in the ethos of your developers, your community and your projects. If it’s an afterthought to the language and it’s creators, why should we expect it to be different for the frameworks that drive the application development. Why would we expect libraries to give it the same duty of care in considering how their implementations will fit into peoples testing framework, particularly if you can’t judge which of their community tool-sets they’ll be using. This is where not even having things like assert in your language and basic constructs for people to test the code that they write will lead to a trickle down effect on everything that touches it.
2 The stopgap solutions have deficiencies and approaches which are come up by community standards, this trickles into the frameworks and leads people to steer away from testing their code. NodeJS not having a testing binary means we rely on fragile community tools. JUnit might be a defecto standard, but it’s still a dependency, not a first class citizen. This means every project will include extra tools for their specific needs, will bring in their own specific approaches to solve mocks and dependency injection. Learn one framework and you’ll need to learn a different set of testing tools because the standard is not defined.
3 Affordances in design intent create better results for the people that have to use them. Put a shoe rack at the front of your house and people will leave their shoes there. I’m talking about creating simple affordances to make it simple to do the right thing. Rust built it well into its language, and it begot rspec which became the golden standard for BDD tests. My favourite thing about Golang is the SRCFILE_test.go pattern which encourages you to write tests along side your source files. Not hidden in away in another folder but first class to your own code base. If your tests files are treated as just as essential to your source code then it will be treated as such. Make it easy and people will do it, and consistently. Your code should be as easy to create to the standards of the Standard Library, Go is the only language that’s made that possible in my experience.
“But we can just do what the right anyway”. Yes, we can. Of course, I believe that strongly teams and individuals can create, discuss and adapt standards to do things better. However, every month programming languages continue to keep getting more features, more things to optimise and increase better ways of doing things, but they’re ignoring blatant gaps. Why is there still no official testing binary in NodeJS is beyond me, and projects would have gone in much better directions if there was. Instead people have relied on whatever the testing tool is flavour of the month and ready to become apart of your growing NPM dependency debt.
There is endless debate and great reading on different ways in which testing approaches can benefit how you write your code and tests; but I wanted to express my frustration. Good design in tools can create better results, and I feel like with every passing year of my dev life I love Golang more and more the choices the team made in its creation.
Did you enjoy this blog? Let me know what you’d like to see more of in the comments.
Need some creativity in your technology delivery or want to have James rant at you about poor technology choices? Talk to James directly!