I'm glad to have a new guest offering some tips. Corey Weathers of [Twilio](https://twilio.com/) is going to offer his perspective on the importance of software testing. Corey loves .NET and has worked for companies including Microsoft and the US federal government before joining Twilio as a developer evangelist. He works to inspire and equip .NET developer, underrepresented developers, and the Twitch community of developers with the tools they need to build the future of communications.
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.
This is episode 50 with some guest tips on Testing All The Things!
This week's tip is brought to you by devBetter.com.
Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us.
I'm glad to have a new guest offering some tips. Corey Weathers of Twilio is going to offer his perspective on the importance of software testing. Corey loves .NET and has worked for companies including Microsoft and the US federal government before joining Twilio as a developer evangelist. He works to inspire and equip .NET developer, underrepresented developers, and the Twitch community of developers with the tools they need to build the future of communications.
Welcome, Corey!
My name is Corey Weathers and I have the privilege and pleasure of being a .NET developer evangelist for a great company named Twilio. I’d like to start this week by saying a big thank you to Steve for inviting me on the Weekly Dev Tips podcast. This week I’d like to talk about something very near and dear to my heart as a developer – software testing.
Now you may be wondering why testing. After being a developer for a number of years, I have found the following things to happen pretty consistently – someone usually has a problem and says “hey a developer can fix that”. Hopefully they’ve checked in with a software developer before making that assumption, but that’s not often the case. It’s usually problems like these that turn into use cases, user stories, or requirements.
As product development happens, it can also be the case that these stories become more specific, nuanced, and refined in scope. When that happens, it’s not unusual to see more user stories created to cover the new scope that was removed from existing stories. What you end up with is one problem that a developer can fix turning into an ever-expanding list of user stories that become very complicated.
Now when we start writing the code for one use case, and more show up, we continue writing more and more code to meet the ever expanding list of requirements and after this, we miss the opportunities to validate the code that we’re building.
So one of the first mantras to remember here is – TEST EARLY.
Why? Because when you start early, you get to check one box that is super important – that is, you’re making sure that you’re building the right thing. This allows you to clarify your assumptions and confirm the suspicions you may have but that haven’t already been identified and figured out.
Which leads me to the second mantra – TEST OFTEN.
If Test Early ensures that you’re building the right thing, Test Often makes sure that you’re building the thing right. By making your code testable, you’ve added so much to your code base: maintainability, a measure of quality, and confidence in that things will work as you’ve both built and expected them to.
At this point you may be wondering, ok well where do I start? And I realize a number of you may be coming from different starting points. Some of you may be at the very beginning and haven’t written a single line of code; whereas others of you may have an application deploying into a production environment that has poor test coverage. I know that it can be tough to get started.
Hopefully this piece of advice should be relevant for you no matter where you’re starting from. My third and final mantra is START SIMPLE
Let’s use an example here. For our conversation – let’s assume we have an application that has a user interface, and this user interfaces connects to an API that takes some data and saves it in a database.
Assuming everything works as expected, you can start by writing a test for each part of this sequence. So one test can reproduce what happens when you click on the button when rendering the UI; a second test can simulate what happens when the UI calls the API; a third test can confirm that the database actually saved the data; and a final test can simulate all of the steps here by testing this one action with an API and database that looks close to what it will be in the real world. We could probably have an entire conversation as well about making sure you test setting up your application, but if you’re just getting started with testing there’s no need to start there.
With this suite of tests, you now have 4 tests that you can very easily expand on. You’ve started by testing the simplest path forward and can now add different modifications to this path, like what happens when my computer isn’t connected to the internet and my UI can’t talk to the API.
Now here’s where we reach the inevitable – well if I’m just starting out with writing tests and something doesn’t pass as I expect it to, what do I do? Here is where I usually say – this is a good thing. Your test is starting to work. Think about it for a second. If you start writing tests and they start making you ask questions about how your test is working, then you’ll probably end up changing your test a bit so that this question focuses more on your application. This is a win because you’ll learn how to write better tests in the process.
Alternatively, if you start writing tests and they make you question how your application is working, this is a win because it’s forcing you to make sure your application is meeting its intended need AND is testable as it is doing so. So write more tests, look for their results, and respond when the results don’t match what you expect.
That’s it from me this week friends. Remember TEST EARLY, TEST OFTEN, AND START SIMPLE. If you are interested in following up on testing, take a look at the Art of Unit Testing, written by Roy Osherove. He’s built an amazing body of content to help describe some of the why and how to begin testing. If you’d like to follow up with me, feel free to email me at corey@twilio.com. That’s C-O-R-E-Y@T-W-I-L-I-O.COM. That’s it from me this week. I’ll pass it back to Steve.
Great stuff, Corey! Thanks for sharing with everyone. Art of Unit Testing is definitely a good book - I'll post a link in the show notes.
That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.