vikingowl
5b202fed4f
- Include detailed architecture overview in `docs/architecture.md`. - Add `docs/configuration.md`, detailing configuration file structure and settings. - Provide a step-by-step provider implementation guide in `docs/provider-implementation.md`. - Add frequently asked questions (FAQ) document in `docs/faq.md`. - Create `docs/migration-guide.md` for future breaking changes and version upgrades. - Introduce new examples in `examples/` showcasing basic chat, custom providers, and theming. - Add a changelog (`CHANGELOG.md`) for tracking significant changes. - Provide contribution guidelines (`CONTRIBUTING.md`) and a Code of Conduct (`CODE_OF_CONDUCT.md`).
59 lines
1.8 KiB
Markdown
59 lines
1.8 KiB
Markdown
# Testing Guide
|
|
|
|
This guide provides instructions on how to run existing tests and how to write new tests for Owlen.
|
|
|
|
## Running Tests
|
|
|
|
The entire test suite can be run from the root of the repository using the standard `cargo test` command.
|
|
|
|
```sh
|
|
# Run all tests in the workspace
|
|
cargo test --all
|
|
|
|
# Run tests for a specific crate
|
|
cargo test -p owlen-core
|
|
```
|
|
|
|
We use `cargo clippy` for linting and `cargo fmt` for formatting. Please run these before submitting a pull request.
|
|
|
|
```sh
|
|
cargo clippy --all -- -D warnings
|
|
cargo fmt --all -- --check
|
|
```
|
|
|
|
## Writing New Tests
|
|
|
|
Tests are located in the `tests/` directory within each crate, or in a `tests` module at the bottom of the file they are testing. We follow standard Rust testing practices.
|
|
|
|
### Unit Tests
|
|
|
|
For testing specific functions or components in isolation, use unit tests. These should be placed in a `#[cfg(test)]` module in the same file as the code being tested.
|
|
|
|
```rust
|
|
// in src/my_module.rs
|
|
|
|
pub fn add(a: i32, b: i32) -> i32 {
|
|
a + b
|
|
}
|
|
|
|
#[cfg(test)]
|
|
mod tests {
|
|
use super::*;
|
|
|
|
#[test]
|
|
fn test_add() {
|
|
assert_eq!(add(2, 2), 4);
|
|
}
|
|
}
|
|
```
|
|
|
|
### Integration Tests
|
|
|
|
For testing how different parts of the application work together, use integration tests. These should be placed in the `tests/` directory of the crate.
|
|
|
|
For example, to test the `SessionController`, you might create a mock `Provider` and simulate sending messages, as seen in the `SessionController` documentation example.
|
|
|
|
### TUI and UI Component Tests
|
|
|
|
Testing TUI components can be challenging. For UI logic in `owlen-core` (like `wrap_cursor`), we have detailed unit tests that manipulate the component's state and assert the results. For higher-level TUI components in `owlen-tui`, the focus is on testing the state management logic rather than the visual output.
|