테스트하기 위해 비공개 방법을 공개하는 것... 좋은 생각인가?
의장 참고:여기에 이미 39개의 답변이 올라와 있다(일부는 삭제됐다).답변을 게시하기 전에 토론에 의미 있는 내용을 추가할 수 있는지 여부를 고려하십시오.너는 다른 사람이 이미 한 말을 그저 반복하고 있을 것 같다.
나는 가끔 그것을 위한 단위 시험을 작성하기 위해서 수업 시간에 공개적인 방법을 만들어야 하는 나를 발견한다.
보통 이것은 그 방법이 학급 내의 다른 방법들 사이에 공유된 논리를 포함하고 있고 스스로 그 논리를 테스트하는 것이 더 깔끔하기 때문이거나, 또는 스레딩 문제를 걱정하지 않고 동기식 스레드에 사용되는 논리를 테스트하고 싶기 때문에 또 다른 이유가 가능할 수 있다.
다른 사람들은 이런 일을 하는 것을 싫어하기 때문에 스스로 이런 일을 하는 것을 발견할까?나는 개인적으로 보너스가 수업 이외의 어떤 서비스도 제공하지 않는 방법을 공개하는 문제를 능가한다고 생각한다.
갱신하다
모든 사람들의 대답에 감사드리며, 사람들의 흥미를 자극한 것 같다.나는 이것이 수업이 사용되는 유일한 방법이기 때문에 공공 API를 통해 시험을 해야 한다는 일반적인 공감대가 형성되어야 한다고 생각한다. 그리고 나는 이것에 동의한다.위에서 언급한 몇 가지 사례들은 내가 위에서 이런 일을 하게 되는 흔치 않은 경우였고 나는 그것을 하는 것의 이점이 가치가 있다고 생각했다.
그러나 나는 그것이 절대 일어나서는 안 된다는 모든 요점을 볼 수 있다.그리고 그것을 조금 더 생각할 때, 나는 시험을 수용하기 위해 코드를 바꾸는 것은 좋지 않은 생각이라고 생각한다. 내 생각에 시험이 어떤 면에서 지원 도구라고 생각하고, 원한다면 시스템을 '지원 도구'로 바꾸는 것은 명백한 나쁜 관행이다.
참고:
이 답은 원래 유닛 테스트만으로 개인 인스턴스 변수를 Getter를 통해 노출할 수 있는 좋은 이유가 있는가라는 질문에 게시되었다. 이것과 합쳐졌으니, 거기에 제시된 사용 사례에 좀 특이할 수도 있다.
일반적으로, 나는 시험하기 쉽도록 "생산" 코드를 리팩터링하는 것에 찬성한다.하지만, 나는 그것이 여기서 좋은 결정이 될 것이라고 생각하지 않는다.좋은 단위 시험(보통)은 수업의 실행 세부사항에 신경 쓰지 말고, 수업의 가시적인 행동에만 신경써서는 안 된다.내부 스택을 테스트에 노출하는 대신, 클래스가 전화한 후 예상한 순서대로 페이지를 반환하는지 테스트할 수 있다.first()또는last().
예를 들어 다음과 같은 유사 코드를 고려하십시오.
public class NavigationTest {
private Navigation nav;
@Before
public void setUp() {
// Set up nav so the order is page1->page2->page3 and
// we've moved back to page2
nav = ...;
}
@Test
public void testFirst() {
nav.first();
assertEquals("page1", nav.getPage());
nav.next();
assertEquals("page2", nav.getPage());
nav.next();
assertEquals("page3", nav.getPage());
}
@Test
public void testLast() {
nav.last();
assertEquals("page3", nav.getPage());
nav.previous();
assertEquals("page2", nav.getPage());
nav.previous();
assertEquals("page1", nav.getPage());
}
}
개인적으로, 나는 공용 API를 사용하여 단위 테스트를 하는 것이 더 낫고, 나는 단지 테스트하기 쉽게 하기 위해 절대 사적인 방법을 공개하지 않을 것이다.
개인 방법을 분리하여 테스트하려면 Java에서 Easymock/Powermock을 사용하여 이 작업을 수행할 수 있다.
너는 그것에 대해 실용적이어야 하고 왜 사물이 시험하기 어려운지에 대해서도 알아야 한다.
'시험에 귀를 기울이시오' - 테스트가 어렵다면, 그것이 당신의 디자인에 대해 말해주는 것인가?이 방법에 대한 테스트가 사소한 부분이고 public api를 통한 테스트로 쉽게 다루어질 수 있는 곳으로 리팩터링 할 수 있는가?
'레거시 코드로 효과적으로 작업'에서 Michael Firds는 다음과 같이 말한다.
"많은 사람들이 이 문제를 어떻게 극복해야 할지 고민하는데 많은 시간을 보낸다.진짜 답은, 만약 당신이 사적인 방법을 시험하고 싶은 충동이 있다면, 그 방법은 사적인 것이 되어서는 안 되며, 만약 그 방법을 대중에게 귀찮게 만든다면, 그것은 그것은 별도의 책임의 일부이기 때문에, 그것은 다른 계급에 있어야 하기 때문이다.] [기존의 코드와 효과적으로 작업하기 (2005) M.깃털]
다른 사람들이 말했듯이, 민간 구현 세부사항이 아닌 공공 인터페이스를 시험하는 것은 민간 테스트 방법일 가능성이 있다.
그렇기는 하지만, C#에서 사적인 것을 시험하고 싶을 때 사용하는 기법은 접근성 보호를 비공개에서 내부로 다운그레이드한 다음, 장치 시험 어셈블리를 InternalVisibleTo를 사용하여 친구 어셈블리로 표시하는 것이다.유닛 테스트 어셈블리는 그 후에 공공으로 취급할 수 있도록 허용될 것이지만, 공공 표면적에 우발적으로 추가되는 것을 걱정할 필요는 없다.
많은 답변들은 공공 인터페이스를 시험하는 것 만을 제안하지만 IMHO 이것은 비현실적이다 - 만약 방법이 5단계를 하는 것을 한다면, 당신은 그 5단계를 모두 함께 시험하는 것이 아니라 별도로 시험하기를 원할 것이다.이를 위해서는 5가지 방법을 모두 시험해야 하는데, (시험 이외의) 방법은 그렇지 않을 수 있다.private.
"개인적인" 방법을 테스트하는 일반적인 방법은 모든 클래스에 자체 인터페이스를 제공하고 "개인적인" 방법을 만드는 것이다.public, 그러나 인터페이스에 포함시키지 않는다.이런 식으로, 그것들은 여전히 시험될 수 있지만, 인터페이스를 부풀리지는 않는다.
그래, 이렇게 되면 파일럿과 클라스블로의 결과가 나올 거야.
네, 이렇게 하면public그리고private지정자 중복
그래, 이건 골칫거리야.
불행하게도 이것은 코드를 시험하기 위해 우리가 하는 많은 희생들 중 하나이다.아마도 미래 언어(또는 심지어 미래 버전의 C#/Java)는 클래스 및 모듈 테스트 가능성을 더 편리하게 만드는 특징을 가질 것이다; 그러나 한편, 우리는 이러한 후프를 통과해야 한다.
몇몇 사람들은 그 단계들이 각각의 계급이 되어야 한다고 주장하겠지만, 나는 동의하지 않는다 - 그들 모두가 국가를 공유한다면, 다섯 가지 방법이 할 수 있는 다섯 개의 개별적인 계층을 만들 이유가 없다.더 나쁜 것은, 이것은 파일럿과 클래스블로의 결과를 낳는다.또한 모듈의 공용 API를 감염시키므로 모든 클래스는 반드시public다른 모듈에서 테스트하려는 경우(또는 테스트 코드를 제품과 함께 배송한다는 의미인 동일한 모듈에 테스트 코드를 포함하거나 포함).
단위 시험은 코드의 다른 부분에서 클래스를 사용할 수 있는 유일한 방법인 공공 계약을 시험해야 한다.개인 방법은 구현 세부사항이며, 테스트해서는 안 된다. 공용 API가 올바르게 작동하는 한 구현은 중요하지 않으며 테스트 사례의 변경 없이 변경될 수 있다.
IMO, 당신은 당신의 수업이 어떻게 내부에서 구현되는지에 대해 깊은 가정을 하지 말고 당신의 테스트를 작성해야 한다.나중에 다른 내부 모델을 사용하여 이 모델을 리팩터링하지만 이전 구현에서 제공하는 것과 동일한 보증을 만들고자 할 것이다.
이 점을 명심하고, 나는 당신이 당신의 학급이 현재 어떤 내부 구현을 가지고 있든 간에 당신의 계약이 여전히 유효하다는 것을 테스트하는 데 초점을 맞출 것을 제안한다.공용 API의 속성 기반 테스트.
소포를 비공개로 하는 게 어때?그러면 테스트 코드가 해당 코드(및 패키지의 다른 클래스도 표시됨)를 볼 수 있지만 사용자에게는 여전히 숨겨져 있다.
하지만 정말로, 당신은 사적인 방법을 시험하지 말아야 한다.그것들은 이행 세부사항이지 계약의 일부가 아니다.그들이 하는 모든 일은 공공의 방법(공공의 방법에 의해 행사되지 않는 코드가 그 안에 있다면, 그렇게 해야 한다)을 부르는 것으로 덮어야 한다.만약 사설코드가 너무 복잡하다면, 수업은 아마도 너무 많은 일들을 하고 있고 리팩터링을 필요로 할 것이다.
방법을 공개하는 것은 큰 헌신이다.일단 그렇게 하면 사람들은 그것을 사용할 수 있을 것이고, 더 이상 그냥 바꿀 수는 없다.
업데이트: 나는 이 질문에 대해 다른 많은 곳에서 더 확장되고 더 완전한 답변을 추가했다. 이것은 내 블로그에서 찾을 수 있다.
만약 내가 그것을 시험하기 위해 무언가를 공개해야 한다면, 이것은 보통 시험 중인 시스템이 단일 책임 원칙을 따르지 않고 있다는 것을 암시한다.그러므로 도입되어야 할 누락된 수업이 있다.코드를 새로운 클래스로 추출한 후 공개하십시오.이제 당신은 쉽게 테스트할 수 있고 SRP를 따르고 있다.당신의 다른 클래스는 단지 작문을 통해 이 새로운 클래스를 호출해야 한다.
방법을 공개/시험 어셈블리에 보이는 코드 표시와 같은 랭귀지 속임수를 사용하는 것은 항상 마지막 수단이 되어야 한다.
예를 들면 다음과 같다.
public class SystemUnderTest
{
public void DoStuff()
{
// Blah
// Call Validate()
}
private void Validate()
{
// Several lines of complex code...
}
}
검증자 개체를 도입하여 이를 리팩터링하십시오.
public class SystemUnderTest
{
public void DoStuff()
{
// Blah
validator.Invoke(..)
}
}
이제 우리가 해야 할 일은 검증자가 올바르게 작동하는지 테스트하는 것이다.검증의 실제 프로세스(이전의 사설 논리)는 순수한 분리 속에서 시험할 수 있다.이 유효성 검사를 통과하기 위해 복잡한 테스트 설정이 필요하지 않을 것이다.
훌륭한 해답이네.한 가지 언급되지 않은 것은 테스트 주도 개발(TDD)을 통해 리팩터링 단계(리팩터링 패턴의 예에 대한 추출 방법 보기) 중에 프라이빗 메서드가 생성되므로 필요한 테스트 커버리지를 이미 갖추어야 한다는 점이다.만약 제대로 했다면(그리고 물론 정확성에 관해서는 의견이 엇갈릴 것이다), 단지 그것을 시험할 수 있도록 사적인 방법을 공개해야 하는 것에 대해 걱정할 필요는 없다.
만약 당신이 C#를 사용하고 있다면 당신은 내부적으로 메서드를 만들 수 있다.그렇게 하면 당신은 공공 API를 오염시키지 않는다.
그런 다음 dll에 속성을 추가하십시오.
[오피니언:InternalVisibleTo("MyTestAssembly")]
이제 모든 방법을 MyTestAssembly 프로젝트에서 볼 수 있다.완벽하진 않겠지만 테스트하기 위해 사적인 방법을 공개하는 게 좋을 거야
스택 관리 알고리즘을 유틸리티 클래스로 분할하는 것은 어떨까?유틸리티 클래스는 스택을 관리하고 공용 접근자를 제공할 수 있다.그것의 단위 시험은 구현 세부사항에 초점을 맞출 수 있다.알고리즘적으로 까다로운 클래스에 대한 심층 테스트는 가장자리 케이스를 주름내고 커버리지를 보장하는 데 매우 도움이 된다.
그러면 현재 클래스가 구현 세부 정보를 노출하지 않고 유틸리티 클래스에 깔끔하게 위임할 수 있다.이 테스트는 다른 사용자가 권장한 페이지 지정 요건에 관련된다.
자바에서는 패키지를 비공개로 하는 옵션도 있다(가시성 수식어를 생략함).장치 테스트가 테스트되는 클래스와 동일한 패키지에 있는 경우 이러한 방법을 볼 수 있어야 하며, 이 방법을 완전히 공개하는 것보다 약간 안전하다.
사적인 방법은 보통 "도움말" 방법으로 사용된다.따라서 그들은 기본 값만 반환하고, 개체의 특정 인스턴스에서는 절대 작동하지 않는다.
테스트하고 싶다면 몇 가지 옵션이 있다.
- 반사 사용
- 메소드 패키지 액세스 권한 부여
또는 새로운 클래스에 적합한 경우 도우미 방법을 공개 방법으로 사용하여 새 클래스를 만들 수 있다.
필요한 경우 반사를 사용하여 개인 변수에 액세스하십시오.
하지만 정말로, 여러분은 수업의 내부 상태에 대해 신경쓰지 않고, 단지 공공적인 방법들이 여러분이 예상할 수 있는 상황에서 여러분이 기대하는 것을 되돌려준다는 것을 시험하고 싶을 뿐이다.
업데이트에서 당신은 공용 API를 사용하여 테스트하는 것이 좋다고 말한다.사실 여기에는 두 개의 학교가 있다.
블랙박스 테스트
블랙박스 스쿨은 이 수업을 아무도 그 안에서 구현을 볼 수 없는 블랙박스로 간주해야 한다고 말한다.이것을 테스트할 수 있는 유일한 방법은 공용 API를 통해서 입니다. 마치 수업의 사용자들이 그것을 사용하는 것처럼.
화이트 박스 테스트
화이트박스 스쿨은 수업 시행에 대한 지식을 자연스럽게 활용하고, 그 다음, 수업 내용이 제대로 작동하는지 시험해 보는 것이 당연하다고 생각한다.
나는 정말 그 토론에 참여할 수 없다.나는 단지 한 학급(또는 도서관이나 그 밖의 다른 것)을 시험하는 두 가지 뚜렷한 방법이 있다는 것을 알면 흥미로울 것이라고 생각했다.
단위 테스트의 관점에서, 당신은 분명히 더 많은 방법을 추가해서는 안 된다. 나는 당신이 당신의 방법에 대해 시험 케이스를 만드는 것이 좋을 것이라고 믿는다.first()매번 할 수 그 엔 여러 번 그런 다음 여러 번 호출할 수 있는 -next()previous()그리고last()결과가 예상과 일치하는지 알아보는 거야만약 당신이 당신의 수업에 더 많은 방법을 추가하지 않는다면, 당신은 시험의 "블랙박스" 원칙을 고수할 것이다.
절대 당신의 테스트가 당신의 코드를 지시하게 해서는 안 된다.나는 TDD나 다른 DD에 대해 말하는 것이 아니다. 정확히 네가 묻는 것을 말하는 것이다.당신의 앱이 공개되기 위해 그러한 방법들이 필요한가?만약 그렇다면, 그들을 시험해봐.만약 그렇지 않다면, 테스트만을 위해 그들을 공개하지는 마라.변수나 다른 것도 마찬가지야.응용 프로그램의 니즈가 코드를 지시하도록 하고, 니즈가 충족되었는지 테스트하도록 한다. (Ang I mean testing or not testing or not testing testing or not mean I mean mean testing testing 목표를 충족하기 위해 클래스 구조를 변경하는 것을 의미하지 않는다.)
대신 "더 높은 시험"을 해야 한다.개인 메서드를 호출하는 메서드를 테스트하십시오.그러나 테스트는 "구현 결정"이 아니라 애플리케이션 요구사항을 테스트하는 것이어야 한다.
예: (여기서는 유사 코드);
public int books(int a) {
return add(a, 2);
}
private int add(int a, int b) {
return a+b;
}
대신 "책"을 테스트할 수 있는 "추가"를 테스트할 이유가 없다.
절대 테스트가 코드 설계 결정을 내리지 않도록 하십시오.어떻게 그 결과를 얻느냐가 아니라 기대한 결과를 얻는지 시험해 보라.
나는 그것이 나쁜 생각이라고 말하고 싶다. 나는 당신이 어떤 혜택과 잠재적으로 문제가 발생할지 확신할 수 없다.만약 당신이 사적인 방법을 시험하기 위해 전화의 계약을 바꾸는 것이라면, 당신은 그것이 어떻게 사용될 것인가에 대한 수업을 테스트하는 것이 아니라, 당신이 결코 의도하지 않았던 인위적인 시나리오를 만드는 것이다.
게다가, 그 방법을 공개로 선언함으로써, 6개월 안에(어떤 방법을 공개하는 유일한 이유가 시험용이라는 것을 잊어버린 후) 누군가 완전히 다른 사람이 그것을 사용하지 않을 것이고, 이로 인해 의도하지 않은 결과나/또는 유지보수의 악몽이 발생할 가능성이 있다.
먼저 그 방법이 다른 등급으로 추출되어 공개되어야 하는지 살펴라.그렇지 않으면 패키지를 보호하고 Java에서 @VisibleForTesting으로 주석을 달도록 하십시오.
실제로 이렇게 해야 하는 상황(예: 복잡한 알고리즘을 구현하는 경우)이 있다.그냥 패키지-프라이빗으로 하면 충분할 거야.그러나 대부분의 경우 당신은 다른 수업으로 논리를 고려해야 하는 너무 복잡한 수업을 듣게 될 것이다.
고립된 상태에서 테스트하고자 하는 사적인 방법은 당신의 클래스에 또 다른 "개념"이 있다는 것을 나타낸다.그 "개념"을 자체 등급으로 추출하여 별도의 "단위"로 시험한다.
이 비디오에서 그 주제에 대해 정말 흥미로운 이야기를 들어봅시다.
나는 그것을 시험해 보는 보너스가 일부 회원의 가시성을 높이는 문제를 능가한다는 것에 동의하는 경향이 있다.약간의 개선은 보호되고 가상화된 후 테스트 클래스에서 오버라이드하여 노출시키는 것이다.
또는 별도로 테스트하려는 기능인 경우 설계에서 누락된 객체를 제안하지 않는가?다른 시험 가능한 수업에 넣어줄 수 있을 것 같은데...기존 클래스는 이 새로운 클래스의 한 인스턴스에 위임하십시오.
나는 일반적으로 시험 수업을 시험 대상 수업과 동일한 프로젝트/조립으로 유지한다.
이 방법은 내게 필요한 것뿐이다.internal기능/실증을 테스트할 수 있는 가시성.
이것은 테스트 클래스를 걸러내야 하는 당신의 건축 과정을 다소 복잡하게 만든다.나는 모든 시험 수업의 이름을 지음으로써 이것을 성취한다.TestedClassTest그리고 이 클래스를 필터링하기 위해 정규식을 사용하여 클래스를 필터링하십시오.
이것은 물론 C# / .에만 적용된다.질문의 NET 부분
나는 종종 다음과 같은 방법을 추가할 것이다.validateverifycheck, 등 물체의 내부 상태를 테스트하기 위해 호출할 수 있는 클래스로.
때때로 이 방법은 ifdef 블록(대부분 C++로 쓴다)으로 포장되어 출시용으로 컴파일되지 않는다.그러나 프로그램 대상 트리가 사물을 확인하는 과정을 거치는 검증 방법을 제공하는 것이 종종 출시에서 유용하다.
Guava는 @VisibleForTesting 주석을 가지고 있는데, 다른 방법으로는 확대된 범위(패키지 또는 공개)를 표시하는 방법이 있다.나는 같은 것에 @Private 주석을 사용한다.
공개 API를 테스트해야 하지만, 보통 공개되지 않는 것을 사용하는 것이 편리하고 현명할 때도 있다.
다음 경우:
- 한 클래스는 여러 클래스로 나누어 읽기가 훨씬 더 어려워진다.
- 좀 더 테스트할 수 있게 하기 위해서
- 그리고 내장에 대한 테스트 접근 권한을 제공하면
종교가 공학을 능가하는 것 같다.
나는 보통 그 방법들을 다음과 같이 남겨둔다.protected그리고 클래스 로더가 동일한 네임스페이스 내에 배치하기 때문에 모든 보호된 방법에 액세스할 수 있는 동일한 패키지(그러나 다른 프로젝트 또는 원본 폴더) 내에 장치 테스트를 배치한다.
아니, 그 고양이 가죽을 벗기는 더 좋은 방법이 있기 때문이야.
일부 장치 테스트 하니스는 클래스 정의에서 매크로에 의존하며, 이 매크로는 테스트 모드로 구축될 때 자동으로 훅을 생성하기 위해 확장된다.아주 C 스타일인데, 효과가 있어.
더 쉬운 OO 관용구는 테스트하고 싶은 모든 것을 "개인적인" 것이 아니라 "보호된" 것으로 만드는 것이다.테스트 하니스는 테스트 대상 클래스에서 상속받으며, 그런 다음 모든 보호 멤버에 접근할 수 있다.
아니면 "친구" 선택권을 가지던가.개인적으로 이것은 캡슐화 규칙을 어겨서 내가 가장 싫어하는 C++의 특징이지만, C++가 어떤 기능을 구현하는 데 필요한 경우가 있으니 Hey ho.
어쨌든, 만약 당신이 유닛 테스트를 한다면, 당신은 그 멤버들에게 값을 주입할 필요가 있다.화이트 박스 문자는 완벽하게 유효하다.그렇게 하면 네 캡슐이 깨질 거야
.Net에는 라는 특별한 클래스가 있다.PrivateObject클래스의 개인 메서드에 액세스할 수 있도록 특별히 지정됨.
자세한 내용은 MSDN 또는 스택 오버플로에서 확인하십시오.
(지금까지 아무도 언급하지 않은 것이 궁금하다.)
비록 이것이 충분하지 않은 상황들이 있지만, 그 경우 당신은 반성을 사용해야 할 것이다.
그래도 나는 사적인 방법을 시험하지 말라는 일반적인 권고를 고수할 것이다. 그러나 언제나 예외는 있다.
단위 시험의 포인트는 해당 단위에 대한 공개 api의 작업을 확인하는 것이다.시험용으로만 노출되는 전용 방법을 만들 필요가 없어야 한다. 그렇다면 인터페이스가 다시 고려되어야 한다.개인 방법은 공공 인터페이스에 '도움이 되는' 방법으로 생각할 수 있으며, 따라서 개인 방식을 호출할 때처럼 공공 인터페이스를 통해 시험한다.
네가 이렇게 해야 할 필요가 있다는 것을 내가 알 수 있는 유일한 이유는 네 수업이 시험을 염두에 두고 제대로 설계되지 않았기 때문이야.
다른 사람들의 논평에서 광범위하게 지적되었듯이, 단위 테스트는 공개 API에 초점을 맞추어야 한다.단, 프로/컨설팅과 정당성은 차치하고, 반성을 이용하여 단위 테스트에서 개인 방법을 호출할 수 있다.물론 JRE 보안이 그것을 허용하는지 확인해야 할 것이다.개인 메서드를 호출하는 것은 Spring Framework가 자사의 ReflectionUtils와 함께 사용하는 것이다(참조).makeAccessible(Method)방법.
다음은 개인 인스턴스(instance) 방법을 사용한 작은 예시 클래스 입니다.
public class A {
private void doSomething() {
System.out.println("Doing something private.");
}
}
그리고 개인 인스턴스 메서드를 실행하는 예제 클래스.
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
public class B {
public static final void main(final String[] args) {
try {
Method doSomething = A.class.getDeclaredMethod("doSomething");
A o = new A();
//o.doSomething(); // Compile-time error!
doSomething.setAccessible(true); // If this is not done, you get an IllegalAccessException!
doSomething.invoke(o);
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
} catch (SecurityException e) {
e.printStackTrace();
}
}
}
B 실 print 중 인 인 인쇄Doing something private.만약 당신이 정말로 필요하다면, 개인 인스턴스 방법에 접근하기 위해 장치 테스트에서 반사를 사용할 수 있다.
참조URL: https://stackoverflow.com/questions/7075938/making-a-private-method-public-to-unit-test-it-good-idea
'IT이야기' 카테고리의 다른 글
| 메이븐이 JDK 1.6을 사용하는 이유 그러나 내 자바버전은 1.7이다. (0) | 2022.04.29 |
|---|---|
| 모듈 구문 분석 실패:예기치 않은 문자 '@'(1:0) vuejs, vuetify 및 vuex (0) | 2022.04.29 |
| Java에서 int가 null일 수 있는가? (0) | 2022.04.29 |
| Mocha 단위 테스트에서 이름에 접근하는 방법이 Vuex getter를 능가했다. (0) | 2022.04.29 |
| 개체의 클래스를 결정하는 방법 (0) | 2022.04.29 |