Лабораторна робота № 4. Перший проєкт на Cargo з юніт-тестом

Мета

Навчитися створювати, збирати й тестувати проєкт на Rust за допомогою інструменту Cargo: ініціалізувати структуру проєкту, підключати зовнішню залежність (crate) і писати юніт-тести, зокрема з підміною (моком) вхідних даних через трейти.

lockpick/
├── Cargo.toml
├── Cargo.lock
└── src/
    └── main.rs

trait DataSource {
    fn fetch(&self) -> String;
}

fn process(source: &dyn DataSource) -> String {
    source.fetch().to_uppercase()
}

Обладнання та програмне забезпечення

• Codespaces / devcontainer курсу з попередньо встановленим Rust toolchain (rustc, cargo)
• Редактор з розширенням rust-analyzer (входить у типовий devcontainer курсу)
• Термінал усередині контейнера

Порядок виконання

1. Відкрити Codespaces/devcontainer лабораторної. Переконатися, що cargo --version виводить версію інструменту без помилок.
2. Виконати cargo new lockpick --bin (або скористатися наданим стартовим кодом — див. starter/README.md). Очікуваний результат: створено каталог з Cargo.toml і src/main.rs.
3. Реалізувати функцію fn generate_key(seed: &str) -> String і main(), що її викликає. Зібрати командою cargo build — очікуваний результат: збірка без помилок компіляції.
4. Запустити cargo run і переконатися, що програма виводить непорожній рядок у stdout.
5. Написати перший юніт-тест у модулі #[cfg(test)] mod tests { ... } і запустити cargo test — очікуваний результат: test result: ok. N passed; 0 failed.
6. (Рівень 2) Додати залежність у Cargo.toml (наприклад, sha2 = "0.10") і фактично використати її всередині generate_key, а не лише оголосити в маніфесті.
7. (Рівень 3) Ввести trait DataSource для джерела вхідних даних, написати мок-реалізацію цього трейту в тестовому модулі й тест, що використовує мок замість реального джерела, покриваючи і успішний, і помилковий сценарій.

Завдання за рівнями

fn generate_key(seed: &str) -> String {
    let mut acc: u32 = 0;
    for (i, b) in seed.bytes().enumerate() {
        acc = acc.wrapping_add((b as u32).wrapping_mul(i as u32 + 1));
    }
    format!("{:08X}", acc)
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn generate_key_is_deterministic() {
        assert_eq!(generate_key("alpha"), generate_key("alpha"));
    }

    #[test]
    fn generate_key_differs_for_different_seed() {
        assert_ne!(generate_key("alpha"), generate_key("beta"));
    }

    #[test]
    fn generate_key_handles_empty_seed_without_panicking() {
        assert_eq!(generate_key(""), "00000000");
    }
}

cargo test generate_key_is_deterministic   # запустити один конкретний тест
cargo test -- --show-output                 # показати println! навіть при успіху
cargo build --release                       # оптимізована збірка без символів налагодження

Парні теми СРС

• Рівень 2: srs07 — Модель володіння Rust проти збирача сміття і ручного керування пам'яттю
• Рівень 3: srs08 — Екосистема crates.io і семантичне версіонування залежностей

Критерії оцінювання та форма звіту

Студент здає лабораторну тегом submit/lab04 у своєму репозиторії/форку. Автоматичні тести рівня 1 (autograder/) перевіряють: проєкт збирається без помилок (cargo build), проєкт запускається (cargo run) і виводить очікуваний результат, cargo test завершується успішно й містить принаймні один тест, що реально перевіряє логіку (не порожній assert!(true)), а сигнатура fn generate_key(seed: &str) -> String лишилась незмінною.

Для рівня 2 автотести додатково перевіряють наявність зовнішньої залежності в Cargo.toml і її фактичне використання в коді (а не просто оголошення). Захист рівня 2 — усне пояснення, навіщо потрібна саме ця залежність і як працює обраний алгоритм хешування/шифрування на високому рівні.

Рівень 3 оцінюється вручну викладачем: наявність трейта для джерела даних, мок-реалізації в тестовому модулі й тесту, що перевіряє поведінку логіки на підставних даних без звернення до реального джерела. Оцінюється якість покриття (чи мок покриває і успішний, і помилковий сценарій).

Форма звіту: короткий опис реалізації (3–5 речень), скріншот терміналу із зеленим виводом cargo test, для рівня 2 — фрагмент Cargo.toml із підключеною залежністю, для рівня 3 — фрагмент коду мок-реалізації з коментарем, який сценарій вона перевіряє.