JUnit의 테스트 메소드는 왜 public이어야 할까요?

[Toby Lee]

JUnit은 스프링의 동반자, 스프링 사용자의 필수 도구이죠. 

JUnit의 테스트 메소드는 모두 public이어야 합니다. 왜 JUnit 테스트 메소드는 public 이어야 한다고 생각하시나요?

기술적인 복잡한 얘기는 아니니까, 편하게 각자 생각 또는 의견을 얘기해보세요.

[디키]

^^ 기술적인 내용이 아니라고 하시니.. 왠지 넌센스 문제 같기도 합니다만...

첫째. JUnit에서 refelction을 이용해서 TestCase/TestSuite의 test메소드를 가져옵니다.
이 리플렉션은 public메소드만 가져올 수 있으므로 기술적으로는 무조건 public이어야 하죠. 이는 기술적인 내용이구여;;

둘째. Test는 운영코드만큼(운영코드가 수정될때마다) 계속 수정되어야 합니다. 따라서 public으로 해놓는 것이
strategy와 template 두가지 방법 모두로 확장 가능합니다. 이는 지극히 개인적인 의견입니다. ^^

[Green]

private method들은 어차피 public method들에 의해 호출되어 지니까 public method들을 테스트하면 되지 궃이 private method들을 테스트할 필요가 없을 것 같구요..

또한 잘 짜여진 클래스들에는 많은 수의 private 메소드들이 있을테니까 그것을 전부 다 테스트하기에는 

번거로울 것 같고 private은 수정이 빈번히 이루어지니까 수정할때마다 테스트하기에는 시간이 많이 소요됩니다. 

상식적인 수준에서 생각해봤습니다.

더 중요한 무엇인가가 있을 것 같은데요..^^

2009년 5월 31일 (일) 오전 1:01, 디키 <dik...@gmail.com>님의 말:

--
mingyu oh
Anoter E-Mail : gr...@mail.ponsi.co.kr
SIMPLE IS BEST!!

[박성철]

처음에 질문을 보고는 junit4 이후의 애노테이션 방식으로 바뀐 후에도 public으로 제한하는 이유를 물어보신 줄 알았는데
생각해보니 그 전에도 어짜피 리플렉션을 썼으니 전이나 후나 굳이 public일 필요가 없네요.

역시나 깊이 생각않고 떠오르는 것들을 적어보면 ( ^^ )

1) 관례, 일관성 : xUnit의 관례상 test method는 public... 리플렉션 기능이 없어 언어적으로
public method 외에는 접근할 수 없는 경우도 있을 듯
2) 사람이 보기 쉽게 : 프로그램이야 method visibility가 별 상관 없어도 사람은 이런 구분이 코드를 읽는 데 도
움이 되므로
3) 불필요한 security exception 문제를 피하려고 : 종종 VM 보안 설정이 까탈스럽게 되어 있는 경우도
있...
4) 직관적 : 너무나 당연히 public이어야 할 것 같...;;;

너무 궁한가요? ㅋㅋ

모두 활기찬 월요일 되세요.

On 5월30일, 오후4시06분, Toby Lee <tobyi...@gmail.com> wrote:

[낮게 그러나 더 높게]

몇가지를 생각해 보았습니다.

먼저 의미상으로 '테스트'라는 것을 생각해보면..
테스트는 실제 돌아가는 모듈이나 단위 기능들을 점검하여 잘 돌아가는지 이리저리(?) 확인 하기 위한 것이라고 알고 있는데요

만약에 실제로 운용중인 기능들을 모두 테스트 한다고 치면,
구지 테스트를 숨길 필요가 있을까..하는 생각이 듭니다.
테스트 작성자가 테스트를 숨겨놓았다면 아마도 그것은 테스트를 기피하는 부분 이겠거나
아니면 양심 없는 코드를 작성해 놓았기 때문에 테스트를 숨겨놓았을 것입니다.

이렇게 의미상으로 보면 테스트는 모두에게 공개되어야 한다는 의미에서 language측면에서도 public이어야 한다는 생각을 하
고 있구요.

두번째 접근은 리팩토링과 관련된 것입니다.
TDD방법에서는 테스트 코드를 먼저 만들고 실제 클래스를 생성해서 그안에 실제 메소드를 만들게 되죠.
대부분 클래스 안에 제일 처음 만들게 되는 메소드를 private으로 만들진 않는 것 같습니다..
처음부터 private으로 코드를 넣게 된다면 그분은 아마 대단한 실력가가 아닐까 생각합니다.

저는 대게 public으로 메소드를 만들고 필요에 따라서 extract method와 같은 리팩토링 기법을 사용해 중복되는 부분
이나 기능의 분할을 위해서 메소드를 private으로 빼는 습관이 있습니다.

리팩토링 된 private 메소드는 외부에서 직접 호출 하진 않죠(호출하는 방법도 있긴 하지만)
외부에서는 먼저 공개된 public메소드를 호출기준으로 삼고 클래스 내부에 있는 private메소드들는 자연스레 public 메
소드에서 사용 될테니까요. 만약에 클래스 내부에 private메소드가 심하게 있다고 치면 그 클래스는 단일책임원칙에 의해서 잘
설계된 클래스가 아니라고 생각됩니다. 이를테면 분할을 잘못한 구조이거나 procedure스타일로 짜여진 클래스일 가능성이 클
것 같습니다.

이렇듯 테스트는 테스트하기 편한 실제 코드를 좋아한다는 입장에서,
호출할 부분 즉, public메소드를 호출하는 입장에서 테스트 메소드가 private일 필요가 없다고 생각합니다.

이와 비교해서 테스트케이스 안에 메소드들이 public이어야 하는 점도 위와 비슷하게 생각을 해봅니다.
단위 테스트용 클래스들은 잘 분할된 실제 클래스를 테스트 하기 위한 메소드들이지
테스트 케이스안에 private 메소드들을 테스트하기 위한 것은 아닌 것 같습니다.
테스트케이스안에 private 메소드가 있다면 실제로 테스트안에서 리팩토링이 이루어졌다거나 아니면 중복되는 테스트를
private으로 뺐다는 가정이 있으므로, 이 관점에서 생각해 본다면 private 메소드는 테스트 대상이 될 수가 없는 것 같
습니다.

다음은 기술적인 관점입니다.
TestSuit류의 테스트를 하게 되면 한꺼번에 단위 테스트들를 묶어서 테스트하게 되겠죠. 이것도 위에서 설명한 것처럼 외부에
서 호출대상이 되는 부분은 공개 되어진 부분이지 숨어 있는 부분이 아니란 점입니다. 테스트가 숨어있다면 분명 공개된 테스트에서
이미 사용하고 있을 가능성이 크기 때문입니다.

생각나는대로 적으려다가.. 좀 더 생각하고 적었습니당;;;

[Toby Lee]

와.. 다들 아이디어가 대단하시네요. 

그런데 KSUG 운영진만 별 참여가 없군요. 스프링상조회라 JUnit건은 씹히는 건가... :(

한가지 재밌는 사실은 @Test를 붙이거나(4.x), test~로 시작하는 메소드 이름을 사용하지(3.x) 않고, 대신 테스트 클래스 내의 모든 public void method를 자동으로 테스트로 인식하게 하자는 논의도 있었습니다. 하지만 Test클래스가 도메인 클래스를 상속하는 기법을 사용하는 경우에(4.x는 그런게 장점이죠) 곤란하고, 또 테스트 클래스를 구분하기 위한 새로운 애노테이션 (@TestClass 같은)의 도입의 불편함 등의 이유로 실현되지는 않았습니다. 

개인적으로는 타이핑이 귀찮아서 그냥 아무 것도 붙이지 않는 natural access(패키지 프로텍티드라고도 하죠)도 허용했으면 좋겠다 싶은데요. 가끔 public 빼먹어서 테스트 오류 나면 좀 귀찮죠.

2009/6/1 낮게 그러나 더 높게 <para...@paran.com>

[Sanghyuk Jung]

빨간줄의 압박;

 

이미 다른분들이 다 적어주셨지만, 얼릉 떠올랐던 생각은 그냥 TestSuite 같은데서 실행되어야 하니까 public이 직관적이겠다 라는 생각이 드네요; reflection으로 getDeclaredMethod인가 사용하면 private도 호출할 수 있었던 것으로 기억하기 땜에 꼭 reflection을 사용한다고 public이어야 하는 건 아니지 않나 싶구요.
(혹시 이와 관련된 내용도 토비님 책에 들어가나요? ^^;)

2009년 6월 1일 (월) 오후 8:01, Toby Lee <toby...@gmail.com>님의 말:

[Toby Lee]

(혹시 이와 관련된 내용도 토비님 책에 들어가나요? ^^;)

안들어갑니다. :)

그냥 TestSuite 같은데서 실행되어야 하니까 public이 직관적이겠다 라는

 

TestSuite은 composite pattern을 사용해서 Test인터페이스를 통해서 하위(TestCase나 또다른 TestSuite) 호출하기 때문에 개별 테스트 메소드를 직접 호출할 일은 없습니다.

2009/6/2 Sanghyuk Jung <ben...@gmail.com>

[Chung Wan Park]

JUnit의 테스트 메소드가 public인 이유는 아마도 테스트 하고자 하는 모든 사람에게 

열려 있다는 의미 정도 되지 않을까요?

JUnit의 테스트 메소드는 모두에게 오픈되어 모든 개발자들이 테스트 코드를 확인하고

수행할 수 있도록 모든 사람에게 열려있다는 뭐 그런 의미에서 public으로 한 것이 아닐까

생각되네요.

프로젝트 수행 시 JUnit을 이용해서 많은 도움을 받았죠..

프로젝트에 참여했던 사람들이 JUnit소스를 공유 및 보완을 하면서 많은 도움을 받았던 기억이...

JUnit의 테스트 코드는 모든 개발자가 공유해야 하는 의미에서 public이 아닐까요?

2009년 5월 30일 (토) 오후 4:06, Toby Lee <toby...@gmail.com>님의 말:

[강명성]

테스트용이라는 직관성이지 싶네요.

모든 메소드는 void여야 하듯이 다른 클래스나 메소드에서 참조를 하지 않도록 하고

테스트용답게 메소드 안에서 최대한 단순하게 작성하도록 유도하는듯한 느낌입니다.

 

private의 의미는 개방을 하지 않겠다는 의도인데 Junit의 의도와는 전혀 맞지 않고

이런저런 복잡한 테스트를 최대한 지향해서 개발하도록 제한을 둔게 아닌가 싶네요.

 

테스트는 테스트!

2009년 5월 30일 (토) 오후 4:06, Toby Lee <toby...@gmail.com>님의 말:

JUnit은 스프링의 동반자, 스프링 사용자의 필수 도구이죠. 

JUnit의 테스트 메소드는 모두 public이어야 합니다. 왜 JUnit 테스트 메소드는 public 이어야 한다고 생각하시나요?

기술적인 복잡한 얘기는 아니니까, 편하게 각자 생각 또는 의견을 얘기해보세요.

--
매일 행복한 시간 되시길 바랍니다...^^

[윤희한]

언제나 눈팅만 하는데도 참 많은것을 얻어가네요..

저도 공부 열심히 해서 참여하는 사람이 되어야겠어요~~

에효~~ 할게 너무 많지만 하나 하나 천천히 해보렵니다~~

2009년 6월 2일 (화) 오후 1:59, Chung Wan Park <chungw...@gmail.com>님의 말:

[안미라]

=> 언제나 눈팅만 하는데도 참 많은것을 얻어가네요..

동감입니다.

근자에 Spring에 시간을 집중 투하하고 있는데요.

언제쯤 여기에서 오가는 내용을 자~알 이해할 수 있을랑가 몰라도.

용어를 접하는 것 만으로도 왠지 skill up이 되는 듯한 착각이 ㅋㅋ

 

착각이라고 해도 참 좋네요 ㅎㅎ

 

2009년 6월 2일 (화) 오후 3:06, 윤희한 <ryys...@gmail.com>님의 말:

[Toby Lee]

평소에 그냥 원래 그러려니 하고 생각없이 사용하던 것도 한번쯤 왜 그렇게 했을까 의문을 가져보고 생각을 해보는 것은 좋은 습관인듯 합니다.

스프링도 그런 태도를 가지고 기존 기술에 대한 의문을 가지고 고민을 하면서 만들어진 것일테니까요.

JUnit의 개발자들이 밝혔던 테스트 메소드가 public이어야 했던 이유가 있습니다. JUnit은 테스트 클래스의 테스트 메소드를 자바의 reflection api를 이용해서 호출을 해줍니다. Pluggable selector 패턴을 이용했기 때문에 그렇게 했죠. 그런데 JUnit이 처음 만들어지던 때 사용했던 JDK1.1에서는 리플렉션에서 public 메소드만 접근을 허용했습니다. 따라서 JUnit의 테스트 메소드는 모두 public일 수 밖에 없었습니다. 그게 관례가 되서 지금까지 내려온 것입니다.

그런데 JDK1.2부터는 리플렉션에서 public외의 모든 접근레벨을 다 허용하기 시작했습니다. 그래서 심지어 private메소드도 호출하는 것도 가능해졌죠. 심지어 final 변수의 값도 수정이 가능합니다(JDK5이후에는 미리 선언된 상수값으로 final인 경우 코드레벨 최적화 때문에 안되기도 합니다). 

어쨌든 JUnit은 전통을 유지해서 JUnit 4.x에서도 여전히 public 메소드만 테스트로 허용하고 있습니다. 

2009/6/2 안미라 <aclim...@gmail.com>

[낮게 그러나 더 높게]

음.. 그런 히스토리가 있었다니.. 답은 '전통'이였군요.

[박성철]

그게 1.2부터 된 거였군요.
1.2, 1.3 시절에는 거의 자바를 안 했기 때문에 public만 되는 줄로 알고 있다가 private도 되는 것 알고 깜짝
놀랐었어요.
그냥 풀만도 한데 일부러 public인지 확인해서 fail 내 버리는 모습에서 뭔가 배울만한 게 있을 듯 하네요.

좋은 것 하나 또 배웁니다.

On 6월2일, 오후6시38분, Toby Lee <tobyi...@gmail.com> wrote:
> 평소에 그냥 원래 그러려니 하고 생각없이 사용하던 것도 한번쯤 왜 그렇게 했을까 의문을 가져보고 생각을 해보는 것은 좋은 습관인듯
> 합니다.
> 스프링도 그런 태도를 가지고 기존 기술에 대한 의문을 가지고 고민을 하면서 만들어진 것일테니까요.
>
> JUnit의 개발자들이 밝혔던 테스트 메소드가 public이어야 했던 이유가 있습니다. JUnit은 테스트 클래스의 테스트 메소드를
> 자바의 reflection api를 이용해서 호출을 해줍니다. Pluggable selector 패턴을 이용했기 때문에 그렇게 했죠.
> 그런데 JUnit이 처음 만들어지던 때 사용했던 JDK1.1에서는 리플렉션에서 public 메소드만 접근을 허용했습니다. 따라서
> JUnit의 테스트 메소드는 모두 public일 수 밖에 없었습니다. 그게 관례가 되서 지금까지 내려온 것입니다.
>
> 그런데 JDK1.2부터는 리플렉션에서 public외의 모든 접근레벨을 다 허용하기 시작했습니다. 그래서 심지어 private메소드도
> 호출하는 것도 가능해졌죠. 심지어 final 변수의 값도 수정이 가능합니다(JDK5이후에는 미리 선언된 상수값으로 final인 경우
> 코드레벨 최적화 때문에 안되기도 합니다).
>
> 어쨌든 JUnit은 전통을 유지해서 JUnit 4.x에서도 여전히 public 메소드만 테스트로 허용하고 있습니다.
>

> 2009/6/2 안미라 <aclimax....@gmail.com>

>
> > => 언제나 눈팅만 하는데도 참 많은것을 얻어가네요..
> > 동감입니다.
> > 근자에 Spring에 시간을 집중 투하하고 있는데요.
> > 언제쯤 여기에서 오가는 내용을 자~알 이해할 수 있을랑가 몰라도.
> > 용어를 접하는 것 만으로도 왠지 skill up이 되는 듯한 착각이 ㅋㅋ
>
> > 착각이라고 해도 참 좋네요 ㅎㅎ
>

> > 2009년 6월 2일 (화) 오후 3:06, 윤희한 <ryys1...@gmail.com>님의 말:

>
> >> 언제나 눈팅만 하는데도 참 많은것을 얻어가네요..
> >> 저도 공부 열심히 해서 참여하는 사람이 되어야겠어요~~
>
> >> 에효~~ 할게 너무 많지만 하나 하나 천천히 해보렵니다~~
>

> >> 2009년 6월 2일 (화) 오후 1:59, Chung Wan Park <chungwan.p...@gmail.com>님의 말:

>
> >> JUnit의 테스트 메소드가 public인 이유는 아마도 테스트 하고자 하는 모든 사람에게 열려 있다는 의미 정도 되지 않을까요?
> >>> JUnit의 테스트 메소드는 모두에게 오픈되어 모든 개발자들이 테스트 코드를 확인하고
> >>> 수행할 수 있도록 모든 사람에게 열려있다는 뭐 그런 의미에서 public으로 한 것이 아닐까
> >>> 생각되네요.
> >>> 프로젝트 수행 시 JUnit을 이용해서 많은 도움을 받았죠..
> >>> 프로젝트에 참여했던 사람들이 JUnit소스를 공유 및 보완을 하면서 많은 도움을 받았던 기억이...
> >>> JUnit의 테스트 코드는 모든 개발자가 공유해야 하는 의미에서 public이 아닐까요?
>

> >>> 2009년 5월 30일 (토) 오후 4:06, Toby Lee <tobyi...@gmail.com>님의 말: