모듈/테스트

쥬·2023년 4월 21일

모듈 (Module)이란 무엇인가요? Node.js에서 모듈을 사용하는 방법은 무엇인가요?

개발하는 애플리케이션의 크기가 커지면 언젠간 파일을 여러 개로 분리해야 하는 시점이 옵니다. 이때 분리된 파일 각각을 '모듈(module)'이라고 부르는데, 모듈은 대개 클래스 하나 혹은 특정한 목적을 가진 복수의 함수로 구성된 라이브러리 하나로 구성됩니다.

자바스크립트가 만들어진 지 얼마 안 되었을 때는 자바스크립트로 만든 스크립트의 크기도 작고 기능도 단순했기 때문에 자바스크립트는 긴 세월 동안 모듈 관련 표준 문법 없이 성장할 수 있었습니다.

그런데 스크립트의 크기가 점차 커지고 기능도 복잡해지자 자바스크립트 커뮤니티는 특별한 라이브러리를 만들어 필요한 모듈을 언제든지 불러올 수 있게 해준다거나 코드를 모듈 단위로 구성해 주는 방법을 만드는 등 다양한 시도를 하게 됩니다.

AMD – 가장 오래된 모듈 시스템 중 하나로 require.js라는 라이브러리를 통해 처음 개발되었습니다.
CommonJS – Node.js 서버를 위해 만들어진 모듈 시스템입니다.
UMD – AMD와 CommonJS와 같은 다양한 모듈 시스템을 함께 사용하기 위해 만들어졌습니다.

모듈 시스템은 2015년에 표준으로 등재되었습니다. 이 이후로 관련 문법은 진화를 거듭해 이제는 대부분의 주요 브라우저와 Node.js가 모듈 시스템을 지원하고 있습니다.

module 종류

Node.js에서 module은 ‘필요한 함수들의 집합’을 의미합니다.

module은 크게 3가지로 분류할 수 있습니다.

core module(built-in module, 내장 모듈)
local module(사용자 정의 모듈)
제3자 라이브러리 모듈(외장 모듈)

core module

core module(built-in module)은 Node.js에서 기본적으로 제공하는(내제되어 있는) 모듈을 의미합니다.

Node.js에서 기본적으로 제공하는 모듈은 http, os 등 굉장히 다양합니다.

모듈을 사용하는 방법

const test_module = require(“module_name”)

require() 함수는 모듈을 import 할 때 사용하는 함수로 자바스크립트 파일을 읽고 그 파일을 실행시켜 객체를 반환합니다.

local module

Node.js에서 제공하는 core module 외에 자신이 직접 모듈을 만들어서 애플리케이션에 포함시킬 수도 있습니다.

모듈을 직접 생성할 땐 export 키워드를 사용합니다.

외장 모듈

제3자에 의해 제공된 라이브러리에 포함된 모듈

모듈을 사용하는 방법

// 기본으로 내보내기
export default function myDate() {
  return Date();
}
// 기본으로 내보냈기 때문에 바로 사용할 수 있습니다
const test = require(“myModule”);
test();
// 목록으로 내보내기
export { myDate, sample1, sample2, … };
// destructuring을 사용해 필요한 부분만 가져와서 사용할 수 있습니다.
const samples = require(“myModule”);
samples.myDate();
또는
const { myDate, sample1 } = require(“myModule”);
myDate();
// 내보내면서 이름 바꾸기
export { myDate as myFirstDate };
const test = require(“myModule”);
test.myFirstDate();

추가

2015년 자바스크립트에 import/export라는 모듈 개념이 도입되었지만, 브라우저에는 구현되지 않아서 사용할 수 없었다.
크롬 60 버전부터 브라우저에서 모듈을 사용할 수 있게 되었다.

ES6(ES2015)가 도입되면서 자바스크립트도 자체 모듈 시스템 문법이 생겼다. 노드 9 버전부터 사용할 수 있다.
require 대신 import / module.exports 대신 export default 를 사용한다.
하지만, 파일 확장자를 mjs로 지정해야하는 제한이 있다.
js 확장자 파일에서 사용하려면, package.json 에 type: 'module' 속성을 넣으면 된다.

테스트 (Testing)에 대해 어떤 것을 알고 있나요?

테스트의 원리

테스팅은 결함이 존재함을 밝히는 것
완벽한 테스팅은 불가능
개발초기에 테스팅 시작
결함집중 – 적은 수의 모듈에서 대다수의 결함이 발견됨(파레토 법칙)
살충제 패러독스 – 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함
테스팅은 정황에 의존적 – SW성격에 맞게 테스트 실시
오류-부재의 궤변 – 요구사항을 충족시키지 못한다면, 결함이 없다고 해도 품질이 높다고 볼 수 없음

프로그램 실행 여부에 따른 분류

정적 테스트
테스트 대상을 실행하지 않고 구조를 분석하여 논리성을 검증하는 테스트
동적 테스트
소프트웨어를 실행하는 방식으로 테스트를 수행하여 결함을 검출하는 테스트

테스트 기법에 따른 분류

화이트박스 테스트
각 응용 프로그램의 내부 구조와 동작을 검사하는 SW테스트
화이트박스테스트 = 구조(코드) 기반테스트 = 로직 기반 테스트 = 글래스 박스 테스트
블랙박스 테스트
프로그램 외부 사용자의 요구사항 명세를 보면서 수행

테스트 목적에 따른 분류

회복 테스트
시스템에 고의로 실패를 유도하고, 시스템의 정상적 복귀 여부를 테스트하는 기법
안전 테스트
불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스 코드 내의 보안적인 결함을 미리 점검하는 테스트 기법
성능 테스트
사용자의 이벤트에 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 사용자 요구에 시스템이 반응하는 속도 등을 측정하는 테스트 기법

성능 테스트의 상세 유형
1. 부하 테스트
시스템에 부하를 계속 증가시키면서 시스템의 임계점을 찾는 테스트
2. 스트레스 테스트
임계점 이상의 부하를 가하여 비정상적인 상황에서의 처리를 테스트
3. 스파이크 테스트
짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정 테스트
4. 내구성 테스트
오랜 시간 동안 시스템에 높은 부하를 가하여 시스템 반응 테스트

구조 테스트
시스템의 내부 논리 경로, 소스 코드의 복잡도를 평가하는 테스트 기법
회귀 테스트
오류를 제거하거나 수정한 시스템에서 오류 제거와 수정에 의해 새로이 유입된 오류가 없는지 확인하는 일종의 반복 테스트 기법
병행 테스트
변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트 기법

테스트 종류에 따른 분류

명세 기반 테스트(블랙박스 테스트)
프로그램의 요구사항 명세서를 기반으로 테스트 케이스를 선정하여 테스트하는 기법
구조 기반 테스트(화이트박스 테스트)
소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트 기법
경험 기반 테스트(블랙박스 테스트)
유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로 한, 직관과 기술 능력을 기반으로 수행하는 테스트 기법.

테스트 레벨

단위 테스트
사용자 요구사항에 대한 단위 모듈, 서브루틴 등을 테스트하는 단계
자료 구조 테스트, 실행 경로 테스트, 오류 처리 테스트, 인터페이스 테스트
통합 테스트
단위 테스트를 통과한 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호작용을 검증하는 테스트 단계
빅뱅 테스트, 상향식 · 하향식 테스트, 샌드위치 테스트
시스템 테스트
통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지를 검증하는 테스트 단계
기능 · 비기능 요구사항 테스트
인수 테스트
계약상의 요구사항이 만족되었는지 확인하기 위한 테스트 단계
- 알파 · 베타 테스트
  알파 테스트 - 선택된 사용자가 개발자 환경에서 통제된 상태로 개발자와 함께 수행하는 인수 테스트
  베타 테스트 - 실제 환경에서 일정 수의 사용자에게 대상 소프트웨어를 사용하게 하고 피드백을 받는 인수 테스트

추가 - 심화

테스트의 종류는 다양하지만 가장 유명한 것은 아래 세가지이다.

단위 테스트 (Unit Test)
통합 테스트 (Integration Test)
E2E 테스트(End-to-End Test) / UI 테스트

Google Test Automation Conference에서 제안된 Testing pyramid에 따르면 전체 테스트의 비율은 E2E Test 10%, Intergration Test 20%, Unit Test 70%를 유지하는 것이 이상적이라고 한다.

추가로 다른 6가지 테스트에 대해 자료를 찾아봤으며, 9가지 외에도 보안 테스트 퍼포먼스 테스트 등이 있다고 한다.

1. 단위 테스트 (Unit Test)

테스트 가능한 가장 작은 단위의 모듈을 실행하여 올바른 결과물이 출력되는 지 확인하는 테스트이다. 일반적으로 클래스 또는 메서드 단위로 실행하며 단위가 작을수록 복잡성이 낮아진다. 자신이 작성한 코드에 대해 테스트 코드를 작성하며 구현된 코드의 내용을 알고 있어야 하는 화이트 박스 테스트이다.

단위 테스트의 중요성

적은 비용

가장 큰 이유는 테스팅에 소요되는 비용을 들 수가 있다.

통합 테스트, E2E테스트 같은 경우 테스트를 위해 다른 시스템과 반드시 결합되어야 한다. 결합되어야하는 요소들이 많을 수록 테스트 환경을 준비하는데에만 소요되는 시간이 꽤 오래 걸릴 것이다. 하지만 단위 테스트는 필요 모듈만 부분적이고 독립적으로 테스트를 실행하여 빠른 테스트가 가능하며 다른 테스트에 비해 실행 속도 자체도 빠르기 때문에 잦은 수정과 배포가 가능하다.

유지보수의 용이함

잘 작성된 테스트 코드는 중장기적으로 유지보수를 용이하게 해준다. 이전에 통과된 단위 테스트를 반복 실행하여 버그를 찾는 regression 테스트를 할 수 있으며 리팩토링시에도 테스트 코드까지 수정하는 것이 아니라 이전 테스트를 실행하며 테스트를 통과하는지 확인해주기만 하면 된다.

또한 high-level 테스트에서 버그가 발생했다는 것은 코드 상에 문제가 있다는 것외에도 단위 테스트의 부재 또는 테스트가 잘못 작성되었음을 의미한다. 따라서 올바른 단위 테스트를 작성하고 반복 실행하므로써 버그를 최소화하는 것이 좋다.

2. 통합 테스트 (Integration Test)

단위 테스트보다 더 큰 단위의 동작을 확인하기 위한 테스트로, 최소 두 개 이상의 서브 시스템을 결합하여 테스트하는 것을 말한다.

postman이나 httpie를 이용하여 장고 서버와 DB서버가 정상적으로 통신하고 올바른 결과물을 출력하는지 확인하는 것을 예로 들 수 있다.

단위 테스트보다 더 많은 코드를 실행하기 때문에 에러가 어디서 발생했는지 파악하거나 수정하는 것이 비교적 어렵다.

3. E2E 테스트(End-to-End Test) / UI 테스트

결과물을 사용자 시점으로 시나리오에 맞춰 테스트하고 예상되는 결과가 나오는지 확인하는 테스트이다. 가령 상품 조회 페이지로 들어가서 원하는 데이터 값이 나오는지 또는 회원 가입이 정상적으로 동작하는지 등을 확인하는 것이다. 백엔드 관점에서는 실제 서버에 요청을 보내고 클라이언트로 원하는 데이터가 보내졌는지 확인한다.

테스트 중 가장 까다롭고 비용이 많이 드는 테스트이다.

4. 인수 테스트(Acceptance Test)

인수 테스트는 사용자 스토리(시나리오)에 맞춰 수행하는 테스트이다.

인수 테스트는 소프트웨어 인수를 목적으로 하는 테스트이다. 소프트웨어를 인수하기 전에 명세한 요구사항(인수 조건)대로 잘 작동하는지 검증이 필요하다.

인수 테스트는 애자일 개발 방법론에서 파생했다. 특히, 익스트림 프로그래밍(XP)에서 사용하는 용어이다. 이는 시나리오가 정상적으로 동작하는지를 테스트하기 때문에 통합 테스트와는 분류가 다르다. 시나리오에서 요구하는 것은 누가, 어떤 목적으로, 무엇을 하는가이다. 개발을 하다 보면 이런 기능은 API를 통해 드러난다. 인수 테스트는 주로 이 API를 확인하는 방식으로 이뤄진다.

소프트웨어를 인수할 때, 소프트웨어 내부 구조나 구현 방법을 고려하기보다는 실제 사용자 관점에서 테스트하는 경우가 많다. 따라서, 인수 테스트는 소프트웨어 내부 코드에 관심을 가지지 않는 블랙박스 테스트이다. 실제 사용자 관점에서 테스트할 때 주로 E2E(End-to-End) 형식을 이용해서 확인한다.

5. 부하 테스트 (Load Test)

애플리케이션의 성능과 안정성을 확인하기 위해 동시 사용자나 동시 요청이 많은 시나리오를 모방하는 테스트이다.
도구로는 JMeter, Artillery 등이 있다.

6. 스트레스 테스트 (Stress Test)

시스템의 한계를 확인하기 위해 극한의 부하를 가하는 테스트이다. 잠재적인 문제를 파악하는데 도움이 된다.
부하 테스트와 마찬가지로 JMeter, Artillery 등의 도구를 사용할 수 있다.

7. 스모크 테스트 (Smoke Test)

전자 회로 기판에 전원을 넣었을 때 기판에서 연기가 나는지 확인하는 테스트에서 유래
다른 말로는 BVT (Build Verification Testing)라고 부르기도 한다.

테스트에 앞서서 프로그램의 중요한 기능이 잘 작동하는지 확인하기 위해 소프트웨어 빌드 후에 수행되는 소프트웨어 테스팅이다.
가장 기본적인 부분을 테스트한다.
해당 빌드가 더 이상 리소스를 투입해서 테스트를 할 가치가 있는 빌드인지 판단하고 개발팀에 피드백을 주기 위한 목적이다.

8. 회귀 테스트 (Regression Test)

이미 테스트된 프로그램의 테스팅을 반복하는 것
결함 수정 이후 변경의 결과로 새롭게 만들어 지거나, 이전 결함으로 인해 발견되지 않았던 또 다른 결함을 발견하는 테스트이다.

9. 새너티 테스트 (Sanity Test)

개발팀 혹은 개발자가 테스트 주체가 되어 테스트 케이스 없이 주요한 단위 모듈이나 시스템 모듈을 테스트하는 기법.
새로운 기능이 추가되었을 때 그 기능에 대해서 테스트 해보는 것을 새너티 테스트라고 한다. 새로운 기능 뿐 아니라 수정된 버그에 대해서도 새너티 테스트를 진행한다.

회귀테스트의 하위 집합으로, 새너티 테스트는 새로운 S/W 빌드가 주요 테스팅 업무를 수행하기에 충분히 적합한가를 판단하기 위해 수행하는 테스트이다.

비교	Sanity Test	Smoke Test
테스트 주체	대부분 개발팀	개발팀, 검증팀
테스트 대상	새로 추가된 기능, 수정된 버그	프로그램의 주요 기능
테스트 시기	주로 빌드, 릴리즈 전	주로 빌드, 릴리즈 후

잘 작성된 테스트 코드의 특징

1. 하나의 테스트 함수는 하나의 기능에만 집중할 것
1개의 함수에 대해 assert를 최소화 해야하며 함수가 맡은 기능이 잘 동작하는지에 초점을 맞춰야한다.

2. 독립적인 실행

3. 빠른 실행
테스트가 실행 될 때는 시간이 너무 많이 소요되지 않도록 해야하며 어쩔 수 없이 시간이 많이 소요되는 테스트는 테스트 슈트를 분리하거나 스케쥴 작업을 걸어두는 것이 좋다.

4. 어느 환경에서도 반복 가능할 것

테스트 코드 작성 시 권장

테스트를 자주 실행하며 커밋하기 전 또는 코드를 저장할 때마다 테스트를 실행한다.
자동으로 테스트를 수행할 수 있도록 훅을 구현한다.
디버깅 시 버그를 잡아내는 테스트를 작성한다.
테스트 이름은 길고 서술적일 수록 좋다.

쥬

개발자 꿈나무

이전 포스트

프로미스와 async & await/ 클로저

다음 포스트

모듈/테스트

study

모듈 (Module)이란 무엇인가요? Node.js에서 모듈을 사용하는 방법은 무엇인가요?

module 종류

core module

모듈을 사용하는 방법

local module

외장 모듈

모듈을 사용하는 방법

추가

테스트 (Testing)에 대해 어떤 것을 알고 있나요?

테스트의 원리

프로그램 실행 여부에 따른 분류

테스트 기법에 따른 분류

테스트 목적에 따른 분류

테스트 종류에 따른 분류

테스트 레벨

추가 - 심화

1. 단위 테스트 (Unit Test)

단위 테스트의 중요성

2. 통합 테스트 (Integration Test)

3. E2E 테스트(End-to-End Test) / UI 테스트

4. 인수 테스트(Acceptance Test)

5. 부하 테스트 (Load Test)

6. 스트레스 테스트 (Stress Test)

7. 스모크 테스트 (Smoke Test)

8. 회귀 테스트 (Regression Test)

9. 새너티 테스트 (Sanity Test)

잘 작성된 테스트 코드의 특징

테스트 코드 작성 시 권장

프로미스와 async & await/ 클로저

클라우드 컴퓨팅/멀티스레딩과 멀티프로세싱의 차이점

0개의 댓글