web3-testing

web3-testing 스킬 개요

web3-testing가 하는 일

web3-testing 스킬은 에이전트가 Hardhat과 Foundry를 활용해 스마트 컨트랙트 테스트 워크플로를 설계하고 초안을 빠르게 잡도록 돕습니다. 단순히 “Solidity 테스트 좀 작성해줘” 수준의 범용 프롬프트로는 부족한 팀을 위한 도구로, 단위 테스트, 통합 테스트 커버리지, 메인넷 포킹, 퍼징, 가스 체크, 검증 관련 설정까지 실제로 필요한 범위를 함께 다룹니다.

web3-testing를 써야 하는 사람

이 web3-testing 스킬은 특히 다음과 같은 사용자에게 잘 맞습니다:

• 테스트 스위트를 처음 만들거나 고도화하려는 Solidity 개발자
• Web3 영역으로 확장하려는 QA 및 테스트 자동화 엔지니어
• 포크 기반의 현실적인 검증이 필요한 DeFi 팀
• 구조화된 테스트 아이디어를 빠르게 얻고 싶은 감사인 또는 프로토콜 엔지니어

반대로, 단순한 일회성 유닛 테스트 하나만 필요하거나 스택이 Hardhat이나 Foundry를 쓰지 않는다면 활용도가 낮습니다.

실제로 해결하는 일

대부분의 사용자는 이론을 원하지 않습니다. “컨트랙트와 리스크 포인트는 있는데”에서 “실행 가능한 테스트 계획과 시작용 테스트 코드가 있다”까지 빠르게 가고 싶어 합니다. web3-testing의 가치는 대화를 구체적인 테스트 설계와 고급 패턴 쪽으로 밀어준다는 데 있습니다. 특히 일반적인 프롬프트가 자주 놓치는 포크된 상태, 퍼징, 가스 리포팅, 다층 테스트 전략을 챙겨준다는 점이 강점입니다.

이 스킬을 차별화하는 점

일반적인 코딩 프롬프트와 비교하면, web3-testing는 다음 영역에서 더 강한 가이드를 제공합니다:

• Hardhat과 Foundry 워크플로 중 무엇을 선택할지 판단
• 현실적인 네트워크 및 환경 설정 구성
• 스마트 컨트랙트에서 자주 문제 되는 엣지 케이스 커버
• 포크된 체인 상태를 바탕으로 한 프로토콜 동작 검증
• 커버리지, 가스 리포팅 같은 품질 신호 추가

설치 전에 알아둘 점

이 저장소에서 확인되는 신호는 좁지만 실용적입니다. 이 스킬은 스크립트나 레퍼런스가 풍부한 대형 툴킷이라기보다, 사실상 SKILL.md 중심의 단일 플레이북에 가깝습니다. 도입은 쉽지만, 자동화 도구보다는 가이드와 예시를 기대하는 편이 맞습니다. 즉시 가져다 쓸 수 있는 헬퍼가 포함된 강제력 있는 테스트 프레임워크를 찾는다면, 이 스킬은 드롭인 패키지보다는 사고 정리와 테스트 초안 설계에 더 가까운 성격입니다.

web3-testing 스킬 사용 방법

web3-testing 설치 맥락

상위 저장소에서 다음 명령으로 스킬을 설치합니다:

npx skills add https://github.com/wshobson/agents --skill web3-testing

저장소 경로가 plugins/blockchain-web3/skills/web3-testing인 만큼, 설치되는 것은 독립형 npm 테스트 라이브러리가 아니라 특정 목적에 맞춘 스킬 문서입니다.

먼저 읽어야 할 파일

가장 먼저 볼 파일은 다음입니다:

• SKILL.md

실질적인 기준 문서는 이것입니다. 스킬 디렉터리 안에 의미 있는 보조 폴더가 따로 있는 구조는 아니므로, 다른 곳에 숨겨진 헬퍼가 있을 것이라고 기대하지 않는 편이 좋습니다.

스킬이 사용자에게 필요한 입력

web3-testing 스킬은 다음 정보를 줄 때 가장 좋은 결과를 냅니다:

• 컨트랙트의 목적
• 핵심 함수와 접근 제어 구조
• 불변조건 또는 안전 속성
• 선호하는 툴체인: Hardhat, Foundry, 또는 둘 다
• 오라클, 풀, 토큰, 프록시 컨트랙트 같은 외부 의존성
• 단위 테스트, 통합 테스트, 포크 테스트, 퍼징, 가스 체크 중 무엇이 필요한지

약한 입력 예:
“Write tests for my contract.”

강한 입력 예:
“Using Foundry, create unit and fuzz tests for an ERC20 staking contract with reward accrual, admin-only parameter updates, pause behavior, and emergency withdrawal. Include revert-path coverage and invariants around total staked balances.”

막연한 목표를 바로 쓸 수 있는 프롬프트로 바꾸기

좋은 web3-testing usage 프롬프트는 보통 네 가지 요소를 담습니다:

1. 스택
2. 컨트랙트 표면
3. 리스크 영역
4. 원하는 출력 형식

예시:

“Use the web3-testing skill to propose a test plan and starter files for a Hardhat project. Contract set: Vault.sol, Strategy.sol, OracleAdapter.sol. Focus on deposit/withdraw accounting, role restrictions, stale oracle handling, slippage boundaries, and upgrade safety. Include unit tests, one mainnet fork scenario, and gas reporter setup.”

이런 식의 요청은 단순히 “comprehensive tests”를 요구하는 것보다 훨씬 낫습니다. 여기서의 “포괄적”이 무엇을 뜻하는지 에이전트가 구체적으로 이해할 수 있기 때문입니다.

Hardhat와 Foundry는 의도적으로 선택하기

원문 가이드는 두 프레임워크를 모두 다루므로, 프롬프트에서도 어느 쪽에 최적화할지 분명히 적는 것이 좋습니다.

다음이 필요하면 Hardhat를 쓰세요:

• JavaScript 또는 TypeScript 기반 테스트 흐름
• 플러그인 중심 워크플로
• 익숙한 Node 환경에서의 커버리지 및 가스 리포터 설정
• 더 넓은 애플리케이션 툴링과의 쉬운 통합

다음이 필요하면 Foundry가 더 적합합니다:

• 더 빠른 Solidity 네이티브 테스트
• 퍼징 및 invariant 중심 워크플로
• 스마트 컨트랙트에 집중된 더 짧고 촘촘한 개발 루프

팀이 둘 다 사용한다면, 섞어서 얼버무리기보다 역할을 나눠서 설계해 달라고 명시하세요.

테스트 자동화를 위한 web3-testing 최적 워크플로

web3-testing for Test Automation 관점에서 가장 강한 워크플로는 다음 순서입니다:

1. 먼저 테스트 매트릭스를 요청
2. 빠진 실패 케이스를 검토
3. 설정 파일과 구성 파일 생성을 요청
4. 시작용 테스트 코드를 생성
5. 실제 컨트랙트 코드와 ABI 세부 정보로 보정
6. 마지막에 포크와 퍼징 레이어를 추가

이 순서를 따르면, 실행은 될 것처럼 보이지만 실제 프로토콜 리스크는 반영하지 못하는 테스트가 먼저 생성되는 흔한 실패를 줄일 수 있습니다.

이 스킬이 특히 잘 만들어내는 결과물

실무에서 web3-testing가 특히 유용한 산출물은 다음과 같습니다:

• 초기 hardhat.config.js 테스트 설정
• 테스트 카테고리 분해
• 표준 동작에 대한 시작용 단위 테스트
• DeFi 통합을 위한 포크 테스트 아이디어
• 퍼징 대상과 엣지 케이스 목록
• 가스 리포팅과 커버리지 제안

즉, 구조화된 테스트 가이드이자 코드 스캐폴드 생성기로 쓸 때 가장 강합니다.

좋은 결과를 가장 자주 막는 것

가장 큰 장애물은 설치 문제가 아니라 프로토콜 맥락 부족입니다:

• 컨트랙트 코드나 함수 목록이 없음
• 핵심 불변조건에 대한 설명이 없음
• 외부 통합 구조 설명이 없음
• 우선순위 없이 “full coverage”만 요구함
• 하나의 모호한 요청 안에서 프레임워크 가정이 뒤섞임

이런 정보가 빠지면, 결과물은 프로토콜 맞춤형 테스트 자동화가 아니라 범용 ERC20 스타일의 테스트 조언으로 흐르기 쉽습니다.

출력 품질을 높이는 실전 프롬프트 패턴

가능하면 아래 구조를 그대로 쓰는 것이 좋습니다:

• Repository context: framework, Solidity version, proxy pattern, package manager
• Contracts in scope: filenames and responsibilities
• Critical behaviors: deposits, liquidations, claims, rebase logic, governance
• Failure conditions: unauthorized access, rounding, reentrancy assumptions, stale data
• Desired artifacts: config, test plan, test file skeletons, mock strategy, fork scenario
• Constraints: keep tests deterministic, avoid external API reliance, target CI runtime under X minutes

이 형식이면 web3-testing guide가 팀에서 곧바로 가져다 수정할 수 있는 수준의 출력을 내기에 충분한 정밀도를 확보할 수 있습니다.

포크 테스트는 현실성이 중요한 곳에만 쓰기

이 스킬은 메인넷 포킹을 차별점으로 내세우지만, 모든 프로젝트에 필요한 것은 아닙니다. 다음 조건이라면 포크 테스트를 쓰는 편이 좋습니다:

• 실제 프로토콜 상태에 따라 동작이 달라짐
• DEX, 대출 시장, 가격 피드와의 통합이 중요함
• 목(mock)으로는 위험한 엣지 케이스가 가려질 수 있음

반대로 다음 조건이라면 포크 테스트를 생략하거나 최소화하는 편이 낫습니다:

• 현실성보다 CI 속도가 더 중요함
• 컨트랙트가 대부분 독립적인 비즈니스 로직임
• 생태계 시뮬레이션보다 재현 가능성이 더 중요함

생성된 결과물은 도입 전에 반드시 검증하기

web3-testing skill로 만든 내용을 머지하기 전에 다음을 확인하세요:

• revert 이유와 접근 제어 가정이 맞는가?
• 토큰 소수점과 반올림 가정이 실제와 일치하는가?
• 포크 블록 번호가 시나리오에 맞는가?
• 가스 및 커버리지 플러그인이 현재 스택과 호환되는가?
• 테스트가 불변조건을 증명하는가, 아니면 정상 경로만 확인하는가?

이 스킬은 시간을 아껴주지만, 프로토콜별 정확성은 결국 팀의 리뷰에 달려 있습니다.

web3-testing 스킬 FAQ

web3-testing는 입문자에게도 좋은가

기본적인 Solidity 개념을 이미 이해하고 있다면 그렇습니다. 이 스킬은 초기 설정을 빠르게 하고, 성숙한 테스트 스택이 어떤 모습인지 보여주는 데 도움이 됩니다. 다만 완전 초보자라면 Solidity 문법, 배포 흐름, 프레임워크 기초는 별도의 도움을 함께 받아야 할 수 있습니다.

web3-testing는 Hardhat 전용인가

아닙니다. 이 스킬은 Hardhat과 Foundry를 모두 명시적으로 다룹니다. 다만 어떤 생태계를 우선할지 사용자가 분명히 말해줄 때 가장 잘 맞습니다. 모호하게 두면 결과도 흐려지기 쉽습니다.

web3-testing는 일반적인 AI 프롬프트와 어떻게 다른가

일반 프롬프트는 표면적인 유닛 테스트를 반환하는 경우가 많습니다. 반면 web3-testing는 스마트 컨트랙트 테스트 전략 전체에 더 잘 맞춰져 있습니다. 포크 기반의 현실성, 퍼징, 가스 체크, 커버리지, 환경 설정까지 함께 다루므로, 데모용 테스트가 아니라 실제 프로토콜 검증에 더 유용합니다.

web3-testing는 DeFi 프로토콜에도 도움이 되나

그렇습니다. 특히 현실적인 상태를 바탕으로 통합 테스트가 필요할 때 잘 맞는 활용 사례입니다. 프로토콜 의존성, 기대하는 불변조건, 중요하게 보는 사용자 플로를 구체적으로 제공하면 결과 품질이 크게 좋아집니다.

언제 web3-testing를 쓰지 말아야 하나

다음과 같은 경우에는 web3-testing를 굳이 꺼낼 필요가 없습니다:

• 일회성 assertion 하나만 필요할 때
• 프로젝트가 Solidity 또는 EVM 중심이 아닐 때
• 헬퍼와 fixture가 포함된 패키지형 프레임워크를 원할 때
• 의미 있는 테스트 목표를 지정할 만큼의 컨트랙트 맥락이 없을 때

web3-testing에는 실행 가능한 툴링이 포함되어 있나

크게 그렇지는 않습니다. 저장소 기준으로 보면, 이 스킬은 번들 스크립트나 재사용 가능한 자산보다 문서 중심의 예시형 스킬에 가깝습니다. 설치형 테스트 프레임워크라기보다 가이드와 생성 보조 도구로 보는 편이 정확합니다.

web3-testing 스킬을 더 잘 활용하는 방법

파일명보다 프로토콜 리스크를 먼저 주기

web3-testing usage 결과를 가장 빨리 개선하는 방법은, 실제로 우려하는 실패 모드를 먼저 명시하는 것입니다:

• accounting drift
• price manipulation
• permission bypass
• bad upgrade initialization
• insolvency after extreme inputs

이렇게 하면 출력이 범용 스캐폴딩에서 끝나지 않고, 리스크 중심의 테스트 설계로 바뀝니다.

코드보다 먼저 테스트 매트릭스를 요청하기

효율이 높은 패턴은 다음과 같습니다:

1. “List test categories and invariants.”
2. “Now generate the highest-priority test skeletons.”
3. “Now fill in mocks and edge cases.”

이 방식은 불필요한 코드 생성을 줄이고, 오해가 있는 지점을 초반에 드러내는 데 유리합니다.

실제 컨트랙트 인터페이스 제공하기

함수 시그니처, 이벤트, custom error, 스토리지 제약을 붙여주면 web3-testing skill은 훨씬 더 강한 테스트를 생성할 수 있습니다. 이런 정보가 없으면, 설정 세부 사항을 임의로 만들어내거나 지나치게 넓은 가정에 기대게 될 수 있습니다.

정상 경로와 공격적 경로를 분리하기

출력을 다음 구조로 나눠 달라고 요청하세요:

• happy-path functionality
• authorization checks
• boundary and rounding cases
• integration failures
• fork-specific scenarios
• fuzz or invariant candidates

이 구조는 리뷰를 더 쉽게 만들고, CI 계획을 세우는 데도 도움이 됩니다.

정확한 상태 가정으로 메인넷 포크 프롬프트 개선하기

더 나은 포크 테스트 출력을 원한다면 다음 정보를 포함하세요:

• network name
• RPC environment variable name
• target block number
• contracts to impersonate or interact with
• balances or approvals needed
• expected post-transaction state

이 정보가 빠지면 포크 관련 제안은 개념 수준에 머물고, 이후 수작업 정리가 많이 필요해집니다.

자주 발생하는 실패 패턴 주의하기

web3-testing 출력이 어긋나는 대표적인 방식은 다음과 같습니다:

• 중요한 통합 동작을 비현실적인 mock이 대체함
• 겉으로는 넓어 보이지만 실제 가치가 걸린 경로를 놓치는 테스트 커버리지
• 기존 저장소와 충돌하는 프레임워크 설정
• 단위 테스트가 더 빠르고 명확한 곳에 포크 테스트를 남용함
• 불변조건을 충분히 정의하지 않은 채 설정 작업에 과도하게 집중함

생성된 결과물은 문법적 정합성만이 아니라, 실제 리스크를 얼마나 커버하는지 기준으로 검토해야 합니다.

처음 결과를 버리지 말고 반복 개선하기

초기 결과가 대체로 맞지만 부족하다면, 처음부터 다시 시작하기보다 아래처럼 수정 지시를 주는 편이 보통 더 좋습니다:

• “Add revert-path tests for every admin function.”
• “Convert these integration cases into Foundry fuzz tests.”
• “Replace mocks with a fork-based scenario for the oracle dependency.”
• “Prioritize accounting invariants over boilerplate deployment tests.”

대개 이런 방식이 첫 출력을 버리고 새 프롬프트를 처음부터 쓰는 것보다 더 나은 결과를 냅니다.

저장소 맥락을 주면 web3-testing가 훨씬 좋아진다

다음 정보를 함께 주면 이 스킬의 실용성이 크게 올라갑니다:

• 현재 repo 구조
• 기존 fixture 또는 helper library
• CI 시간 제한
• 이미 forge-std, hardhat-toolbox, 또는 커스텀 배포 스크립트를 쓰는지 여부
• 테스트와 fixture의 네이밍 규칙

이렇게 해야 에이전트가 고립된 예시를 생성하는 대신, 실제 저장소에 맞는 형태로 출력을 조정할 수 있습니다.

좋은 web3-testing 출력의 기준

좋은 web3-testing 결과물은 다음을 제공해야 합니다:

• 프로토콜 리스크와 연결된 명확한 테스트 계획
• 현재 스택에 맞는 프레임워크별 설정
• 실제 함수와 불변조건에 대응하는 테스트 스켈레톤
• 가치가 있는 곳에만 선택적으로 적용된 포크 및 퍼징 테스트
• 생성된 코드를 유지보수 가능한 테스트 스위트로 발전시키기 위한 분명한 다음 단계

만약 출력이 의사결정의 질을 높이지도, 구현 시간을 줄여주지도 못한다면, “더 포괄적으로”를 요구하기보다 입력 조건을 더 구체화하는 쪽이 낫습니다.