This week's tip is on how to be more productive by reducing feedback loops with continuous testing. Our guest is Al Rodriguez. Al is a multiclassing wizard spending most of his time using .NET wherever possible but levels up in other tools to get the job done.
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.
This is episode 52, on feedback loops and continuous testing with guest Al Rodriguez.
This week's tip is brought to you by devBetter.com.
Need to level up your career? Looking for a mentor or a the support of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet for weekly group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help members improve. Interested? Check it out at devBetter.com.
This week's tip is on how to be more productive by reducing feedback loops. Our guest is Al Rodriguez. Al is a multiclassing wizard spending most of his time using .NET wherever possible but levels up in other tools to get the job done. Take it away, Al:
Hi. I'm Al Rodriguez and I'm here to talk to you about Continuous Testing.
One way to improve development productivity is to reduce the time of your feedback loop.
A classic example of this is application startup time to validate a UI change.
A 3 minute wait for an application to build and startup feels like an eternity when you've only changed a background color.
This is why some tools exist to hot reload only the part of the application that has changed. Thus reducing the time that you, a busy developer, have to wait.
We see tools like this all over the development space to reduce the feedback loop time.
One example is inside our Text Editors. If you miss a semicolon or misspell a variable name, you immediately get feedback in the form of a red squiggly underline.
Another example of this is a Continuous Integration pipeline. Once you check code in, a pipeline is invoked to build your application, run any tests it needs to, and alert the team if there are any issues.
All three of these examples I've mentioned have wildly different feedback times because they're for very different types of tasks.
But lets move on and talk about unit tests.
The common loop I see when working with unit tests is to write the test, then click the button to run it.
It's a very manual process.
The feedback loop there is usually a couple of seconds. Short and sweet.
As time goes on you'll change some code and eventually click the button to run the tests again.
But which tests? All of them? One class at a time? The individual tests you think are impacted by your changes?
Even worse, what happens if you forget to run the tests?
Now you're checking code into source control that hasn't been fully tested.
What does the feedback loop look like in that situation?
Best case scenario, the tests are run after a few changes are made.
Worst case scenario, they're not even run.
And that's just you. There's also the scenario of people on your team who don't think to run the tests.
On a project with historically low, or no, tests, the idea of running them doesn't cross your mind because it's not part of the normal flow. So new code could have broken the tests, and since they weren't run, no one will find out for a what may be a few weeks.
That's fun and all. But you know what's better? What can reduce that feedback loop?
What you said is right, sure,
but the answer I was looking for is: Not clicking the button. Or more
accurately, not having to click the button. Having a tool that will run
your tests for you.
Continuous Testing is when you have a tool to run your tests as soon as the they are created, changed, or any code impacted by a test has been changed.
And if that's not continuous, I don't know what is. Which would be a problem. So if that's not what Continuous means, please let me know. I can't have another situation where I go years using a word wrong. That would be unfortuitous.
Other benefits of Continuous Testing tools include a UI element to show the current state of the code under test.
For example, when looking at your code there is a visual indicator inside your IDE to show you each line of code that has any failing tests, or if there are no tests for that line. Which is a great reminder that you need to write those tests.
If you want to get started with Continuous Testing there are several options depending on your choice of tooling.
In the .NET space you can use the Live Testing feature built-in to Visual Studio Enterprise.
If you don't have an Enterprise license, another great tool is NCrunch. You can only get NCrunch by purchasing a license, but it's cheaper than upgrading to Visual Studio Enterprise. Which is the reason I use it for my own personal projects.
Finally, if you're working with .NET Core you can use the dotnet CLI command: dotnet watch test
The watch command listens for file changes. Once a file has changed, the test command is run on that folder.
Note that this isn't as efficient as the previous tools because it re-runs all of the tests, not just the ones that have related changes.
If you're in the
javascript realm you can do something similar with npm's watch package. Using
the command npm run test --watch will continually run your test task whenever
files change just like we saw with dotnet.
In summary, do what you can to reduce your feedback loop with automated tests.
And that's all I have to say on this topic.
If you'd like, you can find me on twitter under the handle @ProgrammerAl, that's P-R-O-G-R-A-M-M-E-R-A-L.
Or you can find me interviewing people on their side projects on the Developer Side Quests podcast.
Now go forth and forget where that Run Tests button is. Or even better, remove it from your IDE if that's an option.
Thanks for letting me ramble on your show Steve. Back to you!
Thanks, Al! Great tips! It's great that CLI tools make it so easy to set up this continuous feedback loop, even for developers who don't have access to great commercial tools like VS Enterprise and NCrunch. I hope a few listeners will give continuous testing a try, and if they have any questions or feedback, leave it on the show's page at weeklydevtips.com/episodes/52. I've also added links to the resources covered this week.
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.