약간의 맥락 : 오늘은 다른 동료가 제공 한 일부 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 이미지를 반환합니다 (또는 생성해야하는 모든 것).
어쨌든 단위 테스트는 아니지만 유용한 테스트입니다. 유용한 테스트 (단위 테스트가 아님)를 수행 할 수있는 단위 테스트 프레임 워크를 사용하는 경우 단위 테스트 프레임 워크를 사용하지 않는 이유는 무엇입니까?