TL; DR:
Not every situation warrants tests
Not every type of test is equal
Join me Monday, September 30th at 9:00 PM PST for a live stream!
NEW COURSE LAUNCH!
and I are excited to announce our first course (of many) launching on Dometrain: Nailing The Behavioral Interview! Interviewing is an uncomfortable thing for most of us and just like anything else, it’s a skill that you need to practice to get better at it.There are plenty of resources available that focus on the technical side of things: Coding and system design. While these are also critical parts of your interview, the behavioral question portion carries more weight than most people realize. As software engineers, we love to focus on the technical stuff, but we must understand how to navigate the behavioral interview.
Get this course below, and for a limited time, you can use this code for a BIG discount: CNICKLAUNCH
What’s In This Issue
Exclusive Article: Do You REALLY Need To Write Tests?
They Told Us We MUST Write Tests!
Before we get too far, I just want you to know that I’m not about to suggest testing is bad. Nothing like that. But I’m of the mindset that saying “always” and “never” isn’t a great perspective — especially if we’re never talking about the situations that seem to be outliers.
The common thing we hear as software engineers is that we need to write tests. We need to have high test coverage. We should have a blend of different styles of tests — although some people have polarizing opinions about this one too. It all helps us get into a state where we can be confident about the changes that we’re making to our code.
This isn’t a surprise to you, I’m sure. So let me ask you the question:
Are there situations where you’re able to write tests and you consciously choose to not write them?
Said another way: are there situations where the value of adding test coverage isn’t worth it compared to some other path forward?
Even if you’re thinking about a time when you wanted to rush some feature or fix out — what is it that you were prioritizing over having test coverage?
Interestingly, as much as I love to talk about the value of testing, I’ve spent a lot of my career writing software that I absolutely wouldn’t write tests for.
Testing And My Professional Experience
During my time at Magnet Forensics, I spent a lot of time prototyping things. In fact, this even started earlier in my internships where I had an entire co-op placement focused on prototyping software written in WPF!
The thing about prototypes though is… You frequently throw out the code that you’re writing. It serves a purpose to help answer questions for the business:
Is this feasible?
Do customers want this?
Is this technology a viable option?
What’s the impact of us switching over to thing X?
You must be prepared for prototypes to “fail” and get tossed out. It doesn’t mean it was a waste of time since the purpose is generally to answer a question.
For me, when I am prototyping things, I almost never write tests. While there are folks that are heavy into TDD or others that are of the mindset we MUST have tests, the benefit isn’t there for me when I am prototyping.
My goal is to get a question answered as quickly and as accurately as possible. After that, the prototype is done.
… Except when it isn’t. Because sometimes prototypes “live on” because they end up working very well! From there, they go into subsequent iterations, or potentially live on to be integrated into the code base as a real thing!
For this very reason, when I write prototype code, I still try to focus on writing code that CAN be tested. I focus a lot on composition, dependency injection, and ensuring my different service integrations are coded against an interface. These are things that work well for me based on how I like to test.
If I have a prototype that lives on, I can decide to start testing the core pieces that begin to become more “foundational”. Odds are that there are aspects of the code that start to solidify or become more critical as the edges of the system get built out, and that’s where I’ll focus my attention to start writing tests.
What Does The Internet Have To Say?
I like asking the Internet these types of questions around testing. This time, Twitter was actually pretty quiet with opinions, unlike this post where I asked about database migrations that people like to use. Instead, Threads users had a lot to say! Let’s go over some of the comments:
If the app is in a lot of volatility tests are more work than they are worth. I’d only write them when the area is too complex/impossible to manually test. When the app is stable & the team is growing I’d expand that, but I’m definitely not a TDD evangelist.
This user’s perspective seems to be aligned with mine regarding the volatility part. If you’re changing the code significantly — like with a prototype — tests can slow things down. This needs to be balanced with what you’re shipping though, of course!
If I’m going to write them I prefer to start at high level business requirement verification once the business is firm on what it wants. Ultimately those are the system/integration tests that matter.Then as the source becomes more stable I’ll work my way down towards unit tests.
This user made the point that if they’re going to need to write tests, they try to get more coarse coverage. I used to be huge on unit tests but the tooling has made being able to write fast functional tests (I’m looking at you, testcontainers!) so simple that I get more value out of functional tests by far now.
Most of my personal projects don’t have tests. When there is more than one dev, I write tests.
This user made an interesting point that tests can be very helpful when trying to communicate expected behavior with other developers. This is something I’ve seen first hand make working together in a codebase less painful.
Do I write a test for everything I do? Definitely not. It would be a waste of time. A lot of people write unit tests for things that don’t matter on that scale. Like every class has tests. Why? Why not test the actual whole path of the application? Does it matter if your CalculateAverage function works in all cases? Or does it matter that doing end of year accounting produces correct values in every possible case?
And to wrap up the comments, I thought this was a great perspective. I’ve already mentioned that I used to be far more intentional with pure unit tests, but I’m much more aligned with this statement now. I can cover a LOT of code for little effort now given how tooling has been improving. While I still like to write unit tests on complex logic or things with edge cases I’d like more confidence on, I think you can get quite far with functional tests.
So… We Don’t Need Tests?!
Not so fast! That wasn’t the takeaway. I wanted you to see that there are plenty of developers out there who have different perspectives regarding when and how much to test — and that means that YOU should be thinking about this too!
Should every repository you touch have a minimum code coverage setting?
Should you have unit tests on everything?
Do you need automated regression tests on your code if you don’t expect it to live longer than a couple of weeks?
We should always be challenging how we think about things so that we can make better and more informed decisions!
In my own projects, I will get highly exercised code paths covered with functional tests. Complex areas or things that are mission-critical will get extra layers of unit tests so I can sleep better at night. And new things I am experimenting with generally won’t get much test coverage at all until I’m ready to commit to it. A rare exception here is when I find a situation where TDD works well for me — in which case the tests are guiding my hands!
Now, what about you?
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this course on nailing the behavioral interview:
Weekly Recap
Software Architecture: There And Back Again – Interview With Steve Ardalis Smith
Everyone knows the very best software architecture is Microservices.
End of discussion. Nothing more to say. Mic drop.
Steve ‘Ardalis’ Smith has something to say about this! In fact, he’s published courses specifically for people who may have gone down the wrong path and need to work “backwards” to a monolithic architecture.
Unfortunately, it’s very common that Microservices are used without fully understanding why there’s a benefit and what the trade-offs are. Fortunately, we’re all getting better at recognizing that Microservices are not a one-size-fits all solution.
A huge thank you to Steve for this conversation!
So, You Failed Your Interview… – Principal Software Engineering Manager AMA
So, your interview was a crash-and-burn. What now?
First of all:
Don’t beat yourself up. Seriously.
Interviewing is a skill we need to practice, and there are a lot of factors in the context of an interview that we can’t control.
But what we CAN control is how we reflect upon these experiences and improve for next time!
Let’s chat through what to do after your interview goes south.
As with all livestreams, I’m looking forward to answering YOUR questions! So join me live and ask in the chat, or you can comment now and I can try to get it answered while I stream.
Today we focus on:
My newsletter focused on iterating from interviews that didn’t go as planned
Jumping into articles/posts from LinkedIn & Reddit
Answering YOUR questions
FAILED My Google Interview: Here’s What To Do After
The last time I was looking for my next job, I dropped the ball.
Big time.
I hadn’t interviewed in around 8 years, and I was wildly under-practiced. The irony was that I had spent those 8 years regularly interviewing other people!
But after feeling sorry for myself, it was time to make adjustments:
Focus on what we have control over
Identify gaps to improve upon
Strategize a plan for them
… Get to work.
Remember, there are many things outside of your control when you’re applying to jobs and interviewing. Try to focus on what’s in your control and keep making improvements.
You got this!
Azure Blob Storage – Read and Write Within MINUTES!
You might have heard of blobs in computing — but no, they don’t have anything to do with one of our favorite blob Pokemon!
Blobs are Binary Large OBjects and there are cloud services available to allow us to read and write data.
In this tutorial, I’ll show you how to catch a Ditto. I mean… How to go through the basics of reading and writing blobs from a simple CSharp application!
Use SAS URIs from Azure Blob Storage Like a Pro!
Want to make blobs in Azure Blob Storage someone else’s problem? All we have to do is get SAS-sy!
We can use a Single Access Signature (SAS) token URI to allow others to read, write, and do other actions with blobs in our storage account.
If you need to defer the work of working with blobs in your system to some other component, this is a great option! Offload streaming data between only the necessary components.
In this tutorial, I’ll cover the basics of using read and write operations with SAS token URIs for Azure Blob Storage.
STOP Ignoring Early SaaS User Feedback – But Don’t Follow Blindly!
Feedback is hard for many people — especially when it’s critical. But you know what’s worse than no feedback?
Being stuck with no users because you can’t delight your customers.
In this vlog, I chat through how we need to sift through that feedback from our early users.
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
Did you say something about a new courseeeeee?
It's funny you mention not unit testing prototypes. If what I'm prototyping isn't UI related, I tend to use a unit test framework as the way I execute the code. :-D