Spoiler: the checks for this challenge
These tests run when you press Check my code on the original article. Reading them first gives away the answer.
/// It compiles now, and the program still runs from start to finish.
#[test]
fn main_still_runs() {
main();
}
/// It compiles, but attack() no longer does its job. We only wanted to move the borrow, not the damage.
#[test]
fn attack_still_lands() {
let player = Player {
base_damage: 5,
bonus_damage: 2,
};
let mut enemy = Enemy {
name: String::from("Training Slime"),
health: 20,
};
attack(&player, &mut enemy);
assert_eq!(enemy.health, 13);
}
[Run and edit this example on the canonical article](https://journeytocode.io/borrowing-without-the-lecture/).
> **Tip:** The error is `E0502`. A borrow ends at its last use, so ask where `name` needs to start borrowing.
---
## Update the test
Our `attack()` test still passes three loose numbers, so it needs the new signature:
```rust
#[test]
fn attack_reduces_enemy_health() {
let player = Player {
base_damage: 5,
bonus_damage: 2,
};
let mut enemy = Enemy {
name: String::from("Training Slime"),
health: 10,
};
attack(&player, &mut enemy);
assert_eq!(enemy.health, 3);
}
```
The rule it checks has not changed.
An attack with five base damage and two bonus damage takes ten health down to three.
What changed is how the test says it.
It builds a player.
It builds an enemy.
It lets one attack the other.
Then it checks the enemy afterward.
That reads like the game.
The other three tests do not touch `attack()`, so they stay exactly as they were.
Run them:
```bash
cargo test
```
All four should pass.
We do not need a separate test proving that `attack()` does not change the player.
With our current `Player` type, an `&Player` reference does not allow `attack()` to assign new values to the player's fields.
The compiler checks that for us every time we build.
---
## The complete program
If you have been following along in your editor, here is everything in one place.
At this point, `src/main.rs` should look like this:
```rust
struct Player {
base_damage: u32,
bonus_damage: u32,
}
struct Enemy {
name: String,
health: u32,
}
fn click_damage(base: u32, bonus: u32) -> u32 {
base.saturating_add(bonus)
}
fn health_after_hit(
health: u32,
damage: u32,
) -> u32 {
health.saturating_sub(damage)
}
fn is_defeated(health: u32) -> bool {
health == 0
}
fn attack(
player: &Player,
enemy: &mut Enemy,
) {
let damage = click_damage(
player.base_damage,
player.bonus_damage,
);
enemy.health =
health_after_hit(enemy.health, damage);
}
fn main() {
let player = Player {
base_damage: 5,
bonus_damage: 2,
};
let mut enemy = Enemy {
name: String::from("Training Slime"),
health: 20,
};
while !is_defeated(enemy.health) {
attack(&player, &mut enemy);
println!(
"{} health: {}",
enemy.name,
enemy.health
);
}
println!("{} defeated!", enemy.name);
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn click_damage_adds_base_and_bonus() {
assert_eq!(click_damage(3, 4), 7);
}
#[test]
fn health_never_drops_below_zero() {
assert_eq!(
health_after_hit(3, 10),
0
);
}
#[test]
fn zero_health_is_defeated() {
assert!(is_defeated(0));
assert!(!is_defeated(1));
}
#[test]
fn attack_reduces_enemy_health() {
let player = Player {
base_damage: 5,
bonus_damage: 2,
};
let mut enemy = Enemy {
name: String::from("Training Slime"),
health: 10,
};
attack(&player, &mut enemy);
assert_eq!(enemy.health, 3);
}
}
```
Run both:
```bash
cargo run
cargo test
```
The Training Slime should fall in three hits, and all four tests should pass.
---
## What we learned
Along the way, we encountered:
- ownership
- moves
- `Copy` values
- `&T` references
- `&mut T` references
- functions that change a value instead of returning a new one
- when borrows stop being used
- why Rust prevents conflicting access
You do not need to memorize all of that yet.
The important change is what our attack says.
We started with:
```rust
enemy.health = attack(
enemy.health,
player.base_damage,
player.bonus_damage,
);
```
We ended with:
```rust
attack(&player, &mut enemy);
```
The player is read.
The enemy is changed.
Both stay where they belong.
And the compiler now checks that `attack()` keeps its side of that deal.
---
## There is a bigger shape missing
Look at what `main()` is holding now:
```text
player
enemy
the combat loop
```
That is a fight.
It is not a game.
When the Training Slime dies, the program simply ends.
There is no next enemy.
There is no stage counter.
Nobody earns anything for winning.
And every one of those things would become another loose variable inside `main()`:
```text
player
enemy
stage
gold
experience
```
We have seen this problem before.
Three numbers were not a player.
A pile of variables in `main()` is not a game.
The pieces that make up our game need one place to live, and one place that decides what happens when a player clicks.
Next, we will put the game in one place.
**Small function. Bigger game.** [Join the discussion on the canonical article](https://journeytocode.io/borrowing-without-the-lecture/)