Update src/pages/build/validation.md

Co-authored-by: ThetaSinner <ThetaSinner@users.noreply.github.com>

src/pages/build/validation.md

@@ -43,7 +43,7 @@ Validation is a broad topic, so we won't go into detail here. There are a few ba
 * Data may have dependencies that affect validation outcomes, but those dependencies must be [addressable](/build/identifiers/), they must be retrievable from the same DHT, and their addresses must be constructable from data in the operation being validated. (Note that because an action references the action preceding it on an agent's source chain, this is a dependency you don't need to build into your data.) If dependencies can't be retrieved at validation time, the `validate` callback terminates early with an [indeterminate result](/build/validate-callback/#validation-outcomes), which will cause Holochain to try again later.
 * When multiple actions are written in a same [atomic transaction](/build/zome-functions/#atomic-transactional-commits), actions' ops can only have dependencies on prior actions committed in the transaction, not later actions.
 * You don't need to validate your data manually before committing --- Holochain [validates it after the zome function that writes it is finished](/build/zome-functions/#validate-dht-operations), and returns any validation failure to the caller.
-* **Test, test, test.** Validation is the gate that accepts or rejects all DHT data, so make sure you write thorough test coverage for your validation functions. If the data being validated has no dependencies on DHT data or DNA/zome info, we recommend writing Rust unit tests for the [validation function stubs](/build/validate-callback/#create-boilerplate-code-with-the-scaffolding-tool) that the scaffolding tool generates. We also recommend testing your validation code by writing single- and multiple-agent [Tryorama](https://github.com/holochain/tryorama/) test scenarios for zome functions that write data (we'll write about Tryorama soon; in the meantime, you can check the Tryorama GitHub readme and the scaffolded tests in a project's `tests/src/` folder for guidance).<!-- TODO: link to Tryorama page -->
+* **Test, test, test.** Validation is the gate that accepts or rejects all DHT data, so make sure you write thorough test coverage for your validation functions. If the data being validated has no dependencies on DHT data or DNA/zome info, we recommend writing Rust unit tests for the [validation function stubs](/build/validate-callback/#create-boilerplate-code-with-the-scaffolding-tool) that the scaffolding tool generates. We also recommend testing your validation code by writing single- and multiple-agent [Tryorama](https://github.com/holochain/tryorama/) test scenarios for zome functions that write data. This lets you check that your validation rules pass both when authoring data and checking data authored by other agents. (we'll write about Tryorama soon; in the meantime, you can check the Tryorama GitHub readme and the scaffolded tests in a project's `tests/src/` folder for guidance).<!-- TODO: link to Tryorama page -->
 
 ### Things you don't need to worry about