JUnit으로 성능 테스트 겉핥기

Posted by 에브리플라워
2016.02.22 17:19 프로그래밍/Java
JUnit으로 성능 테스트 겉핥기

일단 하단 참고블로그를 상당부분 보고 따라했으며, 기록에 개입을 혼자 생각한 내용을 첨부해서 적어본다.

JUnit의 사용목적은 단위 테스트(unit test@wikipedia.org)에 있다. 
프로그램의 성능을 시험하는데 부분 별로 테스트하여 성능을 점검해보는 것이라고 생각할 수 있겠다. 
분명히 프로그램에는 다양한 함수가 쓰이고 클래스가 유기적으로 엮여있기 때문에 어떤 부분에서 부하가 발생할지를 예상도 해야할 것이고 최적으로 만들려면 어떻게 해야할지를 고민하면서 여러가지 상황을 엮어서 생각해봐야 할 것이다. 

과거에 프로젝트 진행 시 선임분이 작업이 안된 부분도 이를 이용하여 작성전에 퍼포먼스를 예상하는 경우를 본적이 있다.
이 부분까지 볼 수 있을지 모르겠지만 우선 작성해 본다.



이클립스에 설정하기

직접해보기 위해서 Java Project를 하나 만들어서 시작부터 JUnit library를 포함하도록 해봤다.     


프로젝트 이름 지정하고 Next


Libraries -> Add Libraries -> JUnit -> Next  -> Finish

프로젝트에 라이브러리가 추가되어서 생성된다.
이제 클래스를 하나 만들어서 테스트 해볼 시간이다.

매개변수를 받아서 출력하는 함수 하나를 그냥 만들었다.


바로 JUnit test case를 만들어보자.

위 클래스가 담김 패키지에서 뒤에 .test만 추가해서 새 패키지를 만들고, 작업을 시작해보자.

굳이 이렇게 하지 않아도 되긴하는데 그냥 명목상 보기 좋게 이렇게 했다. 위 형태보다는 아에 src 폴더하위에서 test 디렉토리를 구성하여 담아 두는 형태를 더 자주보았다.


새로 생성한 클래스에서 JUnit test case를 만들도록 한다.


진입하면 이런 화면이 나오는데 여기서 설정을 통하여, 폴더위치나 패키지 위치도 변경할 수 있다. 
위 항목에서 Name에는 테스트 하려는 클래스의 이름에 Test만 붙여서 적고(TestCase도 Class를 작성하여 진행하게된다),
하단에 Class under test에는 확인하고자 하는 클래스를 패키지명 포함하여 모두 적어주면 된다.

 
browse로 해서는 안보인다. 여기에 패키지명을 입력해서 있나 없나를 볼 수 있는 정도인 것 같다. 때문에 안들어가고 바로 치는 것이 낫다.



설정을 마치고 Next를 누른 화면이다. 
기본적으로 상속받은 Object 클래스의 메서드외에 기존 클래스에 담긴 함수도 보인다. 이 함수를 테스트 하기위함이니 해당 함수를 선택하고 Finish.


자동으로 클래스가 작성되어 나타났다.
어노테이션도 생겼다. 이 어노테이션으로 이 함수가 테스트 진행시에 수행될 함수라는 것을 나타내고 있다.


이제 이 함수에 어떻게 테스트 할지를 지정해보았다.
assertEquals(param1,param2) 함수로 결과를 예상하고 해당 함수의 결과값과 비교해서 상태를 알아보도록 한다.
assertEquals()함수는 오버로드 되어있어 다양한 결과와 반환값을 비교할 수 있도록 구성되어 있다.


바로 TestCase를 실행보자.

Test 결과는 JUnit View를 통해 출력된다.
녹색으로 나온 경우가 성공이, 적색으로 나오는 경우는 실패이다.

실패라 하면 예상밖의 결과가 나왔다는 것이다.
일부러 예상값을 틀리게 설정해 보고 다시 테스트 했다.
40321을 예상했지만 결과는 40320이다 라고 표현했다.
실행시간 결과 등을 보임으로써 다양한 상황을 원하는대로 구현해볼 수 있겠다.


위에서 테스트 대상인 함수를 @Test라는 어노테이션으로 표현했는데, 스프링에서 사용하듯이 다양한 조건을 걸어서 원하는 플로우를 끌어 낼수 있으며, 다른 종류의 어노테이션을 통해서 테스트하는 클래스에서 다양한 조건을 구현 할 수 있다.

org.junit.runner.RunWith


org.junit.runners.Suite

또한 단위 테스트 진행간 다른 클래스들과의 연결을 통해서 테스트를 하는 경우가 발생할 수 있다. 이를 위해 존재하는 어노테이션도 있으니 후에 어떤 식의 테스트가 필요한지에 따라 확인 하고 이용할 필요가 있다. (명칭이 적절하다보니 대부분이 이해하기 쉬운것 같다)

복잡해 질수록 이런 작업이 필요한 것 같다. 번거롭더라도 나중에 일터져서 피곤해지는 것보다는 예방이 훨씬 낫지 않은가

참고 및 영감을 주심 : http://www.nextree.co.kr/p11104/


Tags
이 댓글을 비밀 댓글로

티스토리 툴바