Spock에 대한 좋은 글이 있어서 번역해서 올립니다.

오역이 있거나 다른 의견이 있으면 댓글로 남겨주시면 감사하겠습니다.

원본 URL : https://thejavatar.com/testing-with-spock/


Spock Testing – Spock tutorial

Managing exceptions in tests

 이제는 예제를 통해 테스트 실행 중에 특정 유형의 예외가 발생 여부를 확인하는 방법을 배우겠습니다. 그 메소드는 throw () , notThrown () 그리고 noExceptionThrown () 메소드 입니다. Throw 된 예외에 대한 세부 사항을 확인하고 싶다면, 변수에 thrown () 메소드의 결과를 할당 한 다음에 예외 자체를 확인해야 합니다.

Extras and catches

Spock에서 테스트를 작성할 때, 알고 있어야할 몇가지 사항이 있습니다.

Assingments created outside test methods

모든 테스트 전에 클래스 수준의 할당이 평가됩니다. 이것은 각 테스트 본문에 objectUnderTest를 생성하고 싶지 않을 때 특히 편리합니다. 다른 테스트들의 동작 중에 해당 객체가 상태가 공유 되는것에 대해 걱정없이 클래스 수준에서 해결 할 수 있습니다. ( 즉, 테스트 케이스가 시작할 때마다 objectUnderTest가 재 할당된다는 의미입니다.)


 특별한 이유로  클래스 레벨에서 생성 된 객체의 상태를 공유하고 싶을 경우에는 해당 변수에 @Shared 주석을 추가하면 됩니다.



 Spock은 클래스에 지정된 테스트가 파일에 표시된 순서대로 실행된다는 것을 보증하지 않습니다.  따라서, 위 예제는 1번 테스트가 실행되기 전에 2번 테스트가 먼저 실행되면 테스트가 실패할 수 경우입니다. 클래스 파일에 작성된 순서대로 테스트 실행을 원할 경우 @Stepwise 주석을 추가해야 합니다.


Verifying interaction of a method while changing its behaviour

 가끔은 메소드가 호출되었는지 여부와 그 메소드 동작을 변경하고 싶을 때가 있습니다. 여기서 가장 자연스럽게 하는 방법은 given 섹션에서 메서드의 사용자 정의 동작을 정의하고 then 섹션에서는 메소드가 호출되었는지 확인하는 것입니다.


 위 예제에서 확인할 수 있는 것은 Spock은 메소드의 동작을 두 번이상 재정의하지 못하게 하고 있다는 것 입니다. 테스트가 실행되면 Spock은 먼저 구문을 검증하기 위해서 then 섹션을 검색합니다. size () 메서드 하나를 찾게 되면, size () 메서드가 이미 처리되었기 때문에 given 섹션의 list.size () >> 10 표현식이 무시됩니다. 이 문제를 해결하기 위해서는 두 구문을 하나로 만들고,  검증문을 배치 할 수 있는 유일한 곳인 then 섹션에 구문의 결과를 넣어야합니다.


Overriding previously specified behaviours

 Stub, Mock 또는 Spy에서 이미 재정의한 메소드의 동작을 다시 재정의하는 방법은 비슷합니다. 하지만 이것은 작동하지 않습니다.  다음 문제는 그동안 매번 저를 힘들게 했습니다. 클래스 레벨에서 테스트를 위해 공통의 Stub 객체를 만들고 특정 메소드의 동작을 정의했습니다. 제가 다른 테스트를 만들면서, 이미 만들어 놓은 사용자 정의 Stub을 잊어 버리게 됩니다. 다른 테스트를 만들 때, 메소드 레벨에서 테스트에서 필요로 하는 요건을 만족하는 매우 비슷한 메소드의 동작을 정의합니다.  30 분 안에 저는 Stub화 된 오브젝트가 예상대로 작동하지 않는 이유를 알지 못했습니다. 이번에는 해결 방법이 없으며, 이런 일이 발생할 수 있음을 명심하십시오.


That keyword

Spock은 테스트를 작성하는 방법을 향상시키고, 스토리를 보다 설명적이고 쉽게 읽을 수 있는 방법을 제공하고 있습니다. 이미 추가된 정적 함수를 위한 키워드 that이 있습니다. 이 키워드는 테스트 로직을 변경하지는 않지만, expect 섹션은 수정할 수는 있습니다.


+ Recent posts