Skip to content

test & linter debug guide #629

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mqole wants to merge 2 commits into
base: master
Choose a base branch
from
+20 −2
Open

test & linter debug guide #629

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7cf2b2b
test & linter debug guide
mqole Mar 23, 2026
bcc59e3
a few updates
mqole Mar 25, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 18 additions & 2 deletions src/en/general-development/tips/debugging-tools.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,11 +30,27 @@ Parameters the `vv` commands take:
* Secondary debug console
* UI tree view

## Running Tests
## YAML Linter

YAML linter is a tool that attempts to serialize every prototype defined in a `.yml` file. It will collect information on any prototype it cannot serialize and provide the user with an output of those entities. This makes it incredibly useful for identifying where errors are occuring in your yaml.

To run YAML linter, you can use the shell command `dotnet run --project Content.YAMLLinter` in your project folder. If you're using an IDE such as Rider or VSCode, you can also use the YAML linter preset to run your project.

## Running Integration Tests

Integration tests are extremely minimal simulations of what you need to run SS14 - just a server-client pair, no maps or lobbies or anything - and you can run game system code on these simulations in order to locate issues that can only be found through live game simulation. You can use this to make sure a bit of code works as intended by simulating its effects and comparing them against expected values, for example making sure that when you buckle someone to a chair, then that person can't move.

To run integration tests, use the shell command `dotnet test` in your project folder. You can also use `dotnet test --filter` followed by the name of a specific test if you don't want to run every test at once. This is recommended as some tests can take a long time to run! IDEs such as Rider or VSCode may also have built-in ways to run tests without using the terminal.

When you open a PR to the Wizard's Den repository on GitHub, integration tests will run on your PR automatically. If tests fail, you'll need to update your PR before it can get properly reviewed.
Copy link
Copy Markdown
Member

@beck-thompson beck-thompson Mar 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add some info / images on how to see the output of the tests? A lot of new people struggle with this!

Copy link
Copy Markdown
Contributor Author

@mqole mqole Mar 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you grab an appropriate image for me? id love to add one but im not certain what you want the image to include exactly


```admonish note
`Content.IntegrationTests` is the directory containing integration tests. It is not the same thing as the similarly-named `Content.Tests` folder. You should run the tests in both of these folders to debug your changes.
Copy link
Copy Markdown
Member

@ArtisticRoomba ArtisticRoomba Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

integration testing is much different from unit testing. you should describe the differences between them and remark that the feature being PRd should have tests (whether it can be unit tested, integration tested, or both). saying "you should run the tests in both of these folders" is a bit unclear

Copy link
Copy Markdown
Contributor Author

@mqole mqole Mar 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how would you describe the differences between them? ive only ever needed to run integration tests on things, i wasnt aware unit tests had a significant difference

Copy link
Copy Markdown
Member

@Tayrtahn Tayrtahn Mar 25, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The short version is that unit tests test a single "unit" (typically a class) while integration tests test that multiple units work together correctly.

For example, a there's a unit test that uses spoofed data to make sure that the methods of LocalizedDataset work as expected - correctly enumerating its entries, etc. This test doesn't need to bring in any other systems in order to run.

By contrast, there's also an integration test that loads up all the localized dataset instances in the game (going through resource loading, yaml parsing, prototype management, etc) and makes sure that they're set up correctly.

Unit/integration tests are used widely in software development outside of SS14, so Google can provide you with more info about the concepts and their differences.

Edit: I lied, the "unit" test example actually does use some dependencies, so it's not a "pure" unit test. The hypothetical test I described is still a good example though!

```

### Server GC

I recommend you enable [**server GC**](https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/workstation-server-gc) to run SS14 tests, *especially* integration tests (it cuts integration test times in *half*).
It's recommended that you enable [**server GC**](https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/workstation-server-gc) to run SS14 tests, *especially* integration tests (it cuts integration test times in *half*).

To enable this in various editors:

Expand Down
Loading