복잡한 정규식에 대한 단위 테스트가 있어야합니까?

응용 프로그램에서 복잡한 정규식에 대한 단위 테스트를 작성해야합니까?

• 한편으로는 입력 및 출력 형식이 종종 간단하고 잘 정의되어 있기 때문에 테스트하기가 쉽고, 종종 너무 복잡 해져서 테스트가 특히 중요합니다.
• 다른 한편으로 : 그들 자체는 일부 단위의 인터페이스의 일부가 아니다. 인터페이스 만 테스트하고 정규식을 암시 적으로 테스트하는 방식으로 인터페이스를 테스트하는 것이 좋습니다.

편집하다:

나는 그의 의견 에 이것이 내부 구성 요소 의 단위 테스트의 특별한 경우라고 언급 한 Doc Brown에 동의한다 .

그러나 내부 구성 요소 정규 표현식에는 몇 가지 특별한 특성이 있습니다.

1. 단일 라인 정규식은 실제로 별도의 모듈없이 복잡 할 수 있습니다.
2. 정규 표현식은 부작용없이 입력에 대한 출력을 매핑하므로 실제로 테스트하기가 쉽습니다.

도그 테스트를 제외하고 실제 질문은 복잡한 정규 표현식을 단위 테스트에 가치를 제공하는지 여부입니다. 정규식이 충분히 복잡하면 버그를 찾아서 재생산하고 회귀를 막을 수 있기 때문에 정규식이 공용 인터페이스의 일부인지 여부에 관계없이 값을 제공한다는 것이 분명합니다.

정규식은 강력한 도구 일 수 있지만 복잡한 정규식을 약간만 변경해도 여전히 작동한다고 믿을 수있는 도구는 아닙니다.

따라서 다루어야 할 사례를 문서화하는 많은 테스트를 작성하십시오. 검증에 사용되는 경우 실패해야하는 경우를 문서화하는 많은 테스트를 작성하십시오.

정규식을 변경해야 할 때마다 새로운 사례를 테스트로 추가하고 정규식을 수정하여 최선을 다하십시오.

내가 일반적으로 단위 테스트를 사용하지 않는 조직에 있었다면, 우리가 사용할 정규식을 테스트하는 테스트 프로그램을 작성합니다. 내가해야한다면 내 자신의 시간에 그것을 할 것입니다, 내 머리카락은 더 이상 색을 잃을 필요가 없습니다.

정규식은 나머지 응용 프로그램과 함께 코드입니다. 코드 전체가 예상대로 작동하는지 테스트해야합니다. 이것은 몇 가지 목적이 있습니다 :

• 테스트는 실행 가능한 문서입니다. 코드가 필요한 것을 명확하게 보여줍니다. 그것이 테스트되면 중요합니다.
• 미래의 유지 보수 담당자는이를 수정하면 테스트에서 동작이 변경되지 않았는지 확인할 수 있습니다.

다른 언어로 된 코드를 포함하여 극복해야 할 추가 장애물이 있으므로 유지 관리의 이점을 위해이 추가주의를 기울여야합니다.

즉, 신청 기간을 테스트해야합니다. 더 큰 블랙 박스의 일부로 독립 실행되는 자동 테스트로 정규식을 테스트하든 직접 손으로 바이올린을 사용하든 작동하는지 확인하는 것이 중요합니다.

단위 테스트의 주요 장점은 시간을 절약한다는 것입니다. 그들은 당신이 현재 또는 미래에 원하는만큼 여러 번 테스트 할 수있게합니다. 정규식이 언제든지 리팩토링, 조정, 더 많은 제약 조건 등을 얻는다고 믿을만한 이유가 있다면, 아마도 회귀 테스트를 원하거나 변경 할 때 갈 것입니다. 모든 엣지 케이스를 한 시간 동안 생각할 수 있으므로 중단하지 마십시오. 또는 코드가 무서워서 생활하는 법을 배우고 절대로 변경하지 마십시오.

다른 한편으로 : 그들 자체는 일부 단위의 인터페이스의 일부가 아니다. 인터페이스 만 테스트하고 정규식을 암시 적으로 테스트하는 방식으로 인터페이스를 테스트하는 것이 좋습니다.

나는 이것으로 당신이 스스로 대답했다고 생각합니다. 단위의 정규 표현식은 구현 세부 정보 일 가능성이 높습니다.

SQL 테스트에 필요한 것은 아마도 정규 표현식에도 해당됩니다. SQL을 변경하면 일부 SQL 클라이언트를 통해 SQL을 실행하여 예상 한 결과를 얻을 수 있는지 확인할 수 있습니다. 정규식을 변경할 때도 마찬가지입니다. 일부 샘플 입력과 함께 정규식 도구를 사용하여 예상대로 작동하는지 확인하십시오.

내가 유용하다고 생각하는 것은 정규 표현식 근처에 일치하는 텍스트 샘플이있는 주석입니다.

물어봐야한다면 대답은 '예'입니다.

일부 FNG가 와서 그가 정규식을 "개선"할 수 있다고 생각한다고 가정 해보십시오. 이제 그는 FNG이므로 자동으로 바보입니다. 어떤 상황에서도 귀중한 코드를 건드리지 말아야 할 사람 ! 그러나 그는 PHB 또는 무언가 와 관련이 있기 때문에 당신이 할 수있는 일은 없습니다.

당신이 PHB가 당신을 쫓아 내고 다시 비명을 지르고 있다는 것을 제외하고는 모든 것이 나빠질 때 "이 엉망진창을 어떻게 만들 었는지 남자에게 알려줄 수 있습니다." 따라서 아름다운 표현력의 걸작품을 만들 때 신중하게 고려한 모든 사례를 기록 하십시오.

그리고 당신이 그것들을 모두 작성 했으므로, 당신은 일련의 테스트 케이스를 갖는 방법의 3 분의 2입니다. 왜냐하면-정규식 테스트 케이스는 프레임 워크가 구축되면 실행하기가 쉽지 않기 때문입니다.

이제 에지 조건, 대안 및 예상 결과가 있습니다. 그리고 갑자기 테스트 사례는 모든 Agile 블로그 게시물에서 약속 한대로 문서화 됩니다. 당신은 그의 "개선"이 기존의 테스트 사례를 통과하지 못한다면 FNG에게 그다지 개선 된 것은 아니라고 지적합니다. 그리고 원래 코드의 문제를 보여주는 그의 제안 된 새로운 테스트 사례는 어디에 있으며, 작동하기 때문에 수정 할 필요가 없습니다!