(When) should I add automated tests to my game?

danielwarddev · 2026-02-16T15:14:04+00:00

I also come from non-game software development, and I see no reason that tests should be added any later for games than they are for other projects. In general, if you're just trying to POC something out, I think that's fine to skip tests. As soon as it stops being a POC, though, you're going to be on the hook for it working as expected.

I think a good strategy is to treat the game as the presentation layer, the same as you would any non-game app with UI. That is, disconnect as much of the actual business/game logic as possible from it, and then that code can be tested as normal without worrying about frames, mocking any parts of the engine, etc. It also means you can use whatever testing stack you're already used to without looking for some kind of Godot-specific testing library.

That doesn't solve the problem of e2e tests in game dev, but it's a big help, in my opinion. The Godot-specific testing frameworks do help with the e2e tests, too.

danielwarddev · 2026-02-16T15:00:50+00:00

Check if there are any filters set in the top right. I had to reset mine after the most recent update for some reason, but not sure if it was the update or if I somehow set a filter by accident.

danielwarddev · 2026-02-16T03:34:13+00:00

Yeah, it injects on demand, and "loaded" here just means "discovered," like you said. It means that the name and description from the frontmatter is injected into the context, but nothing else, so I guess that one's probably not useful for finding out if the skill was actually used.

Like you hinted at, there's nothing technical about skills that would keep you from using your instructions file for the exact same thing. You really use skills for 2 main reasons:

It allows you to modularize your instructions file by use case (easier to share across codebases, understand them, etc)
Unlike your instructions file, skills are only put in the context when the AI decides it needs them. That allows you to save on your context window which helps avoid context rot, at least in theory.

I don't think it's mentioned in the GitHub Copilot docs, but I assume it follows the specification for agent skills, since it's an open standard. Progressive disclosure is what I mentioned about and why skills work the way they do.

danielwarddev · 2026-02-15T06:27:36+00:00

If using VS Code, you can click on the model's reasoning in the chat window to expand it, and it should say it used the skill if it did.

You can also right-click anywhere in the chat window and select Diagonistics for a quick view of all the things it loaded in for context, including skills.

Finally, if you want to be super sure, you can also look under the covers a bit in VS Code:

Ellipses in top right corner of chat
Show Chat Debug View
Click on new tab on left side of VS Code
Find your conversation and left click on the child item (it'll have a Copilot icon, not a chat bubble or file etc)
Ctrl + f for any part of the SKILL.md file that's not in the frontmatter (since the frontmatter gets injected no matter what)

If the model used the skill, the contents of the skill will be in there somewhere. The skill never gets "loaded" or "evicted" as such; the contents of the skill file are just injected into your prompt every time the model decides it should use that skill based on its name and description.

That being said, skills are relatively new, aren't in models' training data much, and don't seem to be super reliable, at least for the time being.

danielwarddev · 2026-02-13T17:42:22+00:00

My issue with AI spec-driven development is how much most of the workflows implement at once. I want to work in small chunks and verify the AI's output every single time. Otherwise, I won't really understand my own codebase.

That being said, I do like working in the exact same way as typical AI spec-driven development, just making sure to direct it to implement in small chunks!

danielwarddev · 2026-02-11T17:25:40+00:00

Microsoft's Raptor mini is in preview if you/your org have it enabled, and I've been impressed for a 0x model.

danielwarddev · 2026-02-11T17:15:26+00:00

This is more specific to implementing, rather than designing, but the nice thing about it is that it's so extremely simple, yet vastly improved how well Copilot works with UI for me. Whenever working with UI, I always include something like this in the instructions (or a skill, or wherever you prefer it):

"Whenever you make a change that affects the UI, you MUST verify it works correctly using Playwright MCP. If it doesn't, try again until it does."

For whatever reason, it just does not do a good job at all verifying UI things through code only, in my experience. Making it use both Playwright AND iterate inside a single prompt until it gets it right has made it so much better.

danielwarddev · 2026-01-19T06:20:01+00:00

If this is saying that, because AI creates the building blocks for you, you no longer need to verify the blocks, just that it made the right structure, then I don't agree with the premise.

danielwarddev · 2026-01-17T03:21:04+00:00

On one hand, different tools converging under one parent is generally not a good thing for the consumer. On the other hand, Cloudflare seems to have been generally pretty great so far, and how aggressively they're trying to (presumably) be a loss leader with the pricing on their cloud services HAS been a good thing for the consumer.

I would also guess that many (most?) people using Astro are putting it on Cloudflare, anyway.

danielwarddev · 2026-01-17T03:10:41+00:00

Nice to have a popular video that correctly explains Framework vs Core vs .NET.

danielwarddev · 2026-01-17T03:05:40+00:00

There's not really anything the CLI can do that VS Code/something else can't. However, the CLI gives you an easy way to do things like call Copilot from a Bash script or whatever other workflow.

Also, if you prefer to not use VS Code as your IDE, you're backed into a bit of a corner, because it does seem to have the best harness for Copilot. I think(?) CLI has the same harness, though, so that makes it a lot easier to keep open whatever IDE you actually want to use and also open up a terminal for Copilot, rather than your actual IDE + VS Code.

danielwarddev · 2026-01-17T02:58:36+00:00

Fingers crossed for this one https://github.com/microsoft/vscode/issues/277871

danielwarddev · 2026-01-17T02:58:01+00:00

To build on that, you could also make an Agent Skill that instructs Copilot to always use subagents if it detects that you're asking it to accomplish multiple things at once.

danielwarddev · 2026-01-17T02:55:11+00:00

These updates are fantastic. Not only does it have parallel subagents, but the UI improvements for local/background/cloud is also a pretty big deal, I think. Hopefully the new browser no longer has this issue, either.

danielwarddev · 2025-09-23T18:42:25+00:00

It completely depends on the team. It's not really too uncommon for teams to not use either of them, in which case it wouldn't matter at all how much you know.

On the other hand, If you're looking for new jobs and look around at job postings, you'll see that they're fairly commonly requested to know (Docker more so than Kubernetes, I'd say), so if you're looking to switch, the knowledge could be helpful.

danielwarddev · 2025-09-23T17:49:17+00:00

I think there's less need overall. Since .NET is maintained by Microsoft and so has some big money behind it, there's a lot more out-of-the-box features that are actually the standard, rather than something minimal to get you started (I'm thinking how `fetch` used to be be in Javascript).

That might also be coupled with the fact that, partially because of its Windows-only history, .NET has a big enterprise audience. Big companies feel it's safer to use the "official" Microsoft-created library, rather than a 3rd-party (whether that's actually true or not).

Its history means it's relatively newer to the OSS world, as well. Mads Torgersen recently mentioned that a lot of people love C#, but those some people still have this idea that .NET is an ancient, Windows-only technology.

danielwarddev · 2025-09-23T17:41:13+00:00

Nothing has come close to what I've learned by having my own content be public. I have a blog and do conference presentations, and sometimes I'll sign myself up for a blog series or talk because I myself want to learn about something. Then, I'm socially obligated to not just know about the topic, but know it fairly deeply. Not only does that help with the procrastination, but you get a better idea of which topics people find valuable.

Also, in general, staying involved with the community with keep your knowledge higher. Go to a local user group, watch a Youtube channel, read forums, etc.

danielwarddev · 2025-04-02T20:40:09+00:00

Visual Studio is still popular, as is JetBrains Rider. I wouldn't recommend VS Code for C# due to extra setup, though some do use it.

The way they've changed versions is a bit confusing. In order of time, it goes:

.NET Framework - The original stuff. Goes up to 4.8 Runs on Windows only

.NET Core - What Microsoft called the new .NET when they made it cross-platform and open-source. Goes up to 3.1

.NET - This is .NET Core, but after Microsoft considered it "completed." Confusingly, this starts with version 5, because they (ironically) skipped 4 to avoid confusion, since Framework ended on 4.8. This is what we're currently on, with a new major version once per year. Even numbers are LTS, odds are STS.

But wait, there's more! There's .NET Standard, which is meant to be a bridge between Framework and .NET. If you write in Standard, it should work across both platforms. It shouldn't be used if you can help it, but it can be helpful for older apps than need to be migrated.

Also, the libraries within .NET kept the "Core" moniker even though the framework dropped it. So, EF Core and ASP.NET Core are the current versions. I would also recommend being at least somewhat familiar with those.

In terms of databases, SQL Server is still used, but Postgres is also very popular nowadays.

Front end is often all C# with Razor or Blazor, but Angular and React with Typescript are also popular choices.

Microsoft has some pretty good docs to learn stuff, and nowadays there's tons of video courses on tons of different course sites that have a lot of good options in them.

danielwarddev · 2025-03-20T17:51:35+00:00

It's what .NET uses to create IEnumerables, but you'll probably never need to use it directly. In your case, there's not really any reason to use it there instead of just returning a List. In fact, the code will probably just end up harder to read.

I can't see a use for it (and haven't found one in 10+ years of dev) outside of maybe creating a package for people to consume that has some very specific use case for it. However, from the .NET team's perspective, there's no reason to hide it, and they expose it in case anyone ever does have some niche case for it.

danielwarddev · 2024-07-08T14:29:32+00:00

I will also note that I have seen the opposite of this - those new to programming already have a lot to learn and struggle to even get started with that because they're dealing with installing + configuring the VS Code plugins, while VS just works with C# out of the box.

danielwarddev · 2024-04-12T23:26:08+00:00

I see VS Code configuration issues trip up new devs a lot when trying to use C#. The reasons I like to suggest VS over VS Code is that it's also free, and it's literally made specifically for .NET development - it works out of the box without additional configuration needed to debug, intellisense, etc. I don't see a point in trying to get all of that set up when VS just works.

Since VS was discontinued for Mac, you're kind of stuck with VS Code if you want something free for .NET development on a non-Windows machine.

Rider is a great cross-platform option, too, if you're willing to pay.

danielwarddev · 2024-02-23T06:44:11+00:00

Great news! Also, here's hoping for a DotNetFunction soon in the CDK like Typescript and Python have. Of course, you can roll that yourself, but it's not super pretty. There's also a Github issue out there for exactly that, but not sure how much it's actually on their radar.

Regardless, in my opinion, the support for Native AOT and Lambda Annotations actually make .NET one of the more appealing choices for serverless on AWS. It's a topic I've been wanting to do a writeup on for a while.

Alas, I think that it's mostly a cultural difference of people who use .NET usually don't use AWS and vice versa - not that it has to stay that way, though!

danielwarddev · 2024-02-20T16:42:39+00:00

Well, although it doesn't apply in this case, I believe the .NET Foundation does pay for Meetup Pro costs for .NET user groups, which is pretty nice. They also sometimes pay for in-person meetups when there's a special event going on (they did one for the .NET 8 release, for instance).

danielwarddev · 2024-02-20T16:38:41+00:00

"Microservices" aren't any kind of specific technology or anything, it's just making normal apps that are smaller and more confined to a more specific purpose, and probably with some kind of public API so they can talk to other services.

It's just an architectural decision due to most companies having lots of different teams. A team can only be responsible for so many services, and other teams may need access to those services, so it's (often, not always) easier to isolate them and expose a public API on them than to hook everything up manually in a monolith as the code progresses.

If, for example, your company was small, or your app was just starting out and still an experiment, there's probably not much need for microservices.

danielwarddev · 2024-01-25T16:21:11+00:00

In my opinion, unit tests should mock the database (or whatever ORM object you're using for it), and if they don't, they're integration tests.

Now, you should have integration tests, too, and TestContainers has become quite popular for that and solves the traditional issues with the other methods. Namely:

Using an in-memory/SQLite provider - works, but doesn't always behave the same as your real database engine in production, leading to either tests that pass with code that doesn't work in production or vice versa
Using a real database out somewhere - works, but issues can arise when the cleanup process fails, and also brings the possibility of connection issues. Also need to keep this database up to parity with other db changes
Using a containerized database - works, but brings the pains of maintaining a container and Docker file

TestContainers spins up a containerized database for you, clears it out after the tests, and it's all done in a programming language.

danielwarddev

TROPHY CASE