✏️4.6 경계 조건 검사하기

경계 지점에서 문제가 생기는 경우에 테스트를 작성해보자. producers컬렉션이 비었을 때 테스트를 작성해보자.

// 생산자가 없는 경우
describe('no producers', function(){  // 생산자가 없다.
  let noProducers;
  beforeEach(function(){
    const data = {
      name: 'No Producers',
      producers: [],
      demand: 30,
      price: 20,
    };
    noProducers = new Province(data);
  });
  it('shortfall', function() {
    expect(noProducers.shortfall).equal(30);
  });
  it('profit', function() {
    expect(noProducers.profit).equal(0);
  });
});

숫자형이라면 0일 때를 검사해본다.

it('zero demand', function() {  // 수요가 없다.
  asia.demand = 0;
  expect(asia.shortfall).equal(-25);
  expect(asia.profit).equal(0);
});

음수인 경우

it('negative demand', function() {  // 수요가 마이너스다.
  asia.demand = -1;
  expect(asia.shortfall).equal(-26);
  expect(asia.profit).equal(-10);
});

❓ 수요의 최솟값은 0이어야 하지 않나?

이런식으로 경계를 확인하는 테스트를 작성해보면 프로그램에서 특이 상황을 어떻게 처리하는게 좋을지 생각해볼 수 있다.

문제가 생길 가능성이 있는 경계 조건을 생각해보고 그 부분을 집중적으로 테스트하자.

이 프로그램의 세터들은 의미상 숫자만 입력받아야 하지만 UI로부터 문자열을 취하고 있다. 그러다 보니 필드가 비어있을 수도 있다.

it('empty string demand', function() {  // 수요 입력란이 비어 있다.
  asia.demand = "";
  expect(asia.shortfall).NaN;
  expect(asia.profit).NaN;
});

의식적으로 프로그램을 망가뜨리는 방법을 모색하는데, 이런 마음자세가 생산성과 재미를 끌어올려준다.

테스트 코드를 작성하는 도중, 기존 코드의 겉보기 동작을 변경 해야만하는 테스트 코드를 작성하게되는 순간이 온다. 이러한 경우 리팩터링은 겉보기 동작에 영향을 주지 않아야하기 때문에 이런 테스트를 작성하는 것을 저자는 추천하지 않는다.

테스트를 어디까지 해야 할까에 대한 의문에 너무 빠져들 필요는 없고, 특정 위험한 부분에 집중하는 게 좋다 한다. (코드에서 처리 과정이 복잡한 부분, 함수에서 오류가 생길만한 부분)