Skip to main content Skills Marketplace 커뮤니티가 만든 AI 스킬을 발견하고 탐색하세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/SAM42-Lab/everything-claude-code-kr --skill rust-testing명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Zip 다운로드 다운로드 중... 이 저장소의 다른 Skills agent-introspection-debugging 캡처, 진단, 억제된 복구 및 인트로스펙션 보고서를 사용하여 AI 에이전트 실패에 대한 구조화된 셀프 디버깅 워크플로우를 수행합니다.
기술, 명령어, 규칙, 훅 및 기타 요소를 DAILY 대 LIBRARY 버킷으로 분류하여 특정 저장소에 대한 증거 기반의 ECC 설치 계획을 수립합니다. 전체 번들을 로드하는 대신 프로젝트에 실제로 필요한 것만 ECC를 트리밍해야 할 때 사용하세요.
리소스 명명, 상태 코드, 페이지네이션, 필터링, 에러 응답, 버전 관리 및 프로덕션 API를 위한 속도 제한을 포함한 REST API 설계 패턴.
name rust-testing description 단위 테스트, 통합 테스트, 비동기 테스트, 속성 기반 테스트, 모킹(mocking) 및 커버리지를 포함한 러스트 테스트 패턴입니다. TDD 방법론을 따릅니다. origin ECC
러스트 테스트 패턴 (Rust Testing Patterns)
TDD 방법론을 따라 신뢰할 수 있고 유지보수가 용이한 테스트를 작성하기 위한 포괄적인 러스트 테스트 패턴입니다.
사용 시점
새로운 러스트 함수, 메서드 또는 트레이트를 작성할 때
기존 코드에 테스트 커버리지를 추가할 때
성능이 중요한 코드에 대한 벤치마크를 생성할 때
입력 유효성 검사를 위한 속성 기반 테스트를 구현할 때
러스트 프로젝트에서 TDD 워크플로우를 따를 때
동작 방식
대상 코드 식별 — 테스트할 함수, 트레이트 또는 모듈을 찾습니다.
테스트 작성 — #[cfg(test)] 모듈 내에서 #[test]를 사용하거나, 파라미터화된 테스트를 위해 rstest를, 속성 기반 테스트를 위해 proptest를 사용합니다.
의존성 모킹 — mockall을 사용하여 테스트 대상을 격리합니다.
테스트 실행 (RED) — 테스트가 예상된 에러와 함께 실패하는지 확인합니다.
구현 (GREEN) — 테스트를 통과시키기 위한 최소한의 코드를 작성합니다.
리팩터링 (REFACTOR) — 테스트 통과를 유지하면서 코드를 개선합니다.
커버리지 확인 — cargo-llvm-cov를 사용하며, 80% 이상을 목표로 합니다.
러스트 TDD 워크플로우
RED-GREEN-REFACTOR 주기
RED → 실패하는 테스트를 먼저 작성
GREEN → 테스트를 통과시키는 최소한의 코드 작성
REFACTOR → 테스트 통과를 유지하며 코드 개선
REPEAT → 다음 요구 사항으로 이동
단계별 러스트 TDD
pub fn (a: , b: ) { todo!() }
tests {
super::*;
() { ( ( , ), ); }
}
add
i32
i32
->
i32
#[cfg(test)]
mod
use
#[test]
fn
test_add
assert_eq!
add
2
3
5
pub fn add (a: i32 , b: i32 ) -> i32 { a + b }
단위 테스트 (Unit Tests)
모듈 레벨 테스트 구성
pub struct User {
pub name: String ,
pub email: String ,
}
impl User {
pub fn new (name: impl Into <String >, email: impl Into <String >) -> Result <Self , String > {
let email = email.into ();
if !email.contains ('@' ) {
return Err (format! ("invalid email: {email}" ));
}
Ok (Self { name: name.into (), email })
}
pub fn display_name (&self ) -> &str {
&self .name
}
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn creates_user_with_valid_email () {
let user = User::new ("Alice" , "alice@example.com" ).unwrap ();
assert_eq! (user.display_name (), "Alice" );
assert_eq! (user.email, "alice@example.com" );
}
#[test]
fn rejects_invalid_email () {
let result = User::new ("Bob" , "not-an-email" );
assert! (result.is_err ());
assert! (result.unwrap_err ().contains ("invalid email" ));
}
}
어설션(Assertion) 매크로 assert_eq! (2 + 2 , 4 );
assert_ne! (2 + 2 , 5 );
assert! (vec! [1 , 2 , 3 ].contains (&2 ));
assert_eq! (value, 42 , "expected 42 but got {value}" );
assert! ((0.1_f64 + 0.2 - 0.3 ).abs () < f64 ::EPSILON);
에러 및 패닉 테스트
Result 반환 테스트 #[test]
fn parse_returns_error_for_invalid_input () {
let result = parse_config ("}{invalid" );
assert! (result.is_err ());
let err = result.unwrap_err ();
assert! (matches!(err, ConfigError::ParseError (_)));
}
#[test]
fn parse_succeeds_for_valid_input () -> Result <(), Box <dyn std::error::Error>> {
let config = parse_config (r#"{"port": 8080}"# )?;
assert_eq! (config.port, 8080 );
Ok (())
}
패닉 테스트 #[test]
#[should_panic]
fn panics_on_empty_input () {
process (&[]);
}
#[test]
#[should_panic(expected = "index out of bounds" )]
fn panics_with_specific_message () {
let v : Vec <i32 > = vec! [];
let _ = v[0 ];
}
통합 테스트 (Integration Tests)
파일 구조 my_crate/
├── src/
│ └── lib.rs
├── tests/ # 통합 테스트 디렉토리
│ ├── api_test.rs # 각 파일은 별도의 테스트 바이너리로 컴파일됨
│ ├── db_test.rs
│ └── common/ # 공유 테스트 유틸리티
│ └── mod.rs
통합 테스트 작성
use my_crate::{App, Config};
#[test]
fn full_request_lifecycle () {
let config = Config::test_default ();
let app = App::new (config);
let response = app.handle_request ("/health" );
assert_eq! (response.status, 200 );
assert_eq! (response.body, "OK" );
}
비동기 테스트 (Async Tests)
Tokio 활용 #[tokio::test]
async fn fetches_data_successfully () {
let client = TestClient::new ().await ;
let result = client.get ("/data" ).await ;
assert! (result.is_ok ());
assert_eq! (result.unwrap ().items.len (), 3 );
}
#[tokio::test]
async fn handles_timeout () {
use std::time::Duration;
let result = tokio::time::timeout (
Duration::from_millis (100 ),
slow_operation (),
).await ;
assert! (result.is_err (), "should have timed out" );
}
테스트 구성 패턴
rstest를 사용한 파라미터화된 테스트 use rstest::{rstest, fixture};
#[rstest]
#[case("hello" , 5)]
#[case("" , 0)]
#[case("rust" , 4)]
fn test_string_length (#[case] input: &str , #[case] expected: usize ) {
assert_eq! (input.len (), expected);
}
#[fixture]
fn test_db () -> TestDb {
TestDb::new_in_memory ()
}
#[rstest]
fn test_insert (test_db: TestDb) {
test_db.insert ("key" , "value" );
assert_eq! (test_db.get ("key" ), Some ("value" .into ()));
}
테스트 헬퍼 (Test Helpers) #[cfg(test)]
mod tests {
use super::*;
fn make_user (name: &str ) -> User {
User::new (name, &format! ("{name}@test.com" )).unwrap ()
}
#[test]
fn user_display () {
let user = make_user ("alice" );
assert_eq! (user.display_name (), "alice" );
}
}
proptest를 사용한 속성 기반 테스트
기본 속성 테스트 use proptest::prelude::*;
proptest! {
#[test]
fn encode_decode_roundtrip (input in ".*" ) {
let encoded = encode (&input);
let decoded = decode (&encoded).unwrap ();
assert_eq! (input, decoded);
}
#[test]
fn sort_preserves_length (mut vec in prop::collection::vec (any::<i32 >(), 0 ..100 )) {
let original_len = vec.len ();
vec.sort ();
assert_eq! (vec.len (), original_len);
}
#[test]
fn sort_produces_ordered_output (mut vec in prop::collection::vec (any::<i32 >(), 0 ..100 )) {
vec.sort ();
for window in vec.windows (2 ) {
assert! (window[0 ] <= window[1 ]);
}
}
}
커스텀 전략 (Custom Strategies) use proptest::prelude::*;
fn valid_email () -> impl Strategy <Value = String > {
("[a-z]{1,10}" , "[a-z]{1,5}" )
.prop_map (|(user, domain)| format! ("{user}@{domain}.com" ))
}
proptest! {
#[test]
fn accepts_valid_emails (email in valid_email ()) {
assert! (User::new ("Test" , &email).is_ok ());
}
}
mockall을 사용한 모킹(Mocking)
트레이트 기반 모킹 use mockall::{automock, predicate::eq};
#[automock]
trait UserRepository {
fn find_by_id (&self , id: u64 ) -> Option <User>;
fn save (&self , user: &User) -> Result <(), StorageError>;
}
#[test]
fn service_returns_user_when_found () {
let mut mock = MockUserRepository::new ();
mock.expect_find_by_id ()
.with (eq (42 ))
.times (1 )
.returning (|_| Some (User { id: 42 , name: "Alice" .into () }));
let service = UserService::new (Box ::new (mock));
let user = service.get_user (42 ).unwrap ();
assert_eq! (user.name, "Alice" );
}
#[test]
fn service_returns_none_when_not_found () {
let mut mock = MockUserRepository::new ();
mock.expect_find_by_id ()
.returning (|_| None );
let service = UserService::new (Box ::new (mock));
assert! (service.get_user (99 ).is_none ());
}
문서 테스트 (Doc Tests)
실행 가능한 문서
pub fn add (a: i32 , b: i32 ) -> i32 {
a + b
}
pub fn parse_config (input: &str ) -> Result <Config, ParseError> {
todo!()
}
Criterion을 사용한 벤치마킹
[dev-dependencies]
criterion = { version = "0.5" , features = ["html_reports" ] }
[[bench]]
name = "benchmark"
harness = false
use criterion::{black_box, criterion_group, criterion_main, Criterion};
fn fibonacci (n: u64 ) -> u64 {
match n {
0 | 1 => n,
_ => fibonacci (n - 1 ) + fibonacci (n - 2 ),
}
}
fn bench_fibonacci (c: &mut Criterion) {
c.bench_function ("fib 20" , |b| b.iter (|| fibonacci (black_box (20 ))));
}
criterion_group!(benches, bench_fibonacci);
criterion_main!(benches);
테스트 커버리지
커버리지 실행
cargo llvm-cov
cargo llvm-cov --html
cargo llvm-cov --lcov > lcov.info
cargo llvm-cov --fail-under-lines 80
커버리지 목표 코드 유형 목표 핵심 비즈니스 로직 100% 공개 API 90% 이상 일반 코드 80% 이상 생성된 코드 / FFI 바인딩 제외
테스트 명령어 cargo test
cargo test -- --nocapture
cargo test test_name
cargo test --lib
cargo test --test api_test
cargo test --doc
cargo test --no-fail-fast
cargo test -- --ignored
모범 사례
테스트를 먼저 작성하세요 (TDD)
단위 테스트에는 #[cfg(test)] 모듈을 사용하세요
구현이 아닌 행동(behavior)을 테스트하세요
시나리오를 설명하는 서술적인 테스트 이름을 사용하세요
더 나은 에러 메시지를 위해 assert!보다 assert_eq!를 선호하세요
Result를 반환하는 테스트에서는 ? 연산자를 사용하여 깔끔하게 작성하세요
테스트 간의 독립성을 유지하세요 (공유 가변 상태 금지)
Result::is_err()를 테스트할 수 있다면 #[should_panic] 사용을 지양하세요
모든 것을 모킹하지 마세요 — 가능한 경우 통합 테스트를 우선하세요
불안정한(flaky) 테스트를 방치하지 마세요 — 수정하거나 격리하세요
테스트에서 sleep()을 사용하지 마세요 — 채널, 배리어(barriers) 또는 tokio::time::pause()를 사용하세요
에러 경로 테스트를 누락하지 마세요
CI 통합
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: dtolnay/rust-toolchain@stable
with:
components: clippy, rustfmt
- name: Check formatting
run: cargo fmt --check
- name: Clippy
run: cargo clippy -- -D warnings
- name: Run tests
run: cargo test
- uses: taiki-e/install-action@cargo-llvm-cov
- name: Coverage
run: cargo llvm-cov --fail-under-lines 80
기억하세요 : 테스트는 곧 문서입니다. 당신의 코드가 어떻게 사용되어야 하는지 보여줍니다. 명확하게 작성하고 항상 최신 상태로 유지하세요.