2010-04-30 3 views
4

환경 (상당히 일반적인)이 PROD, UAT, QA, DEV 인 경우를 가정 해 봅시다. 모든 환경에서 테스트를 실행하는 것이 좋은 생각입니까?개발 이외의 환경에 대한 테스트를 작성하는 것이 좋습니다.

내가 생각하는 것은 다음과 같습니다. 내 코드가 의존하는 SQL에서 proc을 가지고 있는데, 나는 proc_getActiveCustomers이라고 부를 것이다. 그 proc이 존재하지 않는다면 내 app은 진짜 빨리 남쪽으로 갈 것이다. 그래서 나는 데이터베이스에서이 proc의 존재를 검사하는 테스트를 작성한다. 여기에 새로운 것은 없습니다.

그러나 QA 환경에 내 앱을 배포 할 때 proc_getActiveCustomers의 존재 여부를 확인하는 테스트가 필요합니까? 이것이 좋은 생각이라고 생각하지만, 개발 환경 밖에서는 테스트를 많이 듣지 못했습니다. 내가 알지 못하는 몇 가지 단점이 있는지 궁금하게 만든다.

내가 지향하는 방향은 코드의 환경 목록을 가지고 그 환경을 단위 테스트에 전달하는 것입니다.

답변

5

이것은 smoketest이라고하며, 이건 당신의 경우에도 좋은 생각입니다.

smoketest는 제품이 올바르게 설치되었고 기본적으로 작동 상태 인 것으로 확인하기위한 빠른 테스트 세트입니다. 더 철저하고 자원을 소비하며 종종 바람직하지 않은 방식으로 시스템의 상태를 변경하는 통합,로드 등의 테스트와 달리 프로덕션 환경에는 적합하지 않습니다.

+0

아, 고마워. 나는 이것들이 통합 테스트 또는 단위 테스트처럼 보이지 않는다고 생각하고 있었다. 이제 나는 그들에게 전화 할 것이있다. – jcollum

+0

@jcollum : 필자는 공식적인 맥락에서 사용 된 연기 테스트 용어를 들어 본 적이 없으므로 언제 어디에서 사용하는지 생각하고 싶을 수도 있습니다. (또는 적어도 비 흡연자와 이야기 할 때 의미를 설명하십시오. 기술적 인 종류의 사람). – GreenMatt

+0

@GreenMatt, 좋은 지적. 관리 및 사용자에게 "빌드 확인 테스트"라고 부르는 것이 좋습니다. –

0

당신이 말하는 테스트는 나에게 "단위 테스트"처럼 보이지 않습니다. 설정이 올바른지 확인합니다. 확실히 응용 프로그램 초기화 코드에 체크를 포함시키고 저장 프로 시저를 생성하게 만들지 만 TDD 의미에서 "테스트"라고 부르지는 않습니다.

모든 구성 요소가 올바르게 설치되었는지 확인하기 위해 체크리스트를 실행하는 것과 같습니다.

의도 한대로 구성 요소가 작동하는 경우 단위 테스트가 거기하지 않을 경우 확인해야 ...

0

당신은 드라이브가 전개 상황에 응용 프로그램을 얻을하는 것입니다. 모든 것이 프로덕션 환경을 시뮬레이트한다고 말할 수 있습니다. 앱에이 종속성 (실제, 조롱 된, 하위 항목 또는 위장 된)이있는 경우 항상 테스트해야합니다. Continuous Integration을 확인해보십시오. 이 검사가 필요한지 여부를 설명하는 데 도움이 될 수 있습니다.

+0

동의하면 CI가 훌륭한 솔루션이 될 것입니다. 여기에 입양에 대한 약간의 저항. – jcollum

관련 문제