Ever heard the expression Bread and Butter Testing? Based on a quick Google Search I wouldn’t be too surprised if you haven’t and it could very much be a local expression* but I thought I would share what this expression means to me and how you may use it.
I won’t share any code in this article because it varies a lot on your setup and is quite platform specific (maybe in another article). Instead, think of this as an inspirational article.
* I first came across this expression when I started working for Creuna back in 2017 when it was introduced to me by Stephan Lonntorp (now Engineering Manager at Volvo Cars). Cheers Stephan! ❤️
Something a little extra on the side
Bread and Butter tests are tests that don't necessarily target a specific feature or integration, but instead it focuses on your development setup / infrastructure and things that are easy to overlook. A little heads up that is super nice to have but that you could totally be without if you're perfect and never make mistakes. ;)
Think of it as something a little extra on the side that you didn’t expect but is a nice compliment to your development (or dinner) process. Much like a basket of bread and butter.
Here are some useful Bread and Butter Tests that I’ve come across that could be good inspiration to your project.
- DI (Dependency Injected) Services Testing: A test that covers all your constructor injected services and verifies that they are all registered in the IOC container. This test is golden and has saved me a lot of trouble and time troubleshooting why a specific service is not injected properly. Sure, in most cases you notice this as soon as you spin up your application anyway, with a not so friendly YSOD, but sometimes it’s not that obvious and the error might be silent and you need to investigate logs to realize that you just missed something so obvious as registering the service in your IOC container.
- Route to Controller Testing: In a lot of projects I’ve worked on we register our custom routes in the route table in a class called RouteConfig.cs. This is just a long list of custom dynamic urls pointing at a specific controller and action together with possible route parameters. In these projects we also have a Bread and Butter test that goes over all of these custom routes and verifies that they actually point to an existing controller and action so that we are notified if we have misspelled or accidentally removed a controller action still in use by a route. Again, easy mistakes and nice to cover with these types of tests.
- License Testing: Tests that verifies that you have a valid CMS license (like in Episerver/Optimizely for example) or any other license file for that matter. And if this test could actually parse and validate the expiration date you could throw a failing test a good few weeks before it actually expires and save yourself the trouble of having to find out in your running application (possibly in production).
- Editor Experience ❤️ Testing: This is not something I’ve tried (yet) in Umbraco, I’m just throwing out ideas here. In an article I wrote called “MAKE LOVE NOT POOR EDITOR EXPERIENCES” I mentioned that descriptions and icons in Umbraco doctypes and properties are a nice way of showing an extra effort and I guess it wouldn’t be too complicated to have a Bread and Butter test that iterates over all of your doctypes and properties and check if they have a custom description and icons defined. Let me know when you’ve built this and send it over to me. ;)
I’ve seen something similar in some of the Episerver projects I’ve worked on where the tests would check if the Page/Block type has a custom UI descriptor and make sure it has translated description and a valid svg icon defined.
As you can see these are just inspiration and I think you get the gist by now. Maybe you already have a bunch of these infrastructure or development setup tests in your projects but you didn’t know they could be called Bread and Butter Tests? Well now you do! Or do you have a better name? Please let me know.
Cheers friends! ❤️