The .NET Stacks #17: EF Core 5, Blazor + CSS, and community!

EF Core 5 is done, Blazor CSS isolation, and more!

Dave Brock
Dave Brock

Just a reminder that in your methods, try to write less than 914 “using var” statements.

We’re talking about a lot of little things this week:

  • EF Core 5 is done
  • Blazor CSS isolation
  • The curious case of unit testing
  • September is F#-tember at The .NET Stacks
  • Community links

EF Core 5 is done

This week, Arthur Vickers proclaimed that Entity Framework Core 5.0 is done, pending any issues or bug fixes. Arthur says the team has also spent the last two weeks squashing bugs, writing better exception messages, and improving the docs.

You can check out the official plan, but I’ll be looking forward to the following features:

You can check out the daily builds today.

Blazor CSS isolation

With the latest .NET preview, the Blazor team released CSS isolation (among many other things). With limited documentation available, I wrote about it.

The gist: CSS isolation allows you to scope your CSS to your components. Instead of loading all your styles unnecessarily and incurring CSS bleed when dealing with multiple components and libraries, you can say: I only want these styles to be associated with my component. There’s a lot of flexibility, too—you can use the ::deep combinator in your scoped CSS to pass styles down to child components and working with CSS preprocessors is a snap.

CSS isolation in Blazor is a build-time step—this means there’s no reliance on JavaScript or .NET code, you can easily integrate with existing tooling, and there’s no performance hit if you aren’t using it. However, this also means you’re forced to recompile to see any new CSS changes. This will force you into using dotnet watch if you haven’t already—hitting F5 in Visual Studio every time is no way to go through life.

I’ll be writing the official Microsoft reference doc on it, so if you want anything covered that isn’t in my post or the GitHub issue for the doc, let me know.

The curious case of unit testing

My thinking on unit testing has been shifting a bit in the last six months or so. The timing couldn’t be better: I’m seeing a lot of chatter about unit testing both inside and outside of the .NET developer community.

Back in early July, Alexey Golub wrote a popular piece called Unit Testing is Overrated. It aligned with a lot of what I was thinking about—placing your primary focus on unit tests isn’t always valuable. This is not to say you shouldn’t value them, or champion them, or appreciate them. Quite the opposite. It’s when we decouple so much while saying “we need to make the code testable” where, in the end, the only value is to make unit testing work. In the end, are we just testing our mocks?

Instead of spending a ridiculous amount of time setting up mocks that don’t replicate much of a complex software system, why not rely more on integration tests? This opinion would be blasphemy just ten (or even five) years ago. After all, unit tests should be quick, repeatable, and pure (no side effects). With the rise of containerization and better cloud infrastructure, the “integration tests are slow and flaky” argument is less of an issue.

To that end: last month, Khalid Abuhakmeh wrote Secrets of a .NET Professional, in which he writes this (which led to a spirited Twitter discussion):

The systems we build have many complex external dependencies. The hubris of thinking we could mock away decades of investment in a database, web service, or any other technology has been the source of many frustrating arguments. In my opinion, one good integration test is worth 1,000 unit tests… With the rise of containerization, the pain of writing integration tests has never been lower.

For me, my thought is that unit testing is crucial for testing and verifying core (and pure) business logic. But you need to test against your dependencies, and many times the best bang for your buck comes with integration testing—as long as the tests are reasonably fast and cheap. As for me, I’m no longer obsessing over testing every single layer of an MVC app (as an aside, Andrew Lock wrote a nice post that questions the value of unit testing APIs and MVC controllers).

Our industry gets dogmatic, so opinions like these can get heated. But to me, it doesn’t really seem like a controversial opinion to take a nuanced approach to testing so we can find the most value in our hectic days. Containerization has revolutionized our industry—so let’s take advantage of it.

September is F#-tember at The .NET Stacks

Do you work in F#? Or are you a C# developer and intrigued by its possibilities but haven’t found time to dive in? As C# has “borrowed” a lot of functional programming paradigms, you might be wondering about tradeoffs between C# “with functional bits” and straight F#. I’ve got you covered.

Next week, I’m interviewing Isaac Abraham, author of Get Programming with F#. Soon after, I’ll post an interview with Phillip Carter, the PM for F# at Microsoft. Stay tuned for some great conversations.

🌎 Last week in the .NET world

🔥 The Top 3

📢 Announcements

📅 Community and events

We had three community standups: Languages & Runtime explores miscellaneous topics, Machine Learning talks SciSharp, and ASP.NET talks about Microsoft.Identity.Web.

😎 Blazor

🚀 .NET Core

⛅ The cloud

📔 Languages

🔧 Tools

📱 Xamarin

🎤 Podcasts

🎥 Videos

.NET Stacks

You might also like

Dev Discussions: Cecil Phillip

Dev Discussions: Cecil Phillip

We talk to Cecil Phillip about microservices and distributed systems.

Dave Brock
Dave Brock
Interviews
Dev Discussions: Steve Sanderson

Dev Discussions: Steve Sanderson

We talk to Steve Sanderson, the creator of Blazor, about what's next.

Dave Brock
Dave Brock
Interviews

Featured Posts

Low Ceremony, High Value: A Tour of Minimal APIs in .NET 6

Low Ceremony, High Value: A Tour of Minimal APIs in .NET 6

Ask About Azure: Why do resource groups need a location?

Ask About Azure: Why do resource groups need a location?

Use Azure Functions with .NET 5

Use Azure Functions with .NET 5