cargo build- Build the projectcargo test- Run all testscargo test <test_name>- Run single test (e.g.,cargo test test_string_matcher_contains_behavior)cargo test -- <test_name>- Alternative single test syntaxcargo fmt- Format codecargo clippy- Lint code
- Add logging where appropriate
- Use the macros:
debug,err,warn,info,traceand keep in mind where does a specific logging level make sense. - Warn and err are self-explanatory
- Info should be used for general user information
- Debug and trace should be used for hunting bugs
- Use
anyhow::Result<T>for error handling withanyhow::Contextfor error context - Import external crates first, then local modules
- Group imports by type (std, external, local)
- Use
snake_casefor functions and variables - Use
PascalCasefor types and structs - Use
SCREAMING_SNAKE_CASEfor constants - Private fields use
snake_case
- Use
anyhow::Result<T>return types - Add context with
.with_context(|| "description") - Use
?operator for propagation - Log warnings with
log::warn!for non-fatal issues - Log errors with
log::error!for fatal issues
- Module-level docs at top of files
- Public structs have
#[derive(Debug)] - Use
#[cfg(test)]for test modules - Tests use
#[test_log::test]and#[tokio::test]where appropriate - If
tokio::testis not needed, usetest_log::testfor new tests
- When asked to write tests, first plan out what edge cases you will handle.
- Write unit tests.
- Reference the
test_helpersmodules to see how to mock inboxes. - When asked to write tests, it is okay if they fail. Maybe the problem is in the implementation. You were asked to write the tests to discover bugs.
- Do NOT change the implementation unless EXPLICITLY told to do so when writing tests.
- When testing the new tests, do not run all the tests but just run the tests you wrote like
cargo test string_matcher.
DSL.md: the specification of the DSL used for configuring the program. Read when writing tests for lexer/parser/resolver/etc.src/inbox.rs: main Inbox trait that is used for manipulating emails