단위 테스트에서 파일 내용 / 인코딩을 확인하는 것이 '나쁜 습관'으로 간주됩니까?

약간의 맥락 : 오늘은 다른 동료가 제공 한 일부 SQL 코드를 업데이트해야했고 꽤 큰 스크립트이기 때문에 별도의 파일로 저장되어 런타임에 읽고 실행됩니다. 이 작업을 수행하는 동안 실수로 몇 달 전에 두 가지 버그가 발생했습니다.

• 어떤 이유로 든 ASCII 파일은 UTF-16으로 인코딩되었습니다 (동료가 파일을 이메일로 보냈기 때문에 나에게 파일을 보냈습니다).
• 스크립트에 초기 SET명령문 이 누락되었습니다 (프로덕션의 일부 드라이버로 인해 필요하지만 로컬로 새로 설치하지는 않음).

약 1 시간 동안 이것을 디버깅 한 후 다시는 발생하지 않도록 유닛 테스트를 작성하기로 결정했습니다 (그리고 미래 개발자에게 쉬운 수정을 제공하기 위해 어설 션 메시지에 수정하는 빠른 방법 포함).

그러나이 코드를 푸시했을 때 다른 동료 (우리 팀 리더이기도 함)가 나에게 걸어 가서 다음과 같은 이유로 다시 만들면 안된다고 말했습니다.

"이것들은 단위 테스트에 속하지 않습니다"

"단위 테스트는 코드 흐름을 확인하는 데만 사용해야합니다"

나는이 버그가 앞으로 다시 소개되지 않을 것이기 때문에 여전히 내가하고있는 일이 잘못이 아니라고 생각하기 때문에 지금 꽤 갈등합니다. 그러나이 동료는 선배로 일하고 하루가 끝나면 무엇을 결정하게됩니다. 우리는 시간을 보냅니다. 어떻게해야합니까? 이런 식으로 잘못하고 있습니까? 나쁜 습관으로 간주됩니까?

작성한 테스트는 단위 테스트보다 통합 또는 회귀 테스트에 더 가깝습니다. 이 줄은 매우 모호 할 수 있고 때로는 단위 테스트가 무엇인지 아닌지에 대한 페도 로트리로 진행되지만 동료에게 돌아가 코드의 정확성을 보장하는 가치를 추가하기 때문에 작성한 테스트의 위치를 ​​묻습니다.

나는 단위 테스트가 아닌 것에 중점을 두지 않고 통합 테스트라도 테스트에 여전히 가치가 있음을 깨닫습니다.

기술적으로 이것은 단위 테스트가 아니며 유효성 검사 단계 이상입니다. 적절한 접근 방식은 실제로 워크 플로가 무엇인지에 달려 있습니다. 팀 리더는 단위 테스트의 목적이 정확합니다. 내 생각에 이것은 여전히 ​​수행 해야하는 작업에 잘못된 도구를 사용하는 경우입니다. 이제부터 시작하십시오 :

해결하려는 문제는 무엇입니까?

설명을 통해 데이터베이스 스크립트가 일부 표준을 준수하는지 확인해야합니다.

문제를 해결하기 위해 어떤 도구 / 프로세스를 사용할 수 있습니까?

소스 코드 품질은 일반적으로 정적 분석 도구로 확인됩니다 . 당신은 당신의 SQL을 검증하는 정적 분석 도구가없는 경우에, 당신은에 검사 수행하는 신속하고 더러운 도구를 만들 수 있는 그것을 전달 SQL 파일을. 이야기하고있는 문제를 처리 할 수있는 정적 분석 도구가 있는지 확인하는 것은 문제가되지 않습니다.

Jenkins에 통합하는 등 빌드 인프라의 해당 부분을 만들면 프로젝트의 모든 SQL 파일에 적용 할 수 있습니다.

단위 테스트는 현재 파일의 문제 만 해결합니다.

도구의 필요성을 어떻게 전달합니까?

이것은 매우 쉽습니다. 팀장과 대화하십시오. 그는 제품 소유자 및 귀하와 협력하여 툴링에 대한 투자의 위험 / 보상을 결정할 수 있습니다. 이것이 일회성 문제 일 가능성이 높으면 툴링이 과도 할 수 있습니다. 가장 큰 문제를 파악하기위한 툴링이 쉬운 경우 온 전성 검사만으로도 가치가 있습니다.

팀장에게 귀하 (또는 본인)가 고려하지 않은 일부 아이디어가있을 경우 문제를보다 정확하게 해결할 수 있습니다.

파일 "Unit Tests"에 액세스하는 테스트를 호출하는 것은 좋지 않습니다.

"이것들은 단위 테스트에 속하지 않습니다"

당신은 "감각이 나지만, 나는 그것을 넣을 더 좋은 곳을 찾을 수 없었습니다. 그들은 어디에 속해 있습니까?"

불행히도, 어떤 종류의 테스트가 존재하고 어떻게 구성되는지는 전적으로 회사마다 다릅니다. 따라서 회사에서 이러한 테스트를 처리하는 방법을 찾아야합니다.

아직 단위 테스트 이외의 자동화 된 테스트를 실행할 수있는 방법이 없다면 실용적인 방법은 실제로 단위 테스트가 아닌 단위 테스트에 접두사를 표시하는 것입니다. 실제로 당신이 필요로하는 테스트. 그 후 조직을 시작할 수 있습니다.

마이클 페더스 (Michael Feathers)는 그의 저서 레거시 코드로 효과적으로 작업하기에서 이것을 말합니다

업계에서 사람들은 종종 특정 테스트가 단위 테스트인지에 대해 앞뒤로 이동합니다. [...] 두 가지 특성으로 되돌아갑니다. 테스트가 빠르게 진행됩니까? 오류를 신속하게 지역화하는 데 도움이 될 수 있습니까?

테스트를 통해 오류를 신속하게 파악하고 빠르게 실행할 수 있습니까? 그렇다면, 그렇게하십시오! 아니라면하지 마십시오! 그렇게 간단합니다!

즉, 당신은 다른 사람들과 환경에서 일하고 있으며 그들과 어울려야합니다. 개인적으로 동의하지 않더라도 자신의 방식대로해야 할 수도 있습니다.

때때로 소스 코드 파일, 구성 파일 등에 대해 비슷한 테스트를 작성했습니다. (a) 파일 시스템에 액세스하고 초고속이 아닐 수 있기 때문에 단위 테스트라고 부를 수는 없습니다. (b) 체크인 할 때마다 실행되는지 상관하지 않습니다. CI 서버).

통합 테스트라고 할 수 있습니다. 확실히, 그들은 단위 테스트보다 그 관점에 더 가깝습니다.

그들 자신의 용어는 자원 테스트 입니다. IMHO는 CI 서버에서 야간에 실행하는 경우 전적으로 정당화됩니다. 비용이 최소화되고 신중하게 사용될 경우 가치를 분명히 추가합니다. 신중하게 하나의 정의 : 테스트에서 문제를 일으킨 문제 (예 : 언급 한 인코딩)를 확인하는 경우

단위 테스트는 코드의 메소드 또는 '단위'를 테스트하는 것입니다. 소프트웨어에서 가장 작은 논리 및 코드 그룹을 테스트하고 있습니다.

나중에 다른 장치와 결합하면 통합 테스트를 수행하게됩니다.

귀하의 팀장이 귀하의 이니셔티브를 장려하고 다른 제안을 제시했으면합니다. 당신은 확실히 올바른 생각을 가지고 있습니다.

SQL은 C # 또는 Java와 같은 저급 언어와 마찬가지로 코드이므로 테스트해야합니다. 검증 및 검증은 모든 테스트 수준에 속합니다. 따라서 인코딩 및 SET 문이 포함되지만 반드시 독점적으로 테스트 할 필요는 없습니다. 줄 끝 또는 묶음과 같은 일반적인 내용은 일반적으로 SCM 후크 또는 기능을 사용할 수 있습니다.

모범 사례는 회귀 테스트를 통해 과거 버그가 다시 발생하지 않도록하는 것입니다. 일반적으로 테스트는 버그 해결과 함께 생성됩니다. 이러한 버그가 단위 / 통합 또는 시스템 수준에서 회귀 테스트에 포함되지 않은 경우 개별 문제가 아닌 팀 문제, 프로세스 문제입니다.

문제는 ... 구문 오류, 누락 된 문 또는 '단위'내부의 논리 블록은 일반적으로 테스트되지 않습니다. 서로 다른 조합으로 장치의 입력 및 출력을 테스트하고 생성 될 수있는 많은 가능성을 테스트합니다.

누락 된 SET 문으로 돌아 가기-테스트 할 입력 및 출력의 많은 가능성을 알려주는 데 도움이됩니다. 선택한 SET이 없으면 어떤 테스트를 실패하게됩니까?

제품의 일부가되는 파일이 있으면 내용이 정확해야합니다. 이것을 확인하지 않은 이유는 없습니다. 예를 들어, 일부 폴더에 6 개의 1024x 1024 이미지가 필요한 경우 반드시 정확히 검사하는 단위 테스트를 작성하십시오.

그러나 파일이 없을 수도 있고 파일을 읽는 코드도 있습니다. 해당 코드에 대한 단위 테스트를 작성할 수 있습니다. 위의 예에서, 6 개의 이미지 중 하나를 읽는 기능은 메모리에 1024 x 1024 이미지를 반환합니다 (또는 생성해야하는 모든 것).

어쨌든 단위 테스트는 아니지만 유용한 테스트입니다. 유용한 테스트 (단위 테스트가 아님)를 수행 할 수있는 단위 테스트 프레임 워크를 사용하는 경우 단위 테스트 프레임 워크를 사용하지 않는 이유는 무엇입니까?

어쩌면 나는 당신의 문제를 오해하고 있지만, 나에게 이것은 어떤 종류의 전용 테스트로만 캡처 할 필요가 없으며 단순히 버전 제어 시스템 으로 캡처해야 할 문제처럼 들립니다 . 커밋하기 전에 코드별로 변경 사항을 패치별로 검토해야합니다. 자식에서 이것을하는 간단한 방법은 변경 사항을 추가하는 것입니다.

git add -p

이것은 텍스트 파일의 각 변경에 대해 작업 디렉토리가 실제로 유지할 것인지 묻습니다. 예를 들어,“초기 SET진술” 이 삭제 된 것을 볼 수 있습니다 .

전체 파일의 인코딩이 변경되면 알고리즘이 이전 파일과 새 파일 git add -p을 구분하지 못 하므로 전혀 추가되지 않습니다. 그러면 커밋 전에 수행 한 다른 명령, 즉

git status

여기가 있음을 나타내는 빨간색으로 강조 파일을 볼 것 입니다 변경됩니다. 왜 이것이 문제가되지 않았는지를 조사 git add -p하면 문제가 명백해집니다.

고려해야 할 또 다른 각도 :이 두 가지 조건은 프로그램을 실행하기위한 요구 사항이므로 실행 로직 근처에 로직을 포함시키지 않아야합니까? 내 말은 : 파일을 읽기 전에 파일의 존재 여부를 테스트하거나 내용의 유효성을 검사하는 것입니다. 어떻게 다른가요? 나는 이것이 코드 외부 리소스이기 때문에 실제로 사용되기 전에 런타임에 유효성을 검사해야한다고 생각합니다. 결과 : 더 강력한 앱으로 추가 테스트를 작성할 필요가 없습니다.

테스트는 다른 코드와 동일하며, 복잡 할 경우 단위 테스트의 이점도 있습니다. 이러한 사전 조건 점검을 테스트에 직접 추가하는 것이 가장 간단한 것 같습니다.

대부분의 테스트는 이것을 요구하지 않을 정도로 간단하지만, 일부가 충분히 복잡한 경우에는 이러한 전제 조건 점검에서 근본적으로 잘못된 것이 없습니다. 물론 테스트도 실패해야하지만, 좋은 단위 테스트는 어떤 단위 가 실패 했는지 알려줍니다 .

테스트의 일부로 사용되며 특정 내용과 인코딩이 있어야하는 스크립트는 아마도 하나의 단위 일 것입니다. 나머지 테스트보다 훨씬 많은 코드와 논리를 가질 수 있습니다. 이러한 스크립트를 사용한 테스트는 최고의 디자인이 아니며 가능하면보다 직접적으로 리팩토링해야합니다 (통합 테스트가 아닌 경우).

첫째, 테스트의 목적 중 하나는 코드에서 문제가 반복되는 것을 방지하는 것이므로 이러한 특성에 대한 테스트를 계속 작성 해야합니다 .

두 번째-이름 지정이 어렵습니다. 그렇습니다. 이들은 분명히 "단위 테스트"가 아니지만 명백한 실수로부터 사용자를 보호하고 오류에 대해 더 빨리 피드백을 제공하기 때문에 빌드 프로세스에서 바람직하고 필요한 부분이 될 수 있습니다 (특히 dev 상자에 대한 결과).

따라서 문제는 테스트가 언제 어떻게 실행되는지에 대한 것입니다.

나는 과거에 이런 종류의 테스트를 광범위하게 사용했습니다. 그들은 우리에게 상당한 고통을 덜었습니다.

단위 테스트는 올바른 입력에 대한 올바른 결과를 생성하는지 확인하기 위해 코드 단위를 개별적으로 실행하는 것입니다. 격리는 테스트중인 장치와 테스트 자체를 모두 반복 가능하게해야합니다. 즉, 부작용에 의존하거나 영향을 미치지 않아야합니다.

SQL은 개별적으로 테스트 할 수있는 것이 아니므로 SQL 테스트는 정확히 단위 테스트가 아니며 SELECT 문을 제외하고는 부작용이 거의 확실합니다. 단위 테스트가 아닌 통합 테스트라고 부를 수 있습니다.

도입 할 수있는 결함을 개발주기에서 가능한 빨리 감지 할 수 있고 결함의 원인을 쉽게 식별 할 수 있도록 신속하게 처리 할 수 ​​있도록하는 것이 항상 현명합니다. 수정되었습니다.

문제의 테스트는 "단위 테스트"본문에서보다 적절하게 재배치되어 다른 곳에 배치 될 수 있지만 추적하는 데 몇 시간이 걸릴 수있는 결함의 도입을 방지하는 등 유용한 작업을 수행하는 경우 완전히 제거해서는 안됩니다. 내려가는.