우리는 최근에 응용 프로그램에서 로케일 특정 문제를 발견했으며 수정하기 쉬웠지만 (무슨 일인지 파악한 후에) 이와 관련하여 단위 테스트 관행에 대해 생각하고있는 팀을 확보했습니다.
우리는 이러한 문제를 고객이 발견하기 전에 이상적으로 더 빨리 파악하고 싶습니다. 향후에 로케일 별 버그를 다시 소개하지 않도록 보호하고 싶지만 적어도 하나의 다른 문화에서 모든 단위 테스트를 복제하는 것은 많은 것처럼 보입니다. 간접비.
다중 로캘 단위 테스트에 어떻게 또는 어떻게 접근 하시겠습니까?
답변:
일반적으로 모든 단위 테스트를 복제 할 필요는 없습니다. 로케일에 실제로 의존하는 것을 식별해야합니다 (좋은 점검표는 여기에 있습니다) ). 국제화와 관련된 많은 것들이 단위 테스트보다 높은 수준의 테스트를 받아야합니다.
다른 인코딩으로 제공 될 수있는 문자열 데이터를 처리하는 경우 "데이터 기반 테스트"를 사용할 수 있습니다. 즉, 다른 인코딩의 데이터를 동일한 테스트 방법으로 전달할 수 있습니다. Java의 경우 TestNG가 가장 적합합니다.
또 다른 가능한 문제는 날짜 / 시간 형식화 및 구문 분석입니다. 대부분의 로케일은 시간 요소를 구분하기 위해 :를 사용하지만 점을 사용하는 브라질 사람도 있고 hm 및 s (12h15m30s)를 사용하는 사람도 있습니다. 다른 로케일의 전달 된 데이터로도 사용할 수 있습니다. 모든 로케일을 테스트 할 필요는 없습니다.
오른쪽에서 왼쪽으로 로케일을 사용하여 GUI를 테스트하는 것은 일반적으로 단위 테스트의 대상이 아닙니다.
결론은 단위 테스트에서 로케일 고유의 데이터를 식별하고 데이터 기반 테스트 (데이터 제공 업체)를 사용하여이 데이터를 테스트에 제공해야한다는 것입니다.
다음은 몇 가지 제안입니다.
항상 주요 대상 독자 와 다른 로컬 설정이있는 머신에서 개발 하십시오. 날짜, 통화 및 모든 숫자 형식 문제와 관련된 버그를 매우 빠르게 찾을 수 있습니다. 빌드 서버와 동일하게 브라질 또는 베트남에 배치하십시오 (물리적 설정이 아닌).
단위 테스트에서 테스트 제목, 문자열 등에 악센트 및 특수 문자를 사용하십시오 . 내가 사용하는 소프트웨어 (내가 개발 한 소프트웨어가 아님)에서 발생하는 가장 일반적인 국제화 문제는 프랑스어로 é 및 è 또는 ç입니다. 테스트에 사용하는 모든 문자열에 넣습니다. 항상 같은 단어를 사용하십시오brèç©
경로에 악센트 및 특수 차트를 사용하는 것을 잊지 마십시오 . Visual Studio.NET 자체에도 여전히 많은 문제가 있습니다! 테스트에서 이러한 디렉토리를 작성하고 해당 디렉토리에서 읽고 쓸 수 있어야합니다.
Visual Studio .NET을 사용하는 경우 프로젝트 속성의 코드 분석 에서 전역 화 규칙을 활성화하십시오 . 가장 일반적인 문제는 컴파일시 경고를 생성합니다.
팀에 외국인 을 고용 하십시오.