• chai에서 다양한 assertion style을 제공하더라 => assert, expect, should
  • 이것들의 차이가 무엇일까? 알아봤더니 매개변수라던지 메서드 기술방식이 조금씩 달랐음.
    • should는 Obeject.prototype에 접근하여 should를 바인딩하므로 myObject.should.~ 이렇게 쓸 수 있음. 그러나 네이티브 객체의 prototype을 변형시킨다는 점에서 탈락.
    • 남은것은 expect vs assert. 난 expect를 쓰기로 결정했는데,
    • 그 이유는 expect(타겟객체).to.equal(예상객체, 에러메시지)의 인터페이스가 더 읽을때 직관적으로 느껴졌다. 일단 타겟객체가 뭔지를 expect()에서 써주니깐 주어가 먼저 있고 그다음 메서드명이 chainable한 형식으로 지원되므로 문장처럼 읽히기 때문이다.
    • 그에 비해 assert.toEqual(타겟객체, 예상객체, 에러메시지)의 인터페이스는 매개변수들이 한데 모여있기 땜에 덜 직관적이었다. 그러나 어떤 메서드를 실행할 지가 맨 앞쪽에 나오므로, 타겟보다 행동에 집중하는게 목적이라면 이걸 선호할 수도 있을 거 같다.
  • 왜 (특별한 기능적 차이가 없는데도 불구하고) 다양한 인터페이스를 제공할까?도 생각해 봤는데
    • 기능보다는 테스트코드가 목적에 맞게 얼마나 자연스러운 문장으로 읽히는가? 가 중요한 것이기 때문이라는 생각이 들었음
    • 공식문서에 expect/should는 BDD스타일이고 assert는 TDD스타일이라는데 이런 개발방법론이 자연스럽게 유도되는 문장으로 인터페이스를 제공하는 거 같다는 생각을 했다. 아쉽게도 저런 방법론은 아직 경험해보지 않아서 와닿지는 않음.
• mocha와 jest. mocha는 사용자의 입맛에 맞게 부가적인 도구를 조합해서 쓸 수 있도록 틀만 제공하는 반면, jest는 모든 도구를 한번에 다 제공하고 확실히 요즘 트렌드에 맞게 async라던가 promise, module, mock, mongodb, webpack 이런 것과의 조합이 자연스럽게 이뤄지도록 공식문서에서부터 안내를 하니 좋은 거 같다. mocha는 골라 쓸 수 있게 자유도를 줬지만 찾아보면 거의 많이 쓰는 조합이 mocha + chai + sinon + istanbul 이런 식인듯. 아직은 어떤게 더 좋은지 모르겠다. 나중에 리엑트하게되면 jest로 써보면서 느껴보면 좋겠다.
• 유닛테스트에 관한 가이드는 많이 나오는데 통합테스트 같은 것들은 아직 감이 안 잡힌다.