|
Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
|
Here a simple scenario: You have a StringComparer and you want to add your own comparer to the mix - for example a "natural sort" order, so "file2" sorts before "file10" instead of after.
With C# 14 we can extend the family and make it feel natural!
GitHub Copilot CLI agentic workflows help developers plan, test, review, use /fleet, and delegate scoped feature work from the terminal with control today.
Every developer has experienced it.
A test passes perfectly on your machine.
It passes again in your local build.
You push your changes.
Minutes later, the CI pipeline fails.
You rerun it.
Now it passes.
Nothing changed.
Welcome to the world of flaky tests.
Flaky tests are one of the biggest productivity killers in modern software development. They waste engineering time, reduce confidence in continuous integration, and eventually train developers to ignore failing builds.
While flaky tests can have many causes, one of the most common is surprisingly simple:
Hidden external dependencies.
Learn about Unit Testing Best Practices
The word unit has an important meaning.
A unit test should verify one unit of behavior in complete isolation.
If a test depends on something outside that unit, it becomes harder to reproduce, harder to maintain, and more likely to fail unexpectedly.
A reliable unit test should behave the same way:
External dependencies make that much harder.
Reading or writing files seems harmless.
Perhaps your test loads a configuration file.
Maybe it writes temporary output.
Or perhaps it reads sample JSON from disk.
The problem isn’t the file itself.
The problem is everything surrounding it.
Questions suddenly appear:
None of these questions relate to the business logic you’re trying to verify.
Your test has stopped testing your code and started testing your environment.
Nothing makes a unit test less predictable than relying on a network.
Even calls to localhost introduce unnecessary risk.
Network-dependent tests can fail because:
The production code may be perfectly correct.
The network simply wasn’t.
Unit tests should never require a network connection unless they are intentionally integration tests.
Windows applications often read configuration from the Registry.
That works perfectly in production.
It usually doesn’t belong in a unit test.
Registry values differ between:
Tests that quietly depend on Registry values become extremely difficult to reproduce.
Time is one of the most overlooked dependencies.
Consider code like this:
if (DateTime.Now.Hour > 18)
It seems innocent.
Until the test suddenly fails tomorrow.
Or next month.
Or during daylight saving time.
Time-based logic should be isolated so tests can control it.
Otherwise your test suite changes behavior simply because the clock moved forward.
Environment variables are another hidden dependency.
Perhaps your code reads:
Those values differ everywhere.
Tests that depend on environment variables often pass on one machine and fail on another.
Random numbers.
GUID generation.
Temporary file names.
Thread scheduling.
These all introduce uncertainty.
A good unit test should produce the same result every single time it executes.
Anything random makes failures harder to reproduce.
Individually, these dependencies seem small.
Together they create enormous maintenance costs.
Developers begin saying things like:
“Just rerun the build.”
“That test always fails.”
“Ignore that warning.”
Those phrases are warning signs.
Once developers stop trusting the test suite, the value of automated testing begins to disappear.
The challenge is that many developers don’t even realize their tests contain these dependencies.
Reading the source code isn’t always enough.
A file access may happen three libraries deep.
A network call may occur through a helper class.
A registry read may happen inside a framework component.
These behaviors only become visible while the test executes.
That’s why runtime analysis is so valuable.
Instead of asking what the code looks like, runtime analysis asks:
What did this test actually do?
It’s important to distinguish between unit tests and integration tests.
Integration tests are expected to communicate with databases, web services, queues, file systems, and other external components.
That’s their purpose.
Unit tests have a different goal.
They should isolate business logic from those dependencies.
The problem isn’t accessing external resources.
The problem is doing so unintentionally inside a unit test.
Reliable unit tests share several characteristics.
They are:
Removing hidden dependencies is one of the most effective ways to achieve those goals.
Developers spend less time investigating failures.
CI pipelines become more reliable.
Refactoring becomes safer.
Confidence increases.
Static analysis can detect many useful issues.
But runtime behavior tells a different story.
By observing tests while they execute, it’s possible to identify hidden dependencies that are invisible from source code alone.
TypeMock Test Review performs this runtime analysis and highlights unexpected behaviors such as:
These insights help development teams identify fragile tests before they become flaky builds.
The best unit tests don’t just pass.
They pass consistently.
They don’t depend on your laptop.
They don’t depend on today’s date.
They don’t depend on network connectivity.
They don’t depend on files that happen to exist.
They validate one piece of behavior in isolation.
As automated test suites continue to grow, identifying hidden dependencies becomes increasingly important.
Because the goal isn’t simply writing more tests.
It’s building tests developers can trust.
TypeMock Test Review, included in the TypeMock Isolator 9.5 , helps identify hidden runtime dependencies that make automated tests fragile, unreliable, and difficult to maintain.
The post Why Unit Tests Should Never Access Files, Networks, or the Registry appeared first on Typemock.
Hello and Welcome, I’m your Code Monkey!
This week I had a pretty nice time, I went to Italy for the first time! Went there to see a show (My Chemical Romance) and sightseeing around Florence and Rome (plus the Vatican). Just 3 days since I can't afford a lot of time off work but still really nice! Managed to see a ton of interesting places and so much gorgeous artwork!
Challenge #9 on the Lab is now active! It's a super fun Fire Simulation challenge!
And like I mentioned last week, I will be enabling the FREE Trial so people can try it out without any risk to see if they enjoy this way of hands-on learning. I just need to set it up so stay tuned this week!
Game Dev: Kids play games differently
Gaming: Pick your next game like Tinder
Fun: Clocks, clocks, clocks!
This is a really interesting topic: kids today do not necessarily play games the same way people my age (38) did.
Here is a thread with a ton of research on this topic. It's about how younger players are growing up around Roblox, Fortnite, Minecraft, mobile games, Discord, and live-service platforms. For a lot of them, games are not just "games," they are social spaces. They are places to hang out with friends, talk, create, watch, compete, and exist online.
And I think that matters a lot for developers because the kids of today will be the gamers of tomorrow!
It is very easy to assume that the way people like myself grew up playing games is the "normal" way. Singleplayer campaigns, boxed games, consoles, local co-op, finishing one game then moving to the next. But for younger players, the default might be completely different. The game might be endless, social, user-generated, always updated, and deeply connected to their friend group. Since, again, kids today are tomorrow's adults, that means the games industry and what finds success might change significantly in the coming decades.
As developers it is important to understand how kids play games so we can make better decisions for the future. That does not mean every game needs to become Roblox or Fortnite. But it does mean developers should pay attention to changing player habits instead of assuming the market will always want the same things we wanted when we were younger.
That’s part of the reason why I do my Top 10 New Steam games every month, it’s so I can keep track of what genres are hot on Steam so I know what players are currently wanting to play.
 | I do wonder what the future will be like. Roblox keeps growing and growing which always amazes me. My question is as those Roblox players get older do they age out and start looking for more "standard" games like God of War or Call of Duty? Or maybe stay with Roblox for life? Or maybe they will go more into indie games that have unique mechanics like many Roblox mini-games? If that's the case that could actually be a nice positive! |
ENDING SOON!
Do you want to make a living as an Indie Dev? Then you NEED to learn all about Marketing! It’s a crucial topic nowadays.
Check out my videos with Steam Marketing Expert Chris Zukowski to learn how to get more wishlists and sell more copies.
And if you want all that marketing knowledge condensed into one single place then get his Wishlist and Visibility Masterclass. It is currently on discounted as part of his Summer Sale.
Get it HERE!
The Publisher of the Week this time is Tirgames assets, who makes a bunch of environments and props in various styles from modern to sci-fi.
Get the FREE Stylized Downtown Street which is a nice stylized street with shops, benches and trees.
Get it HERE and use coupon TIRGAMES2026 at checkout to get it for FREE!
This is a fun little tool for anyone with an out-of-control Steam backlog.
An indie developer made Dustpile, a free Tinder-like app for your Steam library. You connect your public Steam profile, it pulls in your games, and then you swipe through them: right for "I'll play it," left for "skip."
That’s a pretty clever UX idea!
A lot of players (myself included) have hundreds of games sitting in their library, many of them never played or barely touched. At that point the hard part is not "do I have something to play?" it is "how do I even choose?" Turning that decision into quick swipes actually makes a lot of sense.
In my case it included Paleo Pines, The Escapists, Spintires and more. Definitely games I'd love to play that I forgot I already owned!
It also includes useful filters, like games you never played, games under 2 hours, under 10 hours, or games you started and dropped. So instead of staring at your endless Steam list feeling overwhelmed, you can quickly build a shortlist.
This is just a small fun web app, but I like the idea! Sometimes the best interface is not more information, it is a faster way to make a decision.
| I quite like this, but even a tool like this isn't enough, I have 2470 games in my account! It's gonna take a while to swipe through all of them! |
How many ways can you build a clock? Turns out, many!
This website has tons of examples of different clocks with very unique very inventive designs.
I'm a big fan of the one titled Geometic Proof, very interesting looking.
This binary one is also super cool.
This one like a radar is also pretty inventive.
All of them have their code available so you can learn how they were actually built.
| I love little websites like these and the fact that the source code is included means this is a great learning tool. |
The weird history of the internet...
https://www.youtube.com/watch?v=7B0ydm64cV8
Awesome quick explainer on how the internet came to be! From a single computer to a giant worldwide network!
Three Ways To Make A Killer First Impression With Your Game
https://www.youtube.com/watch?v=s9VOnhQU1hE
Nice simple practical tips
Get Rewards by Sending the Game Dev Report to a friend!
(please don’t try to cheat the system with temp emails, it won’t work, just makes it annoying for me to validate)
Thanks for reading!
Code Monkey
In the ever-evolving landscape of software development, where everyone seems to chase the next big thing, the temptation to shortcut skill-building is as real as the constant pursuit of efficiency. But one truth remains irrefutable: infrastructure is the bedrock of reliable software, and you simply can’t “vibe code” your way to real solutions.
There’s a growing misconception that advances in AI and automation have somehow “solved” coding. It’s evident that some engineers and companies believe software development can be reduced to a series of shortcuts, much like gambling on a quick win. Yet, writing quality software is still an art, one that requires human insight and craftsmanship that can’t be replicated by machines alone.
Based on content from bigboxSWE
Vibe coding—a term often used to describe a reckless approach to writing code—seems to smooth over the rough edges until it gets to something that functions. But real reliability, the kind needed to earn those coveted “four nines” of uptime, is another story. The heart of this issue lies in feedback loops. When vibe coding a UI feature, issues might be caught in local environments or AI-generated tests. However, when vibe-coded projects hit production, they become ticking time bombs—prone to outages and unactionable alerts that even AI can’t fix.
The software world witnessed a cascade of such errors as 2025 bore witness to an unprecedented level of outages, much to the dismay of tech-savvy companies and users alike. These outages were an unfortunate testament to the fact that infrastructure is often where shortcuts become painfully apparent. For example, a leading cloud provider found themselves crippled when another company’s infrastructure decisions led to their prolonged outage.
These infra failures highlight the irreplaceable value of human expertise. In a world where even the most advanced AI tools can’t foresee or prevent every outage, infrastructure engineers are more vital than ever. This reality is reflected in the steady demand for these roles across tech companies, indicating that the foundational principles of reliability engineering have not been “solved” but remain complex and essential.
To those looking to solidify their understanding of infrastructure, diving into resources like the Google SRE handbooks or exploring DevOps courses can be enlightening. Moreover, engaging in exercises like self-hosting projects from the awesome-selfhosted list instills a hands-on appreciation for managing real-world tech stacks.
Meanwhile, companies like WorkOS have tackled specific challenges like enterprise authentication, so that developers can focus on crafting robust infrastructure without getting bogged down by authentication complexities. Their services come with audit logs, MFA, and role-based access control—all features designed to enhance security without sacrificing usability.
As we advance into a future that promises even more AI integration, let us remember: while some aspects of software may be amenable to “vibe coding,” the backbone of any application—its infrastructure—demands a level of precision and understanding that shortcuts simply can’t replicate. For those pursuing a career in software engineering, embracing the art and science of infrastructure will not only guard against outages but also distinguish you in a field where reliability is power.
In conclusion, never underestimate the power of well-constructed infrastructure. While coding continues to evolve, the vital need for skilled, thoughtful engineering is more prominent than ever. Infrastructure is where the illusion of shortcut-driven progress is shattered, and the hard-earned wisdom of human ingenuity prevails.
Cache stampede: When our cache turned against us
4 minutes by Bart Wullems
Cache stampedes happen when many requests all miss the cache at the same moment and hit the database together. A simple fix is adding a per-key lock using SemaphoreSlim, so only one request rebuilds the cache while others wait and reuse the result. ASP.NET Core's built-in HybridCache handles this automatically. Adding random jitter to expiry times also helps prevent many keys from expiring all at once.
How one team cut agent deployment time from 3 months to 1 week
sponsored by LangChain
Agents are non-deterministic, stateful, and dependent on models and tools that change without warning, so traditional engineering playbooks don't translate. LangChain's new guide, the Agentic Operating Model, shows how one enterprise team went from 3-month agent rollouts to production in a week by aligning people, process, and technology. Get the guide.
Role-based authorization in ASP.NET Core
12 minutes by Mukesh Murugan
Roles in JWTs are just claims with an agreed name. Mukesh suggests to write role claims at login, set RoleClaimType to match, then protect endpoints with RequireRole or the Authorize attribute. A common silent bug occurs when claim mapping renames your role claim to a long URI, causing every role check to return 403 with no error. Multiple roles in one call mean OR, while chained calls mean AND, and repeated checks belong in a named policy.
Redesigning the NServiceBus pipeline yet again
8 minutes by David Boike, Daniel Marbach
The NServiceBus message pipeline was redesigned to support modern .NET trimming and ahead-of-time compilation, which ban the dynamic code generation the old approach relied on. The solution uses default interface members to build a statically typed chain where each behavior wires directly to the next at startup. The result is a pipeline that starts 330 times faster, runs 25 to 29% faster on the success path, and existing custom behaviors require no changes to benefit.
ASP.NET Core background tasks with NCronJob and SignalR
4 minutes by Damien Bod
NCronJob is an open source NuGet package for running background jobs in ASP.NET Core. It works by implementing a simple IJob interface and supports both concurrent and non-concurrent job execution. In this demo Damien uses it to send messages every five seconds through SignalR, displaying them in a Razor Pages UI.
Discriminated unions in C# and .NET 11 (for real this time)
6 minutes by Maarten Balliauw
C# 15 adds native union types, letting you declare that a value is exactly one of several types in a single line. The compiler handles implicit conversions and, most usefully, enforces exhaustive pattern matching, so missing a case in a switch expression raises a warning. This removes the need for workarounds like the OneOf package or hand-rolled implicit operators.
And the most popular article from the last issue was:
Log in
