[Clean Code/클린 코드] - 단위 테스트 (Unit Test)

과거에 테스트 코드 관련 글을 정리한 것이 있어 링크만 첨부하고, 책에서 뽑아온 내용만 기입도록 하겠습니다.

 

 

단위 테스트 ( Unit Test )

클린코드의 9장에서는 단위 테스트 ( Unit Test )에 대해서 다루고 있습니다.

 💡 개발자들은 테스트 코드가 주는 이점을 잘 알고 있습니다. 그러나 잘못된 테스트 코드를 작성하거나 우리가 의도한 바를 정확하게 표현하지 못하면 100%의 효율성을 내기 어렵습니다. 그래서 많은 개발자들이 테스트 코드를 작성하다 쉽게 포기하곤 합니다.

 

우선 테스트를 작성하면 다음과 같은 이점을 얻을 수 있습니다.

• 유연성
• 유지 보수성
• 재사용성

이러한 이점으로부터 얻을 수 있는 것이 무엇이냐? 바로 쉬운 변경입니다.

왜 쉬운 변경이라는 이점을 얻을 수 있을까요?

 

💡 제가 생각하기엔 한 메서드 단위를 테스트 하기 위해서 테스트 코드를 작성함으로써 기능을 확인하고 검증할 수 있는데, 요구사항이나 기능의 변경 시 빠르게 확인이 가능합니다. 확인함으로서 변경에 따른 영향을 쉽게 파악할 수 있고 이로 인해 쉽고 빠른 변경이 가능합니다.

 

클린코드를 읽다가 너무 마음에 와닿는 문장이 있어 인용했습니다.

“테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다. 테스트코드가 지저분할수록 실제 코드도 지저분해진다. 결국 테스트 코드를 잃어버리고 실제 코드도 망가진다.”

💡 우리가 작성한 로직을 테스트 코드로 작성해서 표현하기란 어렵습니다. 테스트 코드를 작성하면서도 이 방식이 맞는지 여러번을 확인하게 되고 생각하게 됩니다. 결국 이러한 생각의 굴례를 벗어나지 못하고 deadLine과 압박을 견지디 못하고 테스트 코드 작성을 포기하고 POSTMAN이나 LOG를 이용해 데이터의 흐름이나 로직의 흐름, 동작을 확인하게 됩니다.

 

물론 이 방법도 나쁜 것이 아니지만 만약에 LOG를 찍어서 데이터가 올바르게 동작하는지, 체크를 한다고 가정해보겠습니다.

💡 만약에 로직들이 이리왔다, 저리갔다 왔다갔다 하고, 로직이 길어지면, 하나하나 다 LOG 도 찍어야하고 직접 check를 해야합니다. 이로서 개발자가 해야할 일이 더욱 많아지고 복잡도가 증가합니다. 테스트 코드는 중요하면서도 작성하기는 어렵습니다. 그럼 어떤 의도를 갖고 테스트 코드를 작성해야 할까요?

 

 

https://jipang9-greedy-pot.tistory.com/167

Test Code 2부