TIL (Today I Learned)

2024.02.09

오늘 읽은 범위

8장 경계

9장 단위 테스트

책에서 기억하고 싶은 내용을 써보세요.

8장 경계

외부 코드(패키지) 사용 시, 우리가 사용할 코드는 테스트 하는 편이 좋다.

외부 코드를 익힐 때에는 학습 테스트를 해보면 좋다.

(학습 테스트는 패키지가 예상대로 도는지 검증한다)

외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자

9장 단위 테스트

TDD가 중요한 것이 아니다. 제대로 된 테스트 케이스를 작성하는 것이 더 중요한 사실이다.

TDD 법칙 3가지

1.실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

2.컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

3.현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

이 3가지 규칙을 따르면 개발과 테스트가 짧은 주기로 묶이며, 테스트 코드가 실제 코드와 함께 나온다.

깨끗한 테스트 코드 유지하기

테스트 코드는 실제 코드 못지 않게 중요하다. 실제 코드 못지 않게 깨끗하게 짜야 한다.

테스트 코드가 복잡할수록, 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리게 된다. 이렇게 테스트 코드는 계속해서 늘어나는 부담이 된다.

테스트는 유연성, 유지보수성, 재사용성을 제공한다.

테스트 케이스가 있다면 변경이 쉬워지고, 리팩터링 등의 변경에도 공포가 사라진다.

다만, 테스트 코드가 지저분하다면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다.

깨끗한 테스트 코드

가독성이 전부이며 가장 중요하다.

실제 코드보다 오히려 테스트 코드에 더더욱 중요하다.

최소의 표현으로 많은 것을 나타내야 한다.

단, 실제 코드만큼 효율적일 필요는 없다. 돌아가는 환경이 다르기 때문이다.

테스트 당 개념 하나

이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다.

깨끗한 테스트 규칙. FIRST

F: Fast (빠르게). 테스트는 빨라야 한다. 빠르게 돌아야 한다. 테스트가 느리면 자주 돌릴 엄두를 못 낸다. 자주 돌려 초반에 문제를 찾아내 고쳐야 한다. 코드를 마음껏 정리하지 못한다면 결국 코드 품질은 망가지기 시작할 것이다.

I: Independent(독립적으로): 각 테스트는 서로 의존하면 안된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안된다. 독립적이어야 하며, 어떤 순서로 실행해도 괜찮아야 한다.

R: Repeatable(반복가능하게): 테스트는 어떤 환경에서도 반복 가능해야 한다. 실제 환경, QA 환경, 네트워크가 끊긴 환경 등 어떤 환경에서도 실행 가능해야 한다. 돌아가지 않는 환경이 있다면, 테스트가 실패한 이유를 둘러댈 변명이 생기기 때문.

S: Self-Validating(자가검증하는): 테스트는 bool 값으로 결과를 내야 한다. 성공 아니면 실패다.

통과 여부를 알려고 로그 파일이나 다른 텍스트 파일 등을 읽는 것이 아니다. 스스로 성공과 실패를 가늠하도록 검증이 되어야 한다.

T: Timely(적시에): 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

결론

테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다. 유연성, 재사용성, 유지보수성을 보존하고 강화하기 때문이다. 지속적으로 깨끗하게 테스트 코드를 관리하려고 노력해야만 한다.

테스트 코드가 방치되어 망가지면 실제 코드도 망가진다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

프론트엔드에서 테스트 코드를 어디 까지, 얼만큼, 어떻게 작성해야 하는 지에 대한 고민이 많이 있다.

테스트 코드하면 TDD 방법론이 유명하다보니, 이를 도입해야 하나 생각하고 TDD 방법론에 대해 알아보게 되었다. 다만 이게 프론트엔드에서 정말 도입할 수 있는 것인가 의문이 든다.

현실적으로 그리고 효율적으로 도입을 하는 방법을 요즘 찾아보고 있는데, 쉽지 않다. 개발자들 사이에서도 의견이 분분하며, 원론적인 TDD 방식으로 적용하는 곳은 찾아보기 힘들다. (결국 테스트 코드를 작성하는 것이 중요하다는 것은 알지만, 방법론을 꼭 따라야 하는 지에 대한 의문이 생기는 것이다.)

개인적으로도, 시스템이나 기업용 웹 어플리케이션 같은 경우에는 자주 화면이 변경되지 않아서 괜찮다고 생각하지만, 웹 서비스 (특히나 아직 자리를 잡지 않았고, 수 많은 기획 변경과 리브랜딩 등이 일어나 변화의 주기와 폭이 매우 높은) 경우에는 적용하기 쉽지 않다고 생각한다.

심지어 일정이 촉박한 상황이라면? 클린한 실제 코드를 작성하는 데에도 벅차게 느껴질 수 있다. 핵심적인 기능들은 테스트 케이스가 필요하겠지만, 테스트를 얼마나, 어디까지 작성할 지는 고민이 필요한 것 같다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

TDD, BDD, DDD 등 여러 방법론이 있는데, 테스트 케이스나 코드를 작성한다고 반드시 TDD를 따를 필요는 없는 것 같다. 그런데 프론트엔드에서 적절한 방법은 무엇인지 고민이 된다.

(아마도 프로젝트 상황에 따라, 도메인에 따라 상당히 다르지 않을까 싶다.)

결국은 테스트 코드 자체를 깨끗하게 만드는 게 중요한 것이 아닐까 싶고, 어떤 코드까지 테스트의 범위에 넣어야 하는지를 고민하면 되는 것 같다.

최애 북틸 3명

dongpark님

상당히 정리를 잘 해주셔서 감탄 & 반성하며 보았습니다.

https://dongpark.notion.site/9-23815f9364134cc9b40c52c6dc2328c0

topcircle님

고민 내용이 너무 비슷해서 좋았습니다.

https://nomadcoders.co/community/thread/9299

mandingco님

떠오르는 생각 부분을 읽다 소름이...

오류 처리에 대해 다시 생각해야겠다고 느낀 점이 똑같아서 좋았습니다.

https://nomadcoders.co/community/thread/9291