.jar 라이브러리를 내용이 아닌 "참조"로 테스트합니다.

Question

제 3 자 응용 프로그램을 사용할 필요가 있습니다. 불행히도이 타사 응용 프로그램이 설정된 방식으로 내 Windows에서 테스트 할 수없는 경우가 많습니다. 상자 (유닉스 환경을 위해 설정 되었기 때문에 - 나는 세부 사항을 남겨 둘 것이다). 그래서 그것을 테스트 할 수 있도록 리팩터링했습니다 (인터페이스 파일을 변경하지 않고 속성 파일 처리가보다 유연하도록 maven/spring을 사용하도록 구조가 변경되었습니다). 새 버전이 동일한 .jar 이름/버전/etc로 컴파일되는 경우 아마도 로컬에서 테스트 한 다음 생산을 위해 "실제".jar로 컴파일 할 수 있습니다. 이것은 사기스러운 생각입니까? (나는 그것이 사소한 의존성을 도입하고 있기 때문에 강한 느낌을 가지고있다 ...). 그렇다면 어떻게하면이 라이브러리를 더 잘 테스트 할 수 있습니까? 예를 들어 리팩토링 변경 사항을 원본 코드에 병합하지 않아도됩니까?

Answer 1

개념적으로 타사 jar를 속성 비트와 나머지 두 가지로 세분했습니다. 속성 비트를 자신의 것으로 바꾸고 나머지는 테스트합니다. 공개 된 시점에 테스트 한 비트와 원래 갖고 있지 않은 패키지를 준비합니다. 이 접근 방식을 취할 때 어떤 위험 요소를 도입 했습니까?

1. 당신이 해제 코드가되지 않습니다 당신이 테스트 코드 -이주의 과정이기는하지만,하지 매우 다른 JAR 다른 JAR이다 - 그래서 당신이 그것을 얻을 자신을 신뢰하는 경우 바로이 수용 가능한 위험 할 수있다.
2. 테스트하지 않은 코드가 손상되었습니다. 이것은 실제 플랫폼에서 적어도 일부 테스트가 필요하다는 것을 나타냅니다.
3. Windows에서의 테스트 결과가 Unix에서의 테스트 결과와 다르다는 것을 알았습니다. 다시 한번 어느 정도의 유닉스 테스트가 표시됩니다.

당신의 appraoch는 실용적이며 유닉스에서 적어도 일부 테스트를 실행하면 위험이 완화 될 수 있다고 생각합니다. 필자는 Windows 기반 테스트가 개발/디버깅의 용이성을 전제로한다고 가정합니다. 나는 이것을 할 것이지만 유닉스에서 실행할 수있는 회귀 테스트 스위트를 만들려고한다. JUnit 테스트가 거기에서 실행될 수있다.