미션 첫 인상 및 설계 방향 💡

미션을 보았을 때, 유닉스와 윈도우의 파일 체계와 URL에 대해 복습하고, 첫번재 미션을 수행하면 되겠다고 생각했다.

이후 테스트 코드 작성하는 부분에서 좀 시간과 공부가 필요하지 않을까하는 생각이 들었다.

미션 해결 중 문제점

• 정규표현식 🥲

  정규표현식을 여러 번 사용했지만, 기억에 잘 남지 않았다….

오늘 공부한 이론 🔍

• Windows 시스템 파일 경로 형식

  

• 정규표현식

  

• 정규 표현식의 flag

• JavaScript에서 ReadOnly

  • Object.defineProperty() 이용
  • Object.freeze() 이용

  "use strict";
  var obj = Object.freeze({ name: "Score", points: 157 });
  obj = { name: obj.name, points: 0 }; // replacing it with a new object works
  
  ("use strict");
  var LUNG_COUNT = 2; // a `var` works, because it's not read-only
  LUNG_COUNT = 3; // ok (anatomically unlikely, though)
  

  • protected 프로퍼티
    • protected 프로퍼티 명 앞엔 밑줄 _이 붙습니다.
  • 읽기 전용 프로퍼티 → setter는 생성하지 않고, getter만 생성

  class CoffeeMachine {
    // ...
  
    constructor(power) {
      this._power = power;
    }
  
    get power() {
      return this._power;
    }
  
  }
  
  // 커피 머신 생성
  let coffeeMachine = new CoffeeMachine(100);
  
  alert(`전력량이 ${coffeeMachine.power}인 커피머신을 만듭니다.`); // 전력량이 100인 커피머신을 만듭니다.
  
  coffeeMachine.power = 25; // Error (setter 없음)
  

• Jest vs. Mocha

  • Mocha
    • 테스트 러너를 포함한 테스트 프레임워크
    • Assertion, Mocking, Stubbing 등의 라이브러리를 포함하지 않음 → 추가 라이브러리 설치 및 설정 작업 필요
  • Jest
    • 잘되어있는 문서화
    • preconfiguration 필요하지 않음 (추가적인 의존성 필요하지 않음)

• 단위 테스트

  • 하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트
  • [ 단위 테스트(Unit Test) 작성의 필요성 ]
    • 새로운 기능 추가 시에 수시로 빠르게 테스트
    • 리팩토링 시에 안정성을 확보
  • [ 좋은 단위 테스트의 특징 ]
    • 1개의 테스트 함수에 대해 assert를 최소화
    • 테스트 함수는 1가지 개념 만을 테스트
  • mock
    • 받을 호출에 대한 기대를 가진 미리 프로그래밍된 객체
    • 행위 검증을 사용 (구현된 메서드의 호출 여부, 횟수, 발생한 예외 등 검증)
    • 행위 검증은 상대적으로 특정 메서드의 호출과 같이 구현에 의존
    • 비교적 복잡한 협력에서도 작성이 간편
  • stub
    • 미리 정해진 호출에 대해 정해진 응답을 제공
    • 테스트 시 프로그래밍된 것 외에는 응답하지 않음
    • 상태 검증을 사용 (결과에서의 상태의 값 확인)
    • 상태 검증을 위해 상태가 노출되는 메서드가 추가될 수 있음

더 나은 내가 되기 위한 발전 체크 포인트🍀