2007/06/13 01:12 Developer
junit vs main
(업데이트 중)
Junit VS main
http://www.okjsp.pe.kr/seq/97629
OKJSP에 다음과 같은 글이 올라왔다. 덧글을 달아서 이것저것 설명을 하는 것보다 블로그에 포스팅을 해서 남기는 것이 더 좋다는 생각이 들어서 링크를 가져와서 이야기를 해본다.
위에 글에 덧글에는 테스트케이스를 만들거냐? 안 만들거냐?에 대한 문제까지 거론이 되어서 그것은 다른 포스트에 적기로 하고, 가장 원론적인 이야기는 반드시 필요한 부분은 테스트를 만들어야 한다는 가정하에 생각을 해보자.
기본적으로 테스트라는 것은 로직에 대한 처리가 잘되어 있는 가에 대한 처리가 대부분이다. 어떤 모델에 dependency를 주입한 다음 원하는 행위를 했을 때 기대하는 값이나 행위를 하게 되면 true 가 되는 것이다.
main으로 해서 만들 경우는 위와 같은 로직을 구현하기에는 쉽지 않고, 중복된 코드들이 많이 발생을 할 것이다. 그리고, 클래스 갯수가 많아지면 일일이 찾아다니면서 run을 하기도 힘들고, 에러가 발생한 경우도 찾기도 어렵다. 물론 테스트를 위한 유틸 클래스를 만들어서 사용을 해도 되겠지만, 그 역할을 하는 것이 바로 junit이다.
이런 단점을 훌륭하게 해결하는 있는 것이 junit이다. 클래스 작성도 무척 간단하고, run도 쉽다. 이클립스에서 사용할 한 다면, 너무나 편리하다는 생각이 든다.
테스트케이스가 많아지는 경우의 해결방법은 TestSuite이 있다. junit은 composite pattern을 적용해서 테스트케이스가 많아져서 클래수 갯수가 증가를 하더라도 테스트 클래스들을 관리할 수가 있다.(손쉽게 전체 테스트 배치를 실행시에 넣었다가 뺄수도 있다). 에러가 나면 위치를 정확히 알려주고, assertXX를 이용하면 디버깅도 가능하다.
여러가지 필요한 메소드들을 미리 구현을 다 해두어서 API 를 쉽게 사용을 할수가 있다.
내가 자주사용하는 메소드는 assertTrue , assertEquals , assertNotEquals , assertSame , assertNull, assertNotNull 등등이다. 이런 메소드가 없다면 일일이 다 구현을 해서 사용을 했을 것이고, 중복코드도 많이 발생을 했을 것이다.
main으로 테스트 클래스를 만들었을 경우의 단점을 xunit은 상당히 훌륭한 디자인으로 해결을 해내었다. 보너스로 spring을 이용하는 사람들은 DB integration test를 쉽게 할수가 있다. 이것 역시 junit을 확장을 한 것으로 일관된 API사용이 가능하다.
좀더 마음을 열고 junit을 사용해보자. 조금만 시간이 지나면, 이리 좋은 것을 이제야 알았을까라는 생각이 절로 들것이다.
개발자 단위 테스트를 용이하게 하는 삼총사가 있다.
- xunit
- mock
- spring
PS.
여전히 테스트케이스 작성이 미더운 분들을 위해서 시간이 날때 테스트케이스가 중요한 이유와 테스트케이스 작성사례를 정리해서 포스팅을 하도록 하겠다.
Junit VS main
http://www.okjsp.pe.kr/seq/97629
OKJSP에 다음과 같은 글이 올라왔다. 덧글을 달아서 이것저것 설명을 하는 것보다 블로그에 포스팅을 해서 남기는 것이 더 좋다는 생각이 들어서 링크를 가져와서 이야기를 해본다.
위에 글에 덧글에는 테스트케이스를 만들거냐? 안 만들거냐?에 대한 문제까지 거론이 되어서 그것은 다른 포스트에 적기로 하고, 가장 원론적인 이야기는 반드시 필요한 부분은 테스트를 만들어야 한다는 가정하에 생각을 해보자.
기본적으로 테스트라는 것은 로직에 대한 처리가 잘되어 있는 가에 대한 처리가 대부분이다. 어떤 모델에 dependency를 주입한 다음 원하는 행위를 했을 때 기대하는 값이나 행위를 하게 되면 true 가 되는 것이다.
main으로 해서 만들 경우는 위와 같은 로직을 구현하기에는 쉽지 않고, 중복된 코드들이 많이 발생을 할 것이다. 그리고, 클래스 갯수가 많아지면 일일이 찾아다니면서 run을 하기도 힘들고, 에러가 발생한 경우도 찾기도 어렵다. 물론 테스트를 위한 유틸 클래스를 만들어서 사용을 해도 되겠지만, 그 역할을 하는 것이 바로 junit이다.
이런 단점을 훌륭하게 해결하는 있는 것이 junit이다. 클래스 작성도 무척 간단하고, run도 쉽다. 이클립스에서 사용할 한 다면, 너무나 편리하다는 생각이 든다.
테스트케이스가 많아지는 경우의 해결방법은 TestSuite이 있다. junit은 composite pattern을 적용해서 테스트케이스가 많아져서 클래수 갯수가 증가를 하더라도 테스트 클래스들을 관리할 수가 있다.(손쉽게 전체 테스트 배치를 실행시에 넣었다가 뺄수도 있다). 에러가 나면 위치를 정확히 알려주고, assertXX를 이용하면 디버깅도 가능하다.
여러가지 필요한 메소드들을 미리 구현을 다 해두어서 API 를 쉽게 사용을 할수가 있다.
내가 자주사용하는 메소드는 assertTrue , assertEquals , assertNotEquals , assertSame , assertNull, assertNotNull 등등이다. 이런 메소드가 없다면 일일이 다 구현을 해서 사용을 했을 것이고, 중복코드도 많이 발생을 했을 것이다.
main으로 테스트 클래스를 만들었을 경우의 단점을 xunit은 상당히 훌륭한 디자인으로 해결을 해내었다. 보너스로 spring을 이용하는 사람들은 DB integration test를 쉽게 할수가 있다. 이것 역시 junit을 확장을 한 것으로 일관된 API사용이 가능하다.
좀더 마음을 열고 junit을 사용해보자. 조금만 시간이 지나면, 이리 좋은 것을 이제야 알았을까라는 생각이 절로 들것이다.
개발자 단위 테스트를 용이하게 하는 삼총사가 있다.
- xunit
- mock
- spring
PS.
여전히 테스트케이스 작성이 미더운 분들을 위해서 시간이 날때 테스트케이스가 중요한 이유와 테스트케이스 작성사례를 정리해서 포스팅을 하도록 하겠다.
