Udon/U# + Test Driven Development
Use Guribo's Udon/U# test-driven-development video as the concept demo, then test UdonSharp, networking, ownership, and late-join behavior in a current project.
Prove one behavior in a small scene, then test local, owner, remote, and late-join cases before moving it into the production world.
- Start from a backed-up Creator Companion project.
- Write down the expected behavior before building the UdonSharp script or prefab wiring.
- Test the smallest version before adding UI, polish, scoring, audio, or extra synced state.
Udon, CyanTrigger, and prefab tutorials sit on top of VRChat networking rules. Always decide whether the behavior should be local, synced, owner-controlled, or rebuilt for late joiners.
Playlist Companion
Creator: Guribo
Watch on YouTube: https://www.youtube.com/watch?v=-ZeJ_-KkUvU
Good Fit
Use this tutorial for the world interaction shown in the video. Build it in a duplicate scene first, then check ownership, sync, SDK Builder warnings, and a private upload before adding it to the live world.
Test-driven development does not have to mean a full enterprise test suite. For VRChat creators, it can simply mean:
- Define the behavior.
- Build the smallest script or scene that proves it.
- Test the cases that usually break in VRChat.
- Refactor only after the behavior is visible and repeatable.
Before You Start
- Confirm you are using the supported VRChat Unity version for the project.
- Open the project through VRChat Creator Companion when possible.
- Check for red Console errors before assuming the tutorial step is the problem.
- Make a backup or duplicate scene before changing assets, controllers, prefabs, or SDK settings.
What To Test
| Test Area | Question to answer | Why it matters |
|---|---|---|
| Local behavior | Does it work for the player who triggers it? | Local success is the baseline before networking. |
| Ownership | Who is allowed to change the state? | Many Udon bugs are ownership bugs wearing a different hat. |
| Remote viewers | Do other players see the same result? | A synced world feature is not finished until another client confirms it. |
| Late joiners | Does the state rebuild after someone joins later? | World state can look correct to existing players and wrong to new ones. |
| Reset/retry | Can the behavior return to a known state? | Debugging is much easier when the test can be repeated. |
Follow-Along Checklist
- Identify whether the interaction needs UdonSharp, CyanTrigger, or a prefab-only setup.
- Name the expected input, output, and owner of the behavior.
- Build the script in a small test scene with only the required objects.
- Add simple visible feedback so you can tell whether the test passed.
- Test with two clients when ownership, pickup state, audio, UI, or scoring can differ per player.
- Keep synced variables and expensive update loops small before expanding the system.
- Move the proven setup into the production scene only after it survives repeat tests.
Practical Test Examples
| Feature | Smallest useful test |
|---|---|
| Door or button | Press once, confirm open state, press again, confirm reset. |
| Score counter | Add a point locally, sync it, then check a second client. |
| Pickup logic | Transfer ownership, drop the pickup, and check remote visibility. |
| Timed event | Start, wait, reset, and test what a late joiner sees. |
| UI panel | Trigger it from desktop and VR interaction distance. |
Help! The video was made for an older SDK or Unity version.
Older tutorial UI labels can drift. Use the current SDK panels, Builder messages, and a private test upload before relying on the setup.
Help! The result works in Unity but not in VRChat.
Test in a built VRChat instance. Runtime permissions, networking, platform restrictions, and SDK validation can change behavior that looks fine in the editor.
Help! It works alone but breaks in the full scene.
Move dependencies into the test scene one at a time. Look for name/path assumptions, missing references, ownership changes, object activation order, or another UdonBehaviour changing the same state.
Help! I cannot automate the test.
Use a repeatable manual test. Write the expected result beside the object, add temporary debug text, and reset the scene state before each run. Repeatable manual checks still catch many world bugs.
Help! I want to apply this to a production project.
Rebuild it in a small copy first, then move only the confirmed pieces into the production avatar or world. That keeps tutorial experiments from becoming permanent project clutter.
Official References
Related Docs
Topics: worlds, udon, unity
