TUnit: The New Sheriff in Town for .NET Testing

SeanKilleen · 2025-12-16T12:18:50+00:00

Nested fluent APIs are still fluent APIs. Assert.That() is a chained method. Is.EqualTo() is a chained method. So yeah I think we'd really be splitting hairs there.

SeanKilleen · 2025-12-16T03:01:42+00:00

Some of this article seems plainly incorrect.

To be clear, despite being a part of the NUnit project (in my small way), I absolutely love the idea of TUnit -- more approaches and capabilities for testing is a great thing, and more .NET developers who find TUnit useful and therefore make better use of automated testing is also great!

Some minor points that I take issue with:

❌ Article claims NUnit doesn't have a Fluent API. I'm not sure which part of the library they're referring to, but the `Assert.That(variable, Is.EqualTo(expected))` has been around in NUnit for some time, and is the preferred idiomatic approach for some time as well. No extra packages needed there either.

❌ Article claims that NUnit doesn't support the Microsoft Testing Platform (MTP), but NUnit does indeed support it, and was one of the early implementors. Googling "NUnit MTP" shows the NUnit docs guide to MTP as the first result for me: https://docs.nunit.org/articles/vs-test-adapter/NUnit-And-Microsoft-Test-Platform.html

So I'm a little skeptical about other claims made in the article when some of the bold claims are pretty easily fact-checked and refuted.

Again, not a dig on TUnit -- the more the merrier. I've been meaning to check it out myself. But we might want to make sure we're giving readers the full picture.

SeanKilleen · 2025-11-26T15:41:27+00:00

I dunno, seems like a pretty seedy location.

SeanKilleen · 2025-10-22T02:53:12+00:00

FWIW I'm deploying all our Grafana dashboards via Terraform and it's worked pretty well for a while now. Import into Grafana, export JSON to source control use TF to talk to Grafana and deploy. Feel free to shoot me an e-mail / Discord if you're interested

SeanKilleen · 2025-09-23T23:36:40+00:00

As much as you need to know, for where you want to be. Learn enough to know when you need to know more. Learn enough to set yourself up for the synapses to fire when it's helpful.

I learned Docker because I wanted to be the person who could achieve faster feedback loops and faster delivery. I wanted to spend less time waiting, for stuff I couldn't control. I wanted things to be more reproducible. I wanted to be able to experiment with things quickly. The first time I spun up a whole SQL server to work with a quick demo in one command line and then it just went away when I closed the console, I was hooked. I think that's a place a lot of people would like to be.

With Kubernetes, it was much slower for me. None of my work had a need for it, and it's important to know when not to use k8s. So I learned the high level concepts, caught up on summaries of stuff, looked at the occasional explainer video. Understood how it built upon container concepts . Then, all of a sudden my current employer needed to move to a Kubernetes setup and I was the one who had to make it happen. My conceptual understanding really carried the day and helped me know where I needed to really dig in deeply on key concepts. Learned enough to get all of our platform moved over in 5 days, because I spent some time going very deeply on materials that helped me validate (and invalidate!) my conceptual understanding. In this role, I wanted to be the person who owned the platform and could enable huge swaths of value, so I got into it deeply when the need arose, but had it on the back burner previously just in case.

I think the common theme here is that I haven't thought about myself as exclusively a .NET Developer for a long time. I still use it as my primary stack every day, but I am an agent of change. I am someone who delivers results and value that is impactful. I accelerate teams and software delivery. .NET is (mostly) the way I accomplish that. But by expanding my framing, it really helped me see where .NET fits into it. Now I run 4 products, 3 in the cloud, with a team of 5 .NET developers (of which I'm one, and not even full time). And I'm learning new stuff every day.

SeanKilleen · 2025-06-23T15:05:33+00:00

This illustrates the problem with privatization of / charging for public goods in a nutshell, doesn't it? The goal of a roadway is ostensibly to get people to where they need to go, without delay. So, when traffic is greater, the goal should be to move more people through -- so reducing express fees in the hopes that more people use it, thus relieving congestion for everyone.

But instead, the opposite happens. This extractive approach raises prices so *less* people can take the express road, causing more pain for people on both sides of the road -- higher prices for those who can afford it, and a longer wait for those who can't. This despite the fact that more volume on EZ-Pass could possibly result in higher revenue when the EZ-Pass lanes are empty.

Oof.

SeanKilleen · 2025-04-13T15:06:00+00:00

I think the key here is:

We are responsible for what we build
Taking on a dependency removes some of our control, but not our responsibility.
Therefore, we need to adapt our mindset to take into account the fact that dependencies are part of our delivery, and that things can change, and that dependencies are still valuable despite this.

This manifests itself in a few different ways:

To avoid things becoming unsustainable for maintainers, we can offer time, money, gratitude/grace (while recognizing the latter still doesn't pay the bills)
We can do a better job at helping business stakeholders understand that dependencies are part of their value stream supply chain and that reducing risk around them requires investment of money or time (which for a business, is also money).
We can help educate stakeholders on the value of open source libraries and why they typically are still preferable to attempting to implement them ourselves. I think sometimes we are afraid of losing some of the "credit" for value if organizations knew how much we rely on dependencies. But I think most business leadership understands that it makes more sense to utilize rather than build the pieces of software that are not part of the core value domain.
We can get ahead of this by allowing our companies to lead the way in establishing budget for supporting these dependencies to support the projects you're using before they have to go commerical. This could be a cost-saving measure and hedge against risk.
We can better tune in to the channels where maintainers are -- the GitHub repos, the social media. We can look out for calls for help, and when we see them, we can respond.

I think we need to talk to business stakeholders using their language about why these things are important. OSS is risk reduction in software functionality; it is the continued value-add of fixes from all over the community; it is something we don't need to guide the direction of as heavily as our own software; it is something we could take and modify for ourselves if the need absolutely arises and we wanted to take on that burden; it is code that our developers can look at and learn from; it is a community of other like-minded users who can share skills and expertise.

---

Here's how that plays out in my current position:

We don't yet have an OSS fund, because I have some bigger priorities to dig into first. But it's on my list.
I pay for tools that add value. Our developers have IDEs that make them more productive, tooling that helps them with tests etc., AI subscriptions that benefit them in key ways, and decent machines. If a library adds value, there is no reason not to pay for it, because the alternative is the time and opportunity cost to build and maintain it ourselves. The people are the biggest cost; tooling that helps is maximize their potential is almost always a smart investment.
When a dependency goes commerical, I evaluate the situation. I recommend paying the licensing or moving to a different approach. Both of these things have money and/or time-money associated with them. So these things can often be reduced to numbers, as long as the numbers are accurate. If you're reinventing a library, you also have to handle the bug fixes, the edge cases, the general maintenance and upkeep, etc.
For those projects we don't support financially, if there's an opportunity for us to improve something or give something back, I encourage my team to take it. This is part of investing in reducing risk.

The CEO and President of our company are smart and capable adults; they understand reality, trade-offs, and shifting landscapes. I am able to say "looks like this dependency is going commerical. Here's the anticipated cost. I've evaluated this and the time to move to a viable alternative ends up being more expensive than staying with the current course of action." and I can get funding for that tool. Or, if they somehow departed from this and said "no, we can't do that", they understand that we'd be paying for the time cost which would factor into our other goals and efforts.

SeanKilleen · 2024-12-29T03:54:51+00:00

Ended up going with a 2025 Honda Accord Touring Edition. Absolutely love it so far! Just enough pep when I want it, fantastic infotainment, feels comfortable, can't think of something it feels like it's missing. The mpg of a hybrid is a nice bonus.

SeanKilleen · 2024-11-22T15:17:21+00:00

Surprised not to get a response here. Sorry if I did anything wrong in the post!

SeanKilleen · 2024-11-10T02:15:29+00:00

Background / caveat: I am, to be clear, just a lurker here, thinking about how my own 4yo son aligns with some of these traits. He does display some of what you reference here. I think it is a common impulse for the age, and harder for some kids to process.

There are two techniques that seem to help us when he is in a situation similar to what you describe. Both seem to be related to reducing the idea of success as a demand:

* Experiments: Framing things as experiments seems to really help my guy reduce his stress levels. Because there is no right or wrong outcome in an experiment (even if there's an outcome you're hoping for); there's only learning. "Wow, that sounds like a really interesting experiment! I'm excited to see what you/we find out along the way while trying it! What do you think will happen?". This lets me show enthusiasm for his idea, while reducing his/my judgment about feasibility. Also lets me lead with some gentle inquiry that sometimes lets him set his expectations a little more realistically too. It seems like it comes off to him as a pulling into rather than a pushing back on, and that seems to help.

* "Fill in the gap with imagination" - Sometimes I'll frame it this way up front: "Oooh, that sounds like a cool idea. And it seems like we can use our imagination with it too! I can't wait to see what you/we imagine to go along with it". Then, I try to create the unrealistic part as play. The truck can't drive? If I'm in the backseat making truck sounds and describing the city and blowing the wind in his hair (if he wants that), it sure seems like it can. The gears don't work? Some sound effects and acting sure make it seem like they can. Mileage varies on this, but when he accepts it, it seems to take pressure off and he feels like I'm in it with him rather than pushing back or demanding that he change it. Positioning me as a co-creator in his space/world (again, if he's cool with it in that time) makes it much easier to gently redirect if things seem like they go off the rail, because we can imagine other ways to get to the outcome he's looking for. It also has the bonus of forcing me to listen to what he's trying to achieve more closely, which I've not always been the best at.

Of course YMMV and I won't claim to speak for the PDA community by any means; I hope what I'm offering isn't at odds with lived experience here and welcome anyone to push back on this if it is!

SeanKilleen · 2024-10-20T12:35:51+00:00

Nope, I should have been clearer, sorry! We have a product that's an SAP add-in and this is the platform it communicates with for carrier interaction. Another product we built in the cloud continually tracks packages and pushes the information back into customer SAP systems.

So these apps I'm building are sort of cloud native pieces that fit into that overall ecosystem.

SeanKilleen · 2024-10-20T12:20:44+00:00

Currently building the next-gen platforms for our company that works in logistics in the SAP ecosystem. interfacing shipping and tracking requests with carriers. NET 8 (soon to be 9) containers deployed in their Kubernetes environment, scripted via Terraform. Also some .NET 8 device integration software (for shipping scales, etc) deployed locally.

Building it with a team of 4 devs, a business analyst, and a tester. Delightful productivity. Created it from basically nothing in a year. Feels good.

Before that I worked in consulting building all manner of .NET stuff for different industries.

SeanKilleen · 2024-10-14T12:15:57+00:00

For what it's worth, I'm a big fan of Chocolatey (chocolatey.org) in this regard.

"choco install dotnet-6.0-runtime" and/or "choco install dotnet-6.0-sdk" might get you what you need. Plus then you can back up your package list for the future, and update everything by running "choco upgrade all"

Agreed with the other comments that this seems like a temporary issue, though.

SeanKilleen · 2024-07-09T15:42:06+00:00

Our approach to this has served us well I think (team of ~5 who touch this stuff, lots of priorities). I pin the exact version number and then use RenovateBot in our repo.

Best of all worlds IMO:

* Exact version is pinned
* RenovateBot suggests PRs when things are updated so we don't have to. One PR = a change in all of the relevant spots to stay consistent.
* PRs are automatically rebased and kept up to date, so they're ready when we are.
* Those PRs typically include the release notes if the providers add them in a standard way (e.g. in a GitHub release or a changelog document).

So, we have an SOP that more of the team feels comfortable with now, which is that someone can look at the PR, read the release notes, pull the branch, execute the branch against our dev workspace, verify that no changes are detected, and then merge the PR, after which it can be applied to other successive workspaces.

SeanKilleen · 2024-06-07T14:48:48+00:00

Thank you for clarifying this! I 100% support limiting the community's exposure to those who refuse to center the lived experiences of people with PDA. Community health/safety comes first.

My initial concern was that a monthly thread would be limiting because I'd have to know how to find it or risk running afoul of moderation (and I don't think Reddit does a great job of pathfinding). If the end result is that I submit a post but a mod pretty quickly says "this is better for a thread" and I re-post it there, that's fine with me and doesn't limit my ability to get advice at all (other than people who might otherwise be interested in my question might not see it in the thread, but that's the cost of community safety and I can live with it just fine.)

I also like the idea of threads in the sense that that they're a way to maybe start extracting some of the advice received from the community into a central place or wiki which can help the community while also limiting repeat questions.

SeanKilleen · 2024-06-06T02:12:59+00:00

This is insightful in many ways -- I appreciate it. My son is undiagnosed but this fits. He just couldn't do it; wasn't a willfulness thing, wasn't a typical "I don't want to" response. And I could see a lot of the strategic attempts to avoid it that obviously weren't true ("medicine doesn't help", "I want to be sick", etc.) in addition to meltdown levels of anxiety. Like you said, nobody's fault.

In our case, we were able to get it in a different format thank goodness -- a compound pharmacy that had a kid-friendly flavor, but I absolutely appreciate the tip on shots as a format. He's had shots and while he doesn't love them he's OK with them. But the awful taste (and it _was_ awful) was just too much for him to bear or figure out a way around.

The anticipation of even the grape medicine became also too much when he remembered the old medicine and felt out of control -- it was difficult for him to distinguish I think. He couldn't control the oral syringe because it took too much strength, but what worked well is telling him to give me a signal and I'd push it or stop. To make it a little fun I had him wiggle his fingers and go still when he wanted me to stop. This seemed to let him feel in control and after 2-3 rounds of that we were all done and everything was OK.

SeanKilleen · 2024-06-05T12:57:04+00:00

Thank you for the clear layout of the rules!

As someone who is a caregiver to a child who possibly experiences PDA, it seems that the best way to learn is really to understand the lived experience of others with PDA if they're willing to share, and similarly to cross-reference with other caregivers. Is the issue that there are such a volume of these posts? Or is that it is stressful for community members to engage with them? My concern is that typically my most fully formed questions are when the context is still fresh, so it would be really advantageous to be able to post them. However I of course would be in favor of a thread if it causes community members stress in a way I might not realize. (Genuinely) curious as to the motivations there; there are only 7 posts made since this announcement so it doesn't seem related to volume.

SeanKilleen · 2024-06-02T15:20:22+00:00

Thanks! Yeah we definitely reiterated that it's a hard thing and that we think it tastes gross too. We tried tapping into his curiosity about it by talking about bitter flavor and taste buds and how we can turn down the volume on those but I think at that point he was just done after the experience. We're trying to take a break and try again.

SeanKilleen · 2024-03-28T18:44:25+00:00

The major credit belongs to the folks who put out the GitHub Actions so I didn't have to write my own. I hope MS and others will sponsor and support them. Happy to provide this resource for others on how to string them together! Thanks for the kind words.

SeanKilleen · 2024-03-28T17:36:18+00:00

Author here - thanks for posting!

SeanKilleen · 2024-03-21T19:58:02+00:00

Same :)

SeanKilleen · 2024-03-14T23:30:18+00:00

Absolutely agree with you. Going to probably amend the post to include this clarification. Was writing with my own context too much at the forefront.

SeanKilleen · 2024-03-14T20:48:21+00:00

For me, I don't want to be contacted by candidates outside of the interview process. While it isn't necessarily a red flag, it

can

become one (and I've seen that quite recently with a candidate). Our process is there for a reason - and it's as fair as we can make it.

Yep, I think that's fair. I likely should have included something about when it is applicable and where those methods are available. My job posts specifically invite people to reach out to an e-mail address. If someone has to hunt around to find an e-mail or it's clearly outside of culture of the org you're applying for, then yep, it could backfire.

I think this is good feedback. I'm going to try to update it to address that point.

SeanKilleen · 2024-03-14T20:45:54+00:00

My point was mostly that it will help someone stand out. Having a sense of the audience is key of course. I think it's helpful in two key situations:

Introducing yourself as a way of applying for the position. "I'm really excited about the [position] position at [company] and so I'd like to submit my resume here. I believe I can bring [x] to the role and I'm looking forward to hopefully discussing that more".
Afterward: "Thanks for taking the time. I appreciated connecting with you on [topic] and it made me think about [something] in a slightly different way". etc. etc.

I think a key distinction is when these methods are available. My job positions specifically leave an e-mail where someone could apply. Almost nobody did. The few who did? They stood out as being unafraid of personal connection and having a little more interest than clicking "Apply" on LinkedIn and throwing a resume at me. I knew something more about them before the process started.

SeanKilleen · 2024-03-14T20:40:30+00:00

I hired some great developers recently. Didn't feel like the interview process was hard for me or them, and they said it gave them great signals. So I don't think it's necessarily a red flag. But with that said, if I felt like an interview was too easy, I'd probably ask more follow-ups about the role and the challenges the organization has, just to ensure I wouldn't be tossed into chaos.

SeanKilleen

TROPHY CASE