단위 테스트 절차 코드가 효과적입니까?

현재 프로젝트에서 코드에 스며드는 버그를 피하기 위해 단위 테스트를 개발주기에 통합하려는 능력이 있습니다. 문제는 스파게티 코드가 95 %의 절차 적이며 단위 테스트를 한 적이 없습니다 (단위 테스트에 대한 모든 경험은 OOP 코드에 대한 것입니다)

요컨대, 현재 코드베이스로 단위 테스트를 진행하는 것이 현명한 것인가, 아니면 응용 프로그램이 적절한 OOP 프레임 워크로 마이그레이션 될 때까지 연기되는 것이 좋을까?

추신 :이 질문을 언어에 구애받지 않고 스타일을 지정하려고 시도했지만 문제의 응용 프로그램에 PHP를 사용한다고 명시하면 자바 스크립트는 경험에서 볼 때이 응용 프로그램에서 가장 많이 발생하기 때문에이 질문에 대답 할 수있는보다 구체적인 답변을 제공하는 데 도움이 될 것입니다.

단위 테스트는 특히 모의 객체와 같은 멋진 기능을 많이 제공하므로 더 나은 테스트를 더 빨리 만들 수 있으므로 객체와 잘 작동합니다.

이것은 절차 적 코드베이스에서 단위 테스트를 수행하는 것을 금지 합니다. OOP에서 대부분의 단위 테스트는 일부 매개 변수를 매개 변수로 전달하고 결과 또는 특정 유형의 예외를 예상하여 메소드를 테스트합니다. 이것은 절차 코드로도 가능합니다. 단지 그 대신 시험 방법, 당신은 기능을 테스트 할 수 있습니다 .

다음을 수행해야합니다.

• 테스트해야 할 기능과 필요하지 않은 기능을 분리하십시오. OOP에서는 이것이 쉽다 : 개인 메소드는 호출자가 직접 접근 할 수 없기 때문에 테스트 할 필요가 없다. 절차 코드에서 일부 기능은 이와 같으며 테스트가 필요하지 않을 수 있습니다.

• 글로벌 범위 에 대해 생각하십시오 . 문제는 OOP에도 존재하지만 스파게티 코드를 테스트해야한다고 말하면이 코드를 작성한 사람들이 전역 범위를 너무 많이 사용하고 내부에서 변경 $_GET또는 $_POST배열 과 같은 미친 일을 하는 등 나쁜 습관을 가질 가능성이 있습니다 기능.

• 코드 외부 함수를 다루십시오. 이것은 더 복잡한 경우이지만 여전히 가능합니다. 어느 쪽이든 당신은 require_once페이지가 어떻게되는지보고하기 를 통해 출력을 잡을 ob_start/ob_get_clean 하거나 테스트 스위트에서 HTTP 요청을 하고, HTML을 구문 분석하여 응답을 분석 할 수 있습니다. 이것은 실제로 UI 테스트가 아닙니다. 여기에서 페이지의 단추가 왼쪽이나 오른쪽에 나타나는지 또는 링크가 큰 빨간색 대문자 나 작은 파란색으로되어 있는지는 신경 쓰지 않습니다. 관심있는 것은 DOM을 통해 일부 HTML 요소 를 찾고 해당 내용을 예상 한 것과 비교하는 것입니다.

• 응답 코드를 테스트하십시오 . require_once출력 버퍼링을 사용하는 것이 좋지만 웹 응용 프로그램에서 오류를 처리하는 방법도 테스트해야합니다. 예를 들어 테스트의 예상 결과가 404 Not Found 인 경우 응답이 무엇인지 알기 위해 HTTP 요청을 수행해야합니다.

응용 프로그램이 적절한 OOP 프레임 워크로 마이그레이션 될 때까지 연기되도록 제안합니다.

나중에가 아니라 다른 플랫폼으로 마이그레이션하기 전에 자동 테스트를 실시하십시오 . 나중에 수행하지 않고 마이그레이션을 수행하는 동안 추가 테스트를 추가하십시오. 이러한 테스트가 "통합 테스트"또는 단위 테스트 인 경우 스스로 결정해야하지만 일반적으로 두 가지 유형에 대해 선호하는 xUnit 테스트 프레임 워크를 사용할 수 있습니다.

단위 테스트를 시작하는 가장 효과적인 방법은 가장 자주 발생하거나 가장 높은 오류 클래스를 식별하는 것입니다. 그런 다음 해당 오류를 대상으로하는 테스트를 작성하십시오.

이러한 테스트를 구현하는 방법은 패러다임과 언어마다 다릅니다. 단위 테스트 수행 능력에 영향을 미치는 가장 큰 것은 코드의 품질입니다. 패러다임이 덜 사용되었습니다. 단위 테스트는 코드의 "단위"를 분리하여 테스트하는 것입니다. 코드의 "단위"를 분리하는 데 영향을주는 것은 테스트를 어렵게 만듭니다.

• 글로벌 사용
• 부작용
• 밀접하게 결합 된 코드
• 잘못 연결된 코드
• 많은 수의 조건
• 잘못 설계된 "단위"

이 모든 것이 언어 패러다임보다 테스트의 어려움에 더 큰 영향을 미칩니다.

코드의 일부를 자동으로 테스트 할 수있는 상황이 발생하면 단위 테스트가 효과적 일 수 있습니다. 따라서 문제는 절차 코드를 효과적으로 단위 테스트 할 수없고, 문제는이 코드를 단위 테스트 할 수 있다는 것입니다. 그것은 읽는 상태와 설정하는 상태에 따라 다릅니다. 이상적으로는 둘 다에 대한 답은 0이지만 그렇지 않은 경우 여전히 테스트 할 수 있습니다.

항상 그렇듯이 코드를 신뢰하는 데 드는 비용과 코드의 정확성에 대한 신뢰도를 평가해야합니다. 단위 테스트의 이점 중 하나는 종속성을 명시 적으로 식별하는 것이므로 OOP 코드와 비교하여 절차 코드를 단위 테스트하는 것이 훨씬 더 효과적입니다.

절차 코드에 대해 진정한 단위 테스트를 수행하는 것이 가능하지 않다고 생각합니다. 주된 문제는 각 절차가 스터브 될 수없는 많은 의존성을 가질 수 있다는 것입니다. 기껏해야 테스트는 통합 테스트입니다. MS Access의 VB6 모듈과 VBA 모듈을 사용하여 여러 달 전에 비슷한 일을했습니다.

즉, 가장 고통을 일으키는 방법 주위에 테스트 스캐 폴딩을 넣을 수 있다면 가치가 있어야합니다.