Writing Stories Guide
This guide covers the YAML story format used by Pilaf for defining test scenarios.
Story Structure
A Pilaf story consists of several sections:
name: "Story Name" # Required: Descriptive name
description: "Description" # Optional: What this test validates
setup: # Optional: Setup actions
- action: "..."
steps: # Required: Main test actions
- action: "..."
cleanup: # Optional: Cleanup actions
- action: "..."
Name and Description
The name field is required and should be unique and descriptive:
name: "Test Lightning Ability"
description: "Validates that the lightning command spawns lightning and damages entities"
Setup Section
The setup section contains actions that prepare the test environment:
setup:
- action: "execute_rcon_command"
command: "op test_player"
assertions:
- type: "assert_success"
- action: "execute_rcon_command"
command: "whitelist add test_player"
Action Reference
Server Actions
Server actions interact with the Minecraft server through RCON.
Client Actions
Client actions simulate player interactions through connected clients.
send_chat
Send a chat message as a player:
- action: "send_chat"
player: "test_player"
message: "/give @p diamond_sword"
assertions:
- type: "assert_success"
Assertions
Assertions validate the results of actions.
Common Assertion Types
| Type | Description |
|---|---|
|
Action completed without errors |
|
String matches a pattern |
|
String does not match a pattern |
|
Collection contains an item |
|
Collection does not contain an item |
|
Values are equal |
|
Values are not equal |
Variables and State
Pilaf supports storing and comparing states across test steps.
Capturing State
steps:
# Capture initial inventory
- action: "capture_state"
variable: "initial_inventory"
target: "inventory"
player: "test_player"
# Perform action that changes inventory
- action: "give_item"
player: "test_player"
item: "bow"
count: 1
# Capture new inventory
- action: "capture_state"
variable: "new_inventory"
target: "inventory"
player: "test_player"
# Compare states
- action: "assert_state"
expected: "initial_inventory"
actual: "new_inventory"
assertion:
type: "assert_not_equal"
Advanced Patterns
Multiple Players
Test interactions between multiple players:
steps:
- action: "send_chat"
player: "player1"
message: "/home set"
- action: "send_chat"
player: "player2"
message: "/home set"
- action: "send_chat"
player: "player1"
message: "/home teleport player2"
- action: "check_log"
pattern: "Teleported"
assertions:
- type: "assert_match"
Best Practices
-
Use descriptive names:
Test Lightning Abilityinstead ofTest1 -
Include assertions: Always validate the expected outcomes
-
Proper cleanup: Ensure tests don’t leave the server in a dirty state
-
Use appropriate wait times: Don’t over-wait, but allow for server processing
-
Test isolation: Each story should be independent
Related Documentation
-
Command Reference - Complete list of all actions
-
Best Practices - Tips and patterns
-
Architecture - Understanding how stories are executed