[JUnit] JUnit 이란?

목차

 

1️⃣ 글을 작성하기에 앞서..

사실 글을 적을까 말까 고민했는데, 회사에서 JUnit에 대해서 교육을 하게 될 계기가 생겨서 작성을 하다 보니 너무 많은 지식을 망각했다는 것을 깨닫게 되었다..

 

잊으면 안되는데도... 심지어 최근에 코드를 작성할 일도 많이 없었어서 코드도 어떻게 작성하는거였지 하면서 약간씩 망각하게 되는걸 보고 잘쓰던거여도 기록을 해두자 생각을 하게 되어서 이렇게 글로 작성해두려 한다.

 

해당 시리즈는 JUnit에 대해서, 그리고 JUnit을 바탕으로 무엇을 할 수 있는지, JUnit의 응용방법, 라이브러리에 대한 소개를 진행할 예정이다.

---

2️⃣ JUnit 그게 뭔데?

JUnit이란 Java 프로젝트에서 단위 테스트를 진행하기 위한 프레임워크로, 코드의 작동 방식을 확인하고 변경으로 인한 오류를 사전에 방지하는 도구이다.

 

테스트 주도 개발론인 TDD를 자바진영에서 이루기 위해서는 꼭 필요한 프레임워크이며, Kent Beck과 Erich Gamma가 제작하였다.

---

3️⃣ JUnit의 의존성 구성

위의 이미지는 JUnit 5 Tutorial 에서 참조를 해왔다. 

 

JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

 

JUnit의 공식문서와 같이 이미지를 보면서 이해를 하게 되었는데, JUnit은 Vintage, Jupiter와 Third Party로 구성이 되어있어 JUnit 5에서도 오래된 테스트를 돌릴 수 있는 이유가 JUnit 5가 Vintage를 포함하고 있어서 가능한것을 알수가 있다...

 

또한 Assertj는 Junit에 포함이 되지 않는 것 자체는 알고 있었는데, Third Party중 하나가 Third Party여서 실행이 가능한게 아닐까 하는 생각을 해볼 수 있었다. 

---

4️⃣ JUnit의 필요성

사실 해당 챕터에서 다룰 내용은 아니긴하다. 정확히는 JUnit보다는 Unit테스트가 필요한 이유라고 볼 수 있겠다. 유닛테스트가 필요한 이유로 봐도 생각해도 된다. 또한 필요성이라고 기록은 했으나, 장점으로 보면 좋을듯 하다.

 

첫번째로, 코드의 품질을 향상시켜 코드 자체의  신뢰성을 높이고, 코드가 변경이 되거나 하면서 발생하는 오류에 대하여 조기에 발견이 가능하고 빠른 수정이 가능해진다.

 

두번째로, JUnit은 개발자에게 코드의 변경에 대한 확신을 제공해준다. 이런 심리적으로 확신감을 준다는 말은, 추후 리팩토링과 기능을 추가하는 과정에서 코드의 안정성을 유지시키고 개발의 효율을 증대시키는 점이다.

 

세번째로, 개발자들간의 커뮤니케이션을 개선 할 수 있다. 테스트케이스는 테스트 자체의 목적도 있지만, 기능의 요구사항과 동작 방식을 명확하게 설명하는 문서의 역할도 할 수가 있다.

이게 가능한 이유는, JUnit을 결국 작성하려면 코드의 동작을 명확하게 명시해야 하며, 예상되는 결과를 검증해야 하기 때문이며 이 모든게 코드로 이뤄져 있기 때문에 코드를 읽고 해석이 가능하다면 불필요한 커뮤니케이션을 감소하는게 당연하기 떄문이다.

 

마지막으로 소프트웨어의 안정성을 높이게 되는데, 최근의 추세에 대부분의 프로젝트는 CI 와 CD가 당연하게 포함이 된다. 이런 자동화된 테스트와 배포의 과정에서 코드의 변경이 기존 시스템에 미치는 영향을 신속하게 파악하며, 안정적인 소프트웨어를 배포하는게 가능해지기 떄문이다.

---

5️⃣ JUnit의 사용방법 흐름

JUnit은 매우 단순하게 기능들에 대해서 테스트를 진행 할 수 있도록 되어있으며, 크게 아래의 4개의 단계를 거치면 된다.

 

1. JUnit의 라이브러리를 프로젝트에 추가한다.
2. @Test어노테이션을 활용하여 테스트 메소드를 작성한다.
3. 테스트 러너를 사용해 테스트 케이스를 실행하며, 보통 필자는 IDE를 활요한다.
4. 테스트가 실행된 결과를 확인

---

6️⃣ 단위테스트 작성 방법

위의 이미지처럼 @Test 어노테이션을 사용해 테스트 메소드를 정의한다.

assert메소드의 경우에는 필수는 아니나, 없으면 검증의 의미가 없는 빈 메소드지 않겠는가? 

assert메소드는 검증의 단계기 때문에 넣는걸 권장한다.

 

순서는 다음과 같다. Calculator클래스 객체를 생성하고, 내부에 메소드를 호출해서 2와 3을 더했을때, 결과가 5가 나오는지를 확인하는 간단한 코드다.

---

7️⃣ JUnit의 단점? 고려사항?

JUnit을 사용하지 않는 환경에서 갑작스레 도입을 진행하려고 할때 한번쯤 생각해봤으면 좋을 항목들이다.

 

1. 개발팀의 규모

개발팀 규모가 큰 경우다. 이런 경우 코드의 변경이 빈번할 수 있기 떄문에 품질을 유지하면서 개발이 가능해지는 장점이 있다.

 

하지만 기존에 JUnit을 활용하고 있지 않았던 환경이라면 모든 개발자가 전부 JUnit을 학습해야 하는 부분들이 발생하며, 실제 JUnit테스트케이스를 작성해보지 않은 사람들은 테스트케이스를 작성해보면서 도입 초기에 생산성이 낮아질 수도 있는 부분을 염두해야 한다.

 

도입기간 과정에서 학습의 편차가 다르기때문에 유닛테스트의 결과에 만족을 못하는 시기가 존재할 수 있다.

 

 

 

2. 프로젝트 규모

프로젝트의 규모가 크고 복잡한 경우이다. 모놀리식으로 여러 시스템을 묶어놓는다든가, 많은 모듈을 동시에 실행시켜야 하는 환경등등..

많은 종류가 존재할 수 있겠다.

 

테스트 케이스는 많아지면 많아질 수록 전체 테스트를 진행하는 시간이 길어지게 된다. 테스트는 자주 쉽게 실행을 해야하는데, 길어지는 테스트 진행시간을 해결할 방법을 찾아야 하게 된다는 점이 해결해야 할 문제라 필자는 생각한다.

 

 

3. 코드의 복잡성

필자가 현재 재직중인 회사의 경우에는 오랜시간 개발을 하신 개발자님이 한분 계셨다. 그분은 트렌트에 맞게 개발하는 분은 아니셨다. 절차지향으로 개발을 하시던 분이었으며, 대부분 한개의 메소드에 모든 비즈니스로직이 포함되어 있었다. 

그러다 보니 매우 복잡한 로직의 메소드만 제작을 하셨으며, 설명이 없으면 이해가 힘들정도였다. 테스트케이스 역시 존재하지 않았다.

 

이런 복잡한 코드로만 이루어진 경우에 JUnit을 도입하면 변경점이나 오류가 있을때 조기에 발견할 수 있는 장점이 있을 수는 있다.

하지만 이런 복잡한 로직의 분석이후 테스트케이스를 작성은 누가할것인가? 코드가 복잡할 수록 테스트케이스를 작성하는 상황이 배보다 배꼽이 더큰 즉 리소스가 더 많이들어가는 상황이 나와버릴 수도 있는 점을 유의해야 한다.

---

8️⃣ 글을 마치며

정리하면서, JUnit을 사용하면서 보니 이론을 실제로 경험해본 경우들이 대부분이라는게 눈에 보인다는게 신기하다.

필자의 경우에도 실제로 확신을 갖고 개발을 할 수 있는 점 때문에라도 JUnit은 너무 필요하다고 생각을 하게 되었으나, 처음에 적응을 하는 과정에서는 생산성이 심각하게 떨어졌던 과거가 있었던 것 같다.

 

JUnit이 꼭 장점만 있는 것이 아니기 때문에 염두를 해두면서 사용하면 좋을 것 같다.

 

다음 아티클은 JUnit으로 할 수 있는 테스트 케이스의 종류에 대해서 정리해보고자 한다.