파워셸에서 TDD 및 유닛 테스트를 수행하는 방법은 무엇입니까?

파워셸에서 TDD 및 유닛 테스트를 수행하는 방법은 무엇입니까?

MS가 모든 새로운 서버 제품에 강력한 영향력을 행사함에 따라, 저는 이를 심각하게 받아들여야 한다고 생각하기 시작했습니다."진지하게 생각하는" 부분은 TDD입니다.파워 셸 스크립트를 유닛 테스트하는 좋은 방법을 찾았습니까?

저는 Mr.Geek Noise로부터 조롱의 샘플을 찾았습니다. 하지만 저는 RhinoMocks와 같은 것을 정말 원합니다.Brian Hartsock은 MS 테스트의 파워셸 문자열에 대한 실행 테스트 샘플을 가지고 있습니다.약간 촌스럽지만 효과가 있는 것 같습니다.

제가 원하는 것은 "실제" 언어로 된 것만큼 깨끗한 Powershell TDD 경험입니다.

---

명확하게 하기 위한 업데이트:

처음 두 개의 답은 파워셸을 테스트하는 것에서 저를 멀어지게 합니다.그 의견들은 흥미롭습니다.파워셸에서 테스트하는 것이 좋은 생각인지 알고 싶지 않습니다.그것은 다른 포럼에서 물어야 할 주관적인 질문입니다.나는 유닛 테스트 파워셸에 대한 해결책을 원합니다.만약 여러분이 그것이 나쁜 생각이라고 생각한다면, 그것을 재미있는 학문적 질문으로 다루세요.

• 예, 스크립트 언어는 서로 다른 시스템을 결합합니다.하지만, 이미 지적했듯이, 역동적인 언어로 조롱하고 이음새를 부러뜨리기도 쉽습니다.
• "디버깅"에 대해 묻는 것이 아닙니다.디버깅은 매우 유용한 주제입니다.다른 사람이 묻도록 하겠습니다.
• 아마도 PS 스크립트는 간단해야 할 것입니다.이 언어는 모듈화를 지원하며, PS에서 복잡한 프로세스가 구현되는 것은 불가피합니다(나쁜 아이디어가 있더라도).
• 이 질문에 대한 답은 "할 수 없습니다"가 아닙니다.일부 사람들이 문제에 대해 진전을 이뤘다는 것을 (조금 오래된) 링크된 블로그를 통해 알 수 있습니다.

상태 변경하기xUnit 스타일로 Powershell 로직의 자동 테스트를 구현하려면 어떻게 해야 합니까?통합 테스트는 가장 흥미로운 의존성을 깨는 단위 테스트입니다.

Scott Muc는 Pester라는 PowerShell용 경량 BDD 프레임워크 프로젝트를 시작했습니다.

https://github.com/pester/Pester

이제 PsUnit이 프레임워크로 업데이트되었습니다.저는 몇 달 전에 당신과 같은 문제를 겪었고, 제가 작성해야 하는 스크립트 수에 비해 PsUnit이 너무 크고 복잡하다고 생각하여 PS용 유닛 테스트 프레임워크를 직접 작성했습니다.PS는 예를 들어 Python과 같은 다른 스크립트 언어와 동일한 종류의 특성을 가지고 있습니다. 즉, 가짜(모킹)에 훌륭한 테스트 방법의 범위로도 언제 어디서나 기능을 재정의할 수 있습니다.즉, 다른 함수에 따라 테스트할 함수나 개체가 있는 경우 테스트 방법에서 이를 선언하여 로컬 가짜 구현을 생성할 수 있습니다.

따라서 어떤 테스트 프레임워크를 사용할지에 관계없이 PS는 TDD에 매우 쉽습니다.그것은 적어도 저의 경험이었습니다.

구체적으로 TDD가 아닌 "테스트 전략"에 대해 질문하신 것 같은데, 두 가지 질문 모두 답변 드리겠습니다.

PowerShell 작업의 대부분은 cmdlet과 객체 파이프를 통해 서로 다른 시스템을 통합하는 작업입니다.PowerShell 스크립트가 제대로 작동하는지 확신하려면 이러한 모든 시스템을 최대한 정확하게 테스트할 수 있도록 완벽한 준비 환경을 구축하는 데 최대한 많은 노력을 기울여야 합니다.

완벽한 준비 환경에서 스크립트를 실행하는 것은 TDD를 통해 "설계를 완성"하거나 사후 장치 테스트를 통해 "코드 의도 테스트"하는 것보다 훨씬 더 가치가 있습니다.

도움이 될 수 있는 작은 노트:

• 그-whatif스위치는 기본 제공 cmdlet에 있습니다.또한 저는 당신이 이것도 할 수 있다는 것을 방금 알았습니다.-whatif:$someBool필요할 때 알게 될 겁니다
• V2에서 제공되는 ISE에는 디버거가 있습니다.달콤해.
• 언제든지 C#에서 사용자 지정 cmdlet을 코드화하고 원하는 작업을 수행할 수 있습니다.

저는 다음 모델과 같은 기본적인 PowerShell 스크립트를 TDD로 작성하고 있습니다.

먼저 SUT_spec.ps1의 사양입니다.

Import-Module -Name .\my_SUT.ps1

$case1_input=@{}
$case1_output=@{}
f1 $case1_input $case1_output

$case1_result = $case1_output["Output"] -eq "expected"
"f1 case1: $case1_result"

# repeat for all test cases

Remove-Module -Name my_SUT

둘째, my_SUT.ps1 파일의 함수로서 내 단위(SUT):

function f1($the_input, $the_output)
{
    #take input from $the_input hashtable, process it and put output into $the_output hashtable.

    $the_output["Output"]="results"
}

셋째, 릴리스 가능한 주 진입점은 SUT_spec.ps1과 같이 별도의 파일이지만 실제 외부 소스로부터의 입력이 있습니다.

죽은 논의이지만 우려는 매우 살아 있습니다.

의도된 용도를 고려할 때 단위 테스트 PS의 유용성에 대한 논의에서 누락된 한 가지는 엔터프라이즈 시스템의 모듈과 관련이 있습니다.PS에 구현된 일반적인 네트워크/파일 수준 작업을 위한 중앙 저장소가 있는 엔터프라이즈 설정을 상상해 보십시오.이 설정에서는 소수의 개발자와 네트워크 전문가가 약간 중복되는 업무를 수행합니다.개발자는 비즈니스 로직을 캡슐화한 모듈을 생성하고 그 유용성을 즉시 인식하여 다른 사람들이 즉시 모듈에 뛰어들어 자신의 노력에 통합합니다.이 모듈은 일회성 대화형 스크립트에서 중간 크기의 클라이언트 응용프로그램에 이르기까지 모든 것에 포함되어 있습니다. 일부는 셸 스크립팅 언어의 사용 사례에 동의하지 않을 수 있지만, 진화는 이 분야에서 상수입니다.

이 시나리오에서는 이러한 공통 모듈이 따라야 할 "계약" 집합을 정의하는 것이 가치가 있다고 생각합니다.지식 공유가 조직에 필수적인 경우 두 명 이상의 사용자가 이러한 모듈을 수정할 수 있습니다.단위 테스트를 통해 모듈의 무결성을 검증하면 질서를 유지하고 혼란을 최소화하여 모듈 자체의 가치를 유지(아마도 증가)하는 데 큰 도움이 될 것입니다.

선호하는 접근 방식에 대해서는 아직 채택하지 않았습니다.PS는 유체/역학적/민첩성 물질을 떠올리게 합니다.제가 TDD에서 본 것과 같은 단단한 구조 안에 그것을 포함하는 것은 부자연스럽게 느껴집니다.그러나 위의 시나리오를 고려할 때 이 목표는 무시할 수 없습니다.신경 쓰지 마세요. 시간 낭비해서 죄송합니다.읽어주셔서 감사합니다.

당신의 질문으로 볼 때 당신은 실망할 것 같습니다.파워셸은 작은 명령줄 언어입니다.물론, C#이 할 수 있는 모든 것을 할 수 있고, 더 많은 것을 할 수 있지만, 어셈블리 언어도 할 수 있습니다.물론 OO이기도 하고 에 연결되어 있습니다.NET 라이브러리, 그러나 훨씬 더 깨끗한 언어인 C#도 마찬가지입니다.

솔루션이 하나의 라이너보다 길거나 TDD가 필요하다고 생각하면 Powershell을 사용하지 않습니다.그것은 복잡한 것에 대해서는 피해야 할 놀라움으로 가득 찬 암호입니다.

임시 검색을 수행하고 텍스트를 대체하거나 형식을 지정하거나 파일 시스템을 둘러보려면 Powershell이 친구입니다.여러분이 정말로 원하는 것은 구문에 익숙해지기 위해 매일 조금씩 사용하고 자주 반복하는 것입니다.이러한 이유로 오픈 소스 Powershell 라이브러리도 사용하지 말고, 특별한 명령줄 사용 사례가 없는 한 CmdLets를 직접 작성하는 것은 잊어야 합니다.파이프 바인딩 규칙은 난해하고 추악합니다.

물론 이것은 모두 제 의견이지만, 저는 오랫동안 Powershell 사용자였고 이렇게 보니 훨씬 더 행복합니다.

언급URL : https://stackoverflow.com/questions/940497/how-to-do-tdd-and-unit-testing-in-powershell