Node에는 어떤 테스트 프레임워크를 사용할 수 있나요? 다음 기사에서는 몇 가지 Node.js 테스트 프레임워크를 공유할 것입니다. 이것이 도움이 되기를 바랍니다. 
Node.js 빠른 소개 과정: 배우려면 입력하세요.
편집자 주: 이 기사의 저자는 Ant Group의 Node.js 엔지니어인 Tianzhu입니다. 그는 먼저 각 부분에서 일반적으로 사용되는 클래스 라이브러리를 소개하고, 기사 마지막 부분에서 단위 테스트가 필요한지 논의할 것입니다. 함께 논의하기로 했습니다.
mocha와 jest가 일반적으로 사용됩니다. 공식적인 새로운 노드 테스트는 아직 다듬어지고 있으며 미래는 밝습니다.
$mocha 테스트/egg-view-ejs.test.js 세우다 ✓ 현지인과 함께 렌더링해야 합니다. ✓ 캐시로 렌더링해야 함 ✓ 레이아웃으로 렌더링해야 합니다. ✓ 오류를 렌더링해야 합니다 렌더스트링 ✓ 데이터와 함께 String을 렌더링해야 합니다. ✓ renderString 오류가 발생해야 합니다. 6패스(398ms)
Runner가 너무 많지만 출력 기준은 모두 TAP 형식이며 결과는 서로 다른 Reporter를 통해 출력됩니다.
단일 테스트를 작성하는 것만으로는 충분하지 않으며, 코드의 모든 분기 프로세스가 적용되는지 알아야 하므로 일반적으로 코드 적용 도구를 사용해야 합니다.
예전에는 istanbuljs였지만 나중에 저자가 nyc를 다시 작성했습니다. 그들은 주로 두 가지 책임을 집니다: 하나는 코드를 번역하여 파일링 코드를 삽입하는 것이고, 다른 하나는 다양한 리포터가 취재 보고서를 생성하도록 지원하는 것입니다.
나중에 V8 내장 커버리지 통계
즉, 더 이상 코드를 번역할 필요가 없으며, 커버리지 데이터 수집이 기본적으로 지원됩니다.
그런 다음 이 저자는 적용 범위 보고서 생성에 초점을 맞춘 c8을 작성했습니다.
변수 결과를 검증하려면 Assert가 필수입니다.
역사적으로: Expect.js, should.js, chai 및 power-assert, jest에도 자체 내장 기대가 있습니다.
하지만 이제 Node.js 공식 주장/엄격은 실제로 꽤 좋습니다.
그 중 power-assert는 우리 EggJS에서 사용하고 있는 것입니다. 저는 수년 전에 "아마 최고의 JS Assert 라이브러리일 것입니다 - The Emperor's New Clothes"라고 언급했습니다.
const 주장 = require('power-assert');
explain('test/showcase.test.js', () => {
const arr = [1, 2, 3];
it('power-assert', () => {
주장(arr[1] === 10);
});
});
//산출:
4) test/showcase.test.js 전원 어설션:
AssertionError: # test/showcase.test.js:6
주장(arr[1] === 10)
|
2 거짓
[1,2,3]
[번호] 10
=> 10
[번호] arr[1]
=> 2추신: 파일 내용을 확인하고 싶다면 Assert 파일도 작성했으니 사용해 보세요.
단위 테스트이기 때문에 환경이나 다운스트림 응답을 시뮬레이션해야 하는 경우가 많습니다.
sinonjs는 나쁘지 않으며 mock, stub 등을 지원합니다. jest에는 자체 모의 라이브러리도 내장되어 있습니다.
HTTP 테스트인 경우 nock는 매우 강력하며 서버 응답을 모의하는 데 도움이 될 수 있습니다.
노크('http://www.example.com')
.post('/login', '사용자 이름=pgte&비밀번호=123456')
.reply(200, { id: '123ABC' })그러나 Node.js의 공식 undici 요청 라이브러리에도 Mock 기능이 내장되어 있습니다.
스냅샷이라는 용어도 있는데, 이는 동작 중에 데이터를 덤프하고 다음 테스트의 모의 데이터로 직접 사용한다는 의미로, 테스트 작성의 효율성을 어느 정도 향상시킬 수 있습니다.
HTTP 서버 시나리오를 테스트하려면 슈퍼테스트 라이브러리가 필수입니다.
explain('GET /users', function() {
it('json으로 응답', async function() {
반품요청(앱)
.get('/사용자')
.set('수락', '응용 프로그램/json')
.expect('콘텐츠 유형', /json/)
.기대하다(200)
.then(응답 => {
주장(response.body.email, '[email protected]');
});
});
});Node.js의 주요 사용 시나리오 중 하나는 Webpack 및 Babel과 같은 명령줄 CLI이며, 자체적으로 단위 테스트도 필요합니다.
이것이 우리가 권장하는 것입니다:
GitHub - node-modules/clet: 명령줄 E2E 테스트
GitHub - node-modules/coffee: Node.js에서 명령줄 테스트
'clet'에서 { 러너, KEYS } 가져오기;
it('보일러플레이트와 함께 작동해야 함', async () => { wait runer() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // stdout을 기다린 후 응답합니다. .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // stdout 유효성 검사 .notStderr(/ npm ERR/) .file('package.json', { name: 'example', version: '1.0.0' }) // 파일 유효성 검사 });
가벼운 페이지 크롤링의 경우 HTTP를 사용하여 직접 라이브러리를 요청할 수 있습니다.
브라우저의 실제 실행을 시뮬레이션하기 위해 초기에는 Selenium과 phantomjs를 사용했습니다.
그런 다음 Google은 Chromium의 축적과 devtools 프로토콜 프로토콜을 기반으로 공식적으로 puppeteer를 출시했으며 빠르게 인기를 얻었고 처음 두 가지를 죽였습니다. 유사한 경쟁 제품으로는 극작가와 사이프러스가 있습니다.
그건 그렇고, 다중 터미널 테스트 도구인 macacajs를 다운로드할 예정입니다. 브라우저 외에도 모바일 앱과 데스크톱 앱의 테스트도 지원합니다. 이는 Yuque 팀의 엔지니어가 오픈 소스로 제공합니다.
오픈 소스를 작성할 때 테스트를 돕기 위해 자동화된 지속적 통합 서비스가 필요한 경우가 많습니다.
이 분야의 플레이어로는 Travis, Appveyor, GitHub Actions 등이 있습니다.
이제는 기본적으로 GitHub Actions를 사용하는데 통합 수준이 너무 멋집니다.
단위 테스트가 매우 중요하다는 것은 의심의 여지가 없습니다. 자격을 갖춘 프로그래머에게 필요한 능력이자 전문적인 자질입니다.
물론 우리는 100% 커버리지 매니아는 아니지만 많은 경우 ROI의 균형점을 추구해야 합니다.
우선, 일반적인 신입생의 관점을 바로잡겠습니다. 단위 테스트 작성은 시간 낭비입니까?
실제로 단위 테스트를 작성하면 시간이 절약됩니다. 이렇게 반직관적인 관점을 갖는 이유는 비교 조건이 객관적이지 않은 경우가 많기 때문입니다. 동일한 품질 요구 사항에서 코드를 두 번 수정한 후 회귀 비용을 고려해야 합니다.
공정한 비교를 위해 "단일 테스트 작성 시간"을 고려하는 것 외에도 쉽게 간과되는 것은 "각 코드 수정 후 회귀 테스트를 수행하는 시간"입니다.
단일 테스트를 작성할 때 초기 단계에서 다양한 브랜치 모의를 생성하고 회귀 테스트를 위한 시간은 키보드를 두드리는 것뿐입니다.
단일 테스트를 작성하지 않고 애플리케이션에 코드를 업데이트한 다음 브라우저를 열고 다양한 위치를 클릭하는 등 테스트할 다양한 상황을 수동으로 시뮬레이션해야 합니다.
이 두 가지 작업에 얼마나 시간이 걸리는지 한 눈에 알 수 있습니다.
초기 투자 + 유지 비용 + 반품 품질 강조에 지나지 않습니다. 회사마다 저울질해서 결정하는 기준이 있습니다.
물론 제가 언급한 시나리오 중 다수는 프레임워크 라이브러리(프런트엔드 및 Node.js 포함), 서버측 애플리케이션, 명령줄 도구 등 입니다 . UI 표시 또는 빠른 로딩 및 언로딩은 활동 페이지의 경우 해당 단일 테스트 유지 관리 비용이 실제로 매우 높습니다. 이때 ROI를 기반으로 일부 비핵심 분기의 단일 테스트를 적절하게 포기하는 것이 합리적입니다.
하지만 이것이 최후의 수단이라는 점을 이해해야 합니다. 다양한 수단을 통해 단위 테스트의 유지 비용을 줄일 수 있지만 단위 테스트가 쓸모없다고 주장할 수는 없습니다.
프런트 엔드 필드에는 diff를 기반으로 비교를 자동화한 다음 소유자에게 변경 사항의 영향에 주의를 기울이도록 상기시키는 반자동 회귀 테스트도 있습니다. 이는 단일 테스트 작성 비용을 줄이는 데 도움이 되는 위의 도구 라이브러리와 같습니다.
이것도 잘못된 관점입니다. 단위 테스트는 프로그래머가 직접 작성해야 하고 , 자신이 책임져야 하는 일종의 전문성입니다. 약간의 표준화가 이루어진 팀은 코드를 제출할 때 CI 테스트가 필요합니다. 그렇지 않으면 품질이 뛰어난 코드 검토 협업이 이루어지지 않습니다.
테스트 학생은 통합 테스트, 회귀 테스트, 엔드투엔드 테스트 등 더 큰 수준의 작업을 담당합니다 .
분업이 다르기 때문에 남을 비난하지 마세요.
단위 테스트는 매우 필요합니다. 단위 테스트를 작성하는 것은 프로그래머의 기본 전문 품질입니다. 개별 시나리오에서는 ROI를 기반으로 선택할 수 있습니다.