오꾸오꾸(오늘도 꾸준히 오랫동안 꾸준히)

CORRECT Conformance 특정 포맷을 준수하는지 확인하는 테스트가 있어야합니다. ex) 전화번호, 이메일, 아이디같은 특정한 포맷을 준수해야하는 경우 포맷에 맞을 때 또는 맞지 않을 때 코드가 어떻게 동작하는지 예상하는 테스트 코드를 작성해야합니다. Ordering 순서 조건을 확인해야합니다. 만약 우리의 코드가 어떠한 배열의 순서를 중요시하는 코드라면 예를들어 학생들의 순번대로 배열이 저장되어있지 않은 경우 어떻게 반응할 것인지 예상하는 것들도 테스트로 나타낼 수 있어야 합니다. Range 숫자의 범위 우리가 예상하는 input의 범위가 특정한 범위이고 그 범위를 넘었을 때 어떻게 동작해야 하는지 코드를 작성해야 합니다. Reference 외부 의존성 유무, 특정한 조건의 유무 구현한 함수에..

Right-BICEP 모든 요구 사항이 정상 동작 하는지 확인해야 합니다. 어떤 것을 집중하여 확인하여야 하는지 알아볼까요? Boundary conditions 모든 코너 케이스에 대해 테스트를 해야합니다. ex) 학생이 0명일 때 1000명일 때 그 이상일 때 이런 모든 케이스들에 대해서 테스트를 해야합니다. 잘못된 포맷의 인풋, null, 특수문자, 잘못된 이메일, 작은 숫자, 큰 숫자, 중복, 순서가 맞지 않은 경우 어떻게 동작 해야 하는지 이러한 케이스에 대해서 테스트가 이루어질 수 있도록 해야합니다. Inverse relationship 역관계를 적용해서 결과값을 확인해야합니다. 즉 일관성을 유지해야 합니다. ex) 5 + 5 = 10 인 것을 테스트했다면 10 - 5 = 5도 적용이 되어야 합..

Fast 테스트코드가 빠르게 수행될 수 있도록 만드는 것 즉 느린것에 대한 의존성 낮추기 테스트하고자 하는 코드에서 파일을 읽거나 데이터베이스에 접근하거나 네트워크를 사용한다면 이건 테스트 코드를 느리게 만들 수 있습니다. Isolated 고립적으로 독립적으로 만들어야 한다는 원칙, 최소한의 유닛으로 검증해야합니다. Repeatable 반복이 가능하도록 만들어라 이 말은 테스트 코드를 실행 할 때마다 동일한 결과를 유지 해야 한다.예) 다른 테스트 코드에 의존하거나 네트워크나 외부적 환경에 의존하는 코드는 환경에 의해서 결과 값이 달라집니다. 그렇기 때문에 테스트 코드는 환경에 영향을 받지 않도록 작성해야한다. Self-Validating 테스트코드는 스스로 실행한 값과 예상 값을 비교해서 성공하거나 실..

테스트의 비밀 한번 작성된 테스트 코드는 영원히 유지보수 해야 한다. 테스트 코드에서는 내부 구현 사항을 테스트하면 안된다.너무 내부적인 상황을 넣게 되면 구현 사항을 조금만 변경해도 테스트가 실패합니다. 사용자가 사용하는 함수, 클래스, API만을 가지고 테스트해야합니다. 재사용성 높이기(테스트 유틸리티) 반복되는 코드가 있다면 함수나 클래스로 만들어서 재사용성을 높입니다. 배포용 코드와 철저히 분리 test코드와 mock stub같은 것들을 철저히 분리해야합니다. 테스트코드를 통한 문서화 테스트코드 우리가 하나의 테스트를 작성하게되면 호출이 실행되기 전에 수행되는 beforeEach와 beforeAll가 실행되고 테스트 코드가 실행되고 나서 호출되는 afterEach affterAll이 있습니다. 그..

stub는 기존의 함수의 인터페이스를 모두 충족하는 다른 객체 product_service_no_di_refactor.js class ProductService_stub { constructor(productClient) { // Dependency Injection에 맞게 this.productClient = productClient } fetchAvailableItems() { return this.productClient .fetchItems() .then(items => items.filter(item => item.available)) } } module.exports = ProductService_stub stub_product_client.js class StubProductClient { ..

실제 객체를 만들어 사용하기에 시간, 비용 등의 Cost가 높거나 혹은 객체 서로간의 의존성이 강해 구현하기 힘들 경우 가짜 객체를 만들어 사용하는 방법입니다. 필요한 순간 테스트 작성을 위한 환경 구축이 어려운 경우 테스트가 특정 경우나 순간에 의존적인 경우 테스트 시간이 오래 걸리는 경우 ProductService.js const ProductClient = require('./product_client') class ProductService { constructor() { // 좋지 못한 코드 클래스 내부에서 의존성을 만들어주는 것은 OOP설계 원칙을 벗어나는 행위 this.productClient = new ProductClient() } fetchAvailableItems() { return ..

자동 환경 설정 npm i jest -g npm i jest "scripts": { "test": "jes --watchAll" }, 지금 내가 작업하는 것들에 대해서만 작용하고 싶다면 "scripts": { "test": "jest --watch" }, git init를하고 .gitignore 파일을 생성 후 .gitignore에 node_modules/* 이렇게하면 내가 수정한 파일만 test가 됩니다. Unit test const add = require('../add.js') test('add 1 + 2 to equal', () => { // 테스트 코드 작성! // === expect(add(1, 2)).toBe(3) }) add.js에 있는 add함수를 사용하여 그 값이 3이여야 한다. npm..

테스트란 무엇인가? 제품(함수, 기능, ui, 성능, API 스펙)이 원하는데로 동작하는지 확인하는 것 어떤 플랫폼에서 하는지 어떤 환경에서 하는지에 따라 다양한 테스트가 존재 진행 순서 수행하는 js.code가 있고 이 코드가 제대로 수행하는지 알 수 있는 test 코드를 작성합니다. 이 test코드는 우리가 원하는 epectation(함수, 기능, ui, 성능, API 스펙)의 요구 사항에 맞게 확인할 수 있도록 테스트를 작성한다. TDD테스트의 장점 자동화 속도(빠르게) 쉽게 작성 높은 커버리지 TDD테스트를 하는 이유 기능이 정상 동작 요구 사항 만족 이슈에 대해 예측 버그를 빠르게 발견 자신감 있게 리팩토링 손쉬운 유지 보수 코드의 품질 향상 코드간 의존성을 낮춤 좋은 문서화 시간을 절약 테스트..