테스트 코드

단위 테스트 코드 파일 생성

일반적인 관례로 테스트할파일이름.spec.js 와 같은 형식으로 파일을 만듭니다.
jest 또한 위 형식의 이름을 가진 파일을 읽어들여 테스트 코드를 실행하는게 기본 설정이기도 합니다.
ex) validation.spec.js

단위 테스트 코드 작성

• test(): 단위 테스트를 묶어주는 함수입니다.
• expect(): 특정 값이 만족되는지(정상적인지) 확인하기 위한 표현식을 작성할수 있게 해주는 함수입니다.

조언

• 테스트 코드 작성은 빨리 시작할수록 좋습니다. 테스트 코드를 처음 작성하는데 시간이 오래 걸린다고 절대로 귀찮아하지 마세요.
  테스트 코드가 있었으면 방지할 수 있는 상황이 끝도 없이 발생합니다 😇
• 테스트 코드를 작성했는데도 자신의 코드를 수정하는게 불안하다면, 지금 작성한 테스트 코드가 정말로 "결함을 찾도록 도와주고 있는지" 확인해보세요.
• 테스트 코드는 여러분이 "질 떨어지는 코드"를 작성하는것을 막아주는 방파제가 됩니다.
  나중에 자신이 다니고 있는 회사에서 코드 리뷰나 좋은 선임 개발자가 없어서 내 코드의 질이 떨어지는것 같다고 생각하는 순간이 온다면 테스트 코드를 잘 작성하고 있는지 한번쯤 돌아봐야 합니다.
• 테스트 코드를 작성하기 어렵거나 애매한 기능이 있다면 추상화가 해결해줄지도 모릅니다.
• 테스트 코드를 작성할때는 비즈니스 로직을 중심으로 작성해보세요.
  개발자의 입장에서 테스트 코드를 작성하는것보다, 내가 만들고 있는 서비스의 기능을 중심으로 테스트 코드를 작성하면 기획자가 신규 개발을 요청할때만 변경될것입니다.
• 테스트 코드의 작성이 조금 익숙해졌다면 TDD(Test-Driven Development)와 BDD(Behaviour-Driven Development)가 무엇인지 찾아보세요.
• 단위 테스트 코드를 작성하는 경우, 테스트하려는 기능의 코드보다 해당 기능을 테스트하는 테스트 코드가 더 훨씬 많은것이 Best Practices(모범 사례)라고 꼽힙니다.
• 테스트 코드는 몇번을 실행하든 같은 결과가 나와야 합니다.

개발자로서 성장하고 싶은 분들을 위한 조언

아래에서 밑줄이 있는 키워드는 직접 찾아보면서 이게 무엇인지 제대로 기억하시는걸 추천합니다.

• 테스트 코드는 지금 당장 작성하기 시작해보세요.
• 항상 새로운것을 받아들이고, 핵심이 뭔지 파악하려고 노력하세요. 빠르게 성장할 수 있는 지름길입니다.항상 새로운것을 받아들이고, 핵심이 뭔지 파악하려고 노력하세요. 빠르게 성장할 수 있는 지름길입니다.
  • 좋은 도구를 잘 쓰기만 해도 금방 현업 개발자들 만큼 잘 할수 있습니다.
    • 장인은 도구탓을 하지 않는다는것은 옛말!
      개발자는 도구를 직접 만들고 사용해서 더 효율적으로 더 좋은 도구를 만드는 사람입니다.
    • 대부분의 현업 개발자들은 이 "좋은 도구"들에 대한 경험이 풍부하며, 잘 사용하는 사람들이기도 합니다.
  • 좋은 도구를 잘 쓰기 위해서는 도구를 잘 이해하고 사용해야 합니다.
    • 모두가 좋다고 떠들어대서 무턱대고 도구를 사용하면 큰 화를 입을 수 있습니다.
  • 새로운 기술을 적용할 때는 오버 엔지니어링을 더욱 조심하세요.
  • 대부분의 회사에서 기술 부채는 없을 수 없습니다.
    다만, 기술 부채가 무작정 늘어만 간다면 잘못되고 있다는 신호일 수 있습니다.
    "6개월동안 기술 부채를 없애려고 집중했을 때 전부 없앨수 있다" 라고 생각될 정도로만 유지하세요.
  • 더 좋은 인터페이스를 만들수 있도록 훈련하세요.
    • 인터페이스는 함수의 이름, 함수의 인자, 반환 값 모두 포함되며, API 조차 인터페이스라는 사실을 잊지 마세요.
  • 실제로 서비스를 운영한다고 생각하고 사이드 프로젝트를 진행해보세요. 사용자의 입장에서 생각하고 개발해보세요.
    당장은 코드를 더 많이 짜야하고 고려할게 많더라도, 이렇게 하는것이 장기적으로 유지보수에 더 도움됩니다.
    - 사용자의 입장에서 더 좋은 서비스라고 생각되게 도와주는 설계나 개발론 또는 기법들이 있으니 찾아보고 공부해보세요.
    ex) BDD(Behavior Driven Development), DDD(Domain Driven Design)
  • 절대로 여러분만 유지보수가 가능한 코드를 짜지 마세요.
    지금의 여러분은 유지보수가 가능한 코드일지 몰라도, 1년 뒤의 자신이 보았을 때는 정말 이상한 스파게티 코드로 보일겁니다.
    즉, 여러분만 유지보수 가능한 코드는 그 당시에만 유지보수가 가능할 정도로 엉망이라는 뜻입니다.
  • 보이스카우트 원칙을 몸에 베도록 하세요.
    **캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.**
  • 자신이 만들 서비스를 어떻게 구현할지 모르겠다면, 최대한 비슷한 유명한 서비스를 찾아서 그 서비스가 어떻게 만들어졌는지 찾아보세요.
    만약 그것이 오픈소스라면 설계를 어떻게 했는지까지 파악할 수 있을겁니다.