mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
Release 1.1.2 — the default path works end to end
Fix release for 1.1.1: the minimal path end to end, engine commands that run on Godot, Unity and Unreal, hook warnings you can see, and verdicts that say when they could not check. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.1 → v1.1.2). Fixes #67 Fixes #131 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ
This commit is contained in:
co-authored by
Claude Opus 5.5
parent
7ed2c3e9c4
commit
b21fa0f7f2
+59
-38
@@ -67,8 +67,10 @@ Before writing any code:
|
||||
|
||||
For Logic and Integration stories, you write the test file (or scaffold it for the developer to complete).
|
||||
|
||||
**Test naming convention**: `[system]_[feature]_test.[ext]`
|
||||
**Test function naming**: `test_[scenario]_[expected]`
|
||||
**Test naming** follows the engine's language (`.claude/rules/test-standards.md`):
|
||||
Godot `[system]_[feature]_test.gd` with `test_[scenario]_[expected]`; Unity
|
||||
`[System]Tests` with `[Scenario]_[Expected]`; Unreal one class per test,
|
||||
`F[System][Scenario]Test`, named `<Root>.[System].[Scenario]` (the root is below).
|
||||
|
||||
**Pattern per engine:**
|
||||
|
||||
@@ -78,8 +80,8 @@ For Logic and Integration stories, you write the test file (or scaffold it for t
|
||||
extends GdUnitTestSuite
|
||||
|
||||
func test_[scenario]_[expected]() -> void:
|
||||
# Arrange
|
||||
var subject = [ClassName].new()
|
||||
# Arrange -- auto_free: a Node subject left alive is an orphan (exit 101)
|
||||
var subject = auto_free([ClassName].new())
|
||||
|
||||
# Act
|
||||
var result = subject.[method]([args])
|
||||
@@ -90,9 +92,14 @@ func test_[scenario]_[expected]() -> void:
|
||||
|
||||
#### Unity (C# / NUnit)
|
||||
|
||||
The file goes under `Assets/Tests/EditMode/` (or `PlayMode/`), in the test
|
||||
assembly `/test-setup` creates — Unity compiles nothing outside `Assets/`.
|
||||
|
||||
```csharp
|
||||
using NUnit.Framework;
|
||||
|
||||
[TestFixture]
|
||||
public class [SystemName]Tests
|
||||
public class [System]Tests
|
||||
{
|
||||
[Test]
|
||||
public void [Scenario]_[Expected]()
|
||||
@@ -111,23 +118,42 @@ public class [SystemName]Tests
|
||||
|
||||
#### Unreal (C++)
|
||||
|
||||
The file goes inside the game module — `Source/<Module>/Private/Tests/` — or UBT
|
||||
never compiles it (see the test-root table in `.claude/docs/directory-structure.md`).
|
||||
The flags need an application context **and** a filter; there is no `GameFilter`.
|
||||
Name tests `<Root>.[System].[Scenario]`, where `<Root>.` is the filter in
|
||||
`commands.test`'s `Automation RunTests` — `<Project>.`, or the distinct root
|
||||
`/setup-engine` chose when the project name is also an engine area — so the
|
||||
project's test command finds them.
|
||||
|
||||
One class per test: `IMPLEMENT_SIMPLE_AUTOMATION_TEST` defines it, so a second
|
||||
test that reuses `F[System][Scenario]Test` fails to link.
|
||||
|
||||
```cpp
|
||||
#include "Misc/AutomationTest.h"
|
||||
#include "[Header].h" // the class's header: FDamageCalculator lives in DamageCalculator.h
|
||||
|
||||
#if WITH_DEV_AUTOMATION_TESTS
|
||||
|
||||
IMPLEMENT_SIMPLE_AUTOMATION_TEST(
|
||||
F[SystemName]Test,
|
||||
"MyGame.[System].[Scenario]",
|
||||
EAutomationTestFlags::GameFilter
|
||||
F[System][Scenario]Test,
|
||||
"<Root>.[System].[Scenario]",
|
||||
EAutomationTestFlags::EditorContext | EAutomationTestFlags::ProductFilter
|
||||
)
|
||||
|
||||
bool F[SystemName]Test::RunTest(const FString& Parameters)
|
||||
bool F[System][Scenario]Test::RunTest(const FString& Parameters)
|
||||
{
|
||||
// Arrange + Act
|
||||
[ClassName] Subject;
|
||||
float Result = Subject.[Method]([args]);
|
||||
|
||||
// Assert
|
||||
TestEqual("[description]", Result, [expected]);
|
||||
// Assert -- a float Expected: TestEqual(float, 75) is ambiguous (C2666)
|
||||
const float Expected = [expected];
|
||||
TestEqual(TEXT("[description]"), Result, Expected);
|
||||
return true;
|
||||
}
|
||||
|
||||
#endif // WITH_DEV_AUTOMATION_TESTS
|
||||
```
|
||||
|
||||
**What to test for every Logic story formula:**
|
||||
@@ -144,12 +170,15 @@ bool F[SystemName]Test::RunTest(const FString& Parameters)
|
||||
implementing a Logic story.
|
||||
2. **Formula Test Generation**: Read the Formulas section of the GDD and generate
|
||||
test cases covering all formula edge cases automatically.
|
||||
3. **Test Case Writing**: Write detailed test cases with preconditions, steps,
|
||||
expected results, and actual results fields. Cover happy path, edge cases,
|
||||
and error conditions.
|
||||
4. **Bug Report Writing**: Write bug reports with reproduction steps, expected
|
||||
vs. actual behavior, severity, frequency, environment, and supporting
|
||||
evidence (logs, screenshots described).
|
||||
3. **Test Case Writing**: Write detailed test cases with the four fields of the
|
||||
Test Case Format below -- precondition, steps, expected result, pass criteria.
|
||||
Cover happy path, edge cases, and error conditions. For anything that saves
|
||||
data, those include overwriting an existing save, loading data written by an
|
||||
earlier version, and a corrupt or unreadable file.
|
||||
4. **Bug Report Writing**: Write bug reports in `/bug-report`'s template (Bug
|
||||
Report Format below) — reproduction steps, expected vs. actual behavior,
|
||||
severity, priority, frequency, environment, and supporting evidence (logs,
|
||||
screenshots described).
|
||||
5. **Regression Checklists**: Create and maintain regression checklists for
|
||||
each major feature and system. Update after every bug fix.
|
||||
6. **Smoke Test Lists**: Maintain the `tests/smoke/` directory with critical path
|
||||
@@ -207,35 +236,27 @@ After a bug fix or hotfix, produce a **targeted** regression checklist, not a fu
|
||||
- Scope the checklist to the system(s) directly touched by the fix
|
||||
- Include: the specific bug scenario (must not recur), related edge cases in the same system,
|
||||
any downstream systems that consume the fixed code path
|
||||
- Each item states what to test, how to verify it passed, and what a failure looks like
|
||||
- Label the checklist: "Regression: [BUG-ID] — [system] — [date]"
|
||||
- Full-game regression is reserved for milestone gates and release candidates — do not run it
|
||||
for individual bug fixes
|
||||
|
||||
### Bug Report Format
|
||||
|
||||
```
|
||||
## Bug Report
|
||||
- **ID**: [Auto-assigned]
|
||||
- **Title**: [Short, descriptive]
|
||||
- **Severity**: S1/S2/S3/S4
|
||||
- **Frequency**: Always / Often / Sometimes / Rare
|
||||
- **Build**: [Version/commit]
|
||||
- **Platform**: [OS/Hardware]
|
||||
Write every bug in `/bug-report`'s template (`.claude/skills/bug-report/SKILL.md`,
|
||||
Phase 2A, "Draft the bug report"), not a format of your own. `/bug-triage`,
|
||||
`/day-one-patch` and `/milestone-review` parse these lines, and a bug without
|
||||
them is never counted:
|
||||
|
||||
### Steps to Reproduce
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
- ID `BUG-NNNN` — one past the highest number in `production/qa/bugs/`,
|
||||
zero-padded to four digits — in `production/qa/bugs/BUG-NNNN.md`
|
||||
- `**Severity**`: `S1-Critical` / `S2-High` / `S3-Medium` / `S4-Low`
|
||||
- `**Priority**`: `P1-Fix this sprint` / `P2-Fix soon` / `P3-Backlog` / `P4-Won't fix`
|
||||
- `**Status**: Open`
|
||||
- `- **System**:` — the system whose code must change
|
||||
|
||||
### Expected Behavior
|
||||
[What should happen]
|
||||
|
||||
### Actual Behavior
|
||||
[What actually happens]
|
||||
|
||||
### Additional Context
|
||||
[Logs, observations, related bugs]
|
||||
```
|
||||
Fill the template's other fields (Category, Frequency, Build, Platform,
|
||||
Reproduction Steps, Expected and Actual Result) as it lists them.
|
||||
|
||||
### What This Agent Must NOT Do
|
||||
|
||||
|
||||
Reference in New Issue
Block a user