"단위 테스트"쉘 스크립트에 대한 약간의 상투적 인 아이디어는 제어 된 환경에서 스크립트를 실행하는 래퍼 스크립트를 사용하는 것입니다. 즉 실행하고 싶지 않은 실제 명령을 "조롱 (mock)"하는 기능을 정의하는 것입니다. (예 : ssh() { }).
이렇게하면 머리글처럼 설명하고있는 다른 프로세스에 대해 걱정할 필요없이 관심있는 상호 작용을 테스트 할 수 있습니다. 이것은 여전히 잘 설계된 bash 코드에 크게 의존하지만 적어도 이론적으로는 가능할 것이라고 생각합니다.
데모 :
$ cat /tmp/grep.sh
#!/bin/bash
# Simple program that relies on grep
echo -e "This is a test\nThis line doesn't match." | grep test
단위 테스터 :
$ /tmp/grep.sh
This is a test
을하지만 유닛 테스트 스크립트 내에서 실행하는 경우 : 이제
$ cat /tmp/unittest.sh
#!/bin/bash
grep() {
echo "Mock GREP result"
}
. "[email protected]"
우리가 직접 grep.sh을 실행하면, 그것은 예상대로 검색 grep은 기능에 의해 조롱된다 :
$ /tmp/unittest.sh /tmp/grep.sh
Mock GREP result
확인하려는 모든 행동을 테스트 할 수 있습니다.
동일한 쉘 (. 명령)에서 실행해야하는 것과 같은 몇 가지 제한 요소가 있습니다. 즉, 스크립트가 다른 스크립트를 호출하면 다시 실제 명령을 호출합니다.
다른 대안은 단위 테스트 디렉토리에 스크립트 세트를 정의하는 것입니다.
$ ls /usr/local/unitbin
grep
ssh
svn
그런 다음 단위 테스트 스크립트가 차례로 다른 스크립트를 호출 스크립트 작업을해야 스크립트에서 실행 PATH, 예컨대 :
$ cat /tmp/unittest.sh
#!/bin/bash
PATH=/usr/local/unitbin:$PATH "[email protected]"
이 변경 있습니다. 내가 말했듯이
이러한 예는 모두
는 약간 말도, 그들은 가치가보다 잠재적으로 더 많은 문제입니다. 이 경로를 고려하기 전에이 질문에 대한 다른 대답을 확실히 볼 것입니다. 그러나 단위 테스트를 원하는 bash 코드가 있지만 샌드 박스에서 안전하게 실행할 수없는 경우이 옵션 중 하나가 유용 할 수 있습니다.
유지하기 어려운 이유는 기본 기능을 둘러싼 "모두 해"래퍼입니다. 제 생각에는 특정 유스 케이스를 중심으로 전체 애플리케이션 (예외 처리 및 junit 테스트 포함)을 코딩하는 것이 더 좋으며 특정 유지 보수 작업을위한 제한된 쉘 스크립트 세트를 유지하는 것이 좋습니다. –
/bin/sh는 _lot_을 수행 할 수 있습니다. 설정을 변수의 일반 목록으로 유지할 수 있다면 "source"/ ""라고 부를 수 있습니다. XML 파일이 있으면 XSLT 스크립트를 작성하여 변수 목록을 작성하십시오. –