Spock Testing – Spock tutorial ( 번역 ) 3/5

아톰18 2017. 3. 28. 16:39

2017. 3. 28. 16:39

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

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

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

Spock Testing – Spock tutorial

Checking interactions on Mock/Spy

때로는 단위 테스트를 위해 만든 더미 객체의 특정 동작이 필요 없을 수도 있습니다. 오히려 프로그램을 실행하는 동안 특정 인터페이스의 메소드가 호출 되었는지가 더 관심이 있을 수 있습니다. Mock 또는 Spy를 통해 그 목적을 달성 할 수 있습니다. 이 섹션에서는 이 내용에 대해 논의 하겠지만, 여기에 제시된 모든 내용 또한 Spy에서도 사용 할 수 있습니다.

Mock를 사용할 때 주의해야할 단점이 있습니다. Mock은 인터페이스와 관계를 확인하기 보다는 특정 구현을 테스트 하거나, 상호 작용을 확인하기 위해서 사용합니다. 그럼에도 불구하고, 컴포넌트간 상호 작용을 검사하는 테스트는 대규모 리팩토링을 수행하는 경우에 유용합니다. 우리는 데이터베이스에 데이터를 삽입하기 전에 중요한 유효성 검사를 놓치지 않고 싶습니다.

Creating Mock

Mock을 만들려면, Spock 테스트 코드에서 Mock () 메소드를 호출하면 됩니다.

Creating Mocks
Java
1
2
3
4
5
6
7
8
9
10
 
def "creating example mocks"() {
   given:
      List list = Mock(List)
 
      List list2 = Mock() // preffered way
 
      def list3 = Mock(List)      
}
 

Checking interactions with Mock object

이제 Mock 객체를 만들었으니, when 섹션 내부에서 코드를 실행하는 동안 객체에 어떤 변화가 있었는지 확인할 수 있습니다.

Checking interaction with mock
Java
1
2
3
4
5
6
7
8
9
10
 
def "size method should be executed one time"() {
    given:
        List list
    when:
        list = Mock()
    then:
        1 * list.size()
}
 

우리는 then 섹션에서 상호 작용 여부를 확인할 수 있습니다. Stub에서 사용자 정의 동작을 정의한 것과 같이, Mock과의 상호 작용을 확인하기 위해서는 해당 메서드 호출이 필요로 합니다. 그 전에 예상하고 있는 상호 작용의 제약 조건을 먼저 정의해야 합니다. 여기서는 Mock이 된 객체의 메소드 size ()가 테스트 중에 정확히 한 번만 호출된다고 가정했습니다. 이 테스트 케이스는 제약 조건이 잘못 됐기 때문에, Spock은 실패 했음을 알려줄 것입니다. ( list.size()를 호출하는 부분이 없기 때문)

Error message
Java
1
2
3
4
5
6
7
8
9
 
Too few invocations for:
 
1 * list.size()   (0 invocations)
 
Unmatched invocations (ordered by similarity):
 
None
 

Matching invocations in mocks

Stub에서 했던 것과 동일 방법으로 Mock에서도 동작시키고 싶은 특정 메소드를 찾을 수 있습니다.

Matching invocations in mocks
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
then:
    // method taking no parameter
    1 * list.size()
 
    // explicit parameter value
    1 * list.add(1)
 
    // wildcard as parameter
    1 * list.add(!null)
 
    // detailed check of parameter passed to function
    1 * userService.save({User user -> user.name == 'Lucas'})
 

Detailed matching of parameter in Mock
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
def "should fail due to wrong user"() {
    given:
        UserService userService = Mock()
        User user = new User(name: 'Mefisto')
    when:
        userService.save(user)
    then:
        1 * userService.save({ User u -> u.name == 'Lucas' })
}
 
 
Too few invocations for:
 
1 * userService.save({ User u -> u.name == 'Lucas' })   (0 invocations)
 
Unmatched invocations (ordered by similarity):
 
1 * userService.save(ExampleSpockTest$User(Mefisto))
 

Specifying a cardinality of an interaction

위 예제에서는 메소드가 한 번 호출되었는지에 대해서만 확인 했습니다. 물론 Spock은 훨씬 더 많은 테스트를 할 수 있습니다.

Cardinalities of invocations
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
then:
    // should not be invoked at all
    0 * list.size()
 
    // should be invoked at least one time
    (1.._) * list.size()
 
    // should be invoked at most one time
    (_..1) * list.size()
 
    // any number of calls
    _ * list.size()
 

Check the order of execution

상호 작용이 발생하는 순서를 지정할 수도 있습니다. 그 방법은 여러 개의 then 섹션들을 만들어서 할 수 있습니다

Specifying the order of execution
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
def "should first save object before committing transaction"() {
    given:
        UserService service = Mock()
        Transaction transaction = Mock()
    when:
        service.save(new User())
        transaction.commit()
    then:
        1 * service.save(_ as User)
    then:
        1 * transaction.commit()
}
 

이제 when 세션에서 구문을 변경하면 어떻게 되는지 봅시다.

Failure due to wrong execution order
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
def "should first save object before committing transaction"() {
    given:
        UserService service = Mock()
        Transaction transaction = Mock()
    when:
        transaction.commit()
        service.save(new User())
    then:
        1 * service.save(_ as User)
    then:
        1 * transaction.commit()
}
 
 
Wrong invocation order for:
 
1 * service.save(_ as User)   (1 invocation)
 

예상대로 Spock은 메소드가 잘못된 순서로 호출되었음을 발견하고 테스트가 실패 합니다.

Spy in Spock

정확하게 말하면, Stub이나 Mock과 다르게 Spy는 더미 개체가 아닙니다. 오히려 Spy는 일반 개체에 대한 래퍼라고 말하는 것이 맞을 것입니다. 인터페이스의 특정 메소드의 동작을 재정의 할 수 있으며, Mock처럼 Spy화된 메소드와 상호 작용을 확인할 수 있습니다. UserService 인터페이스를 가지고 Spy에 대해 논의 할 것입니다.

Transaction interface, UserService interface, UserServiceImpl class
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
interface Transaction { }
 
interface UserService {
    boolean isServiceUp()
    void save(User user)
}
 
class UserServiceImpl implements UserService {
 
    UserServiceImpl(Transaction transaction) { }
 
    @Override
    boolean isServiceUp() {
        return false
    }
 
    @Override
    void save(User user) {
        println "Saving user ${user.name} - UserServiceImpl"
    }
}
 

Creating Spy

Spy를 만들기 위해서는 Spock 테스트 코드에서 Spy () 메소드를 호출해야합니다. 앞에서 말했던 것처럼 Spy는 객체를 감싸는 래퍼입니다. 이를 염두해두고, 인터페이스를 사용하여 Spy를 만든 다음, 다른 컴포넌트을 사용하여 Spy를 통해 메소드를 호출하려고 하면, 재정의한 메서드의 반환값으로 Error를 반환 될 것입니다.

Creating Spy from interface
Java
1
2
3
4
5
6
7
8
9
10
11
12
 
def "creating spy from interface is not a good idea"() {
    given:
        UserService service = Spy(UserService)
    expect:
        service.save(new User(name: 'Katherine'))
}
 
 
org.spockframework.mock.CannotInvokeRealMethodException: Cannot invoke real method on interface based mock object
	at org.spockframework.mock.runtime
 

인터페이스에서 Spy를 만드는 대신, 클래스를 사용하는 방식으로 Spy를 만들어 보겠습니다. UserServiceImpl이 Transaction 인수를 가지게 되면서, Spy를 생성하는 방법이 Mock과 Stub에 했던 방법과는 다른 형식이 되었습니다.

Creating Spy from class
Java
1
2
3
4
5
6
7
8
9
 
def "creating spy from class"() {
    given:
        Transaction transaction = Stub(Transaction)
        UserService service = Spy(UserServiceImpl, constructorArgs: [transaction])
    expect:
        service.save(new User(name: 'Katherine'))
}
 

Verifying interactions in Spy

Mock과 같이 Spy화된 클래스의 메소드와 어떤 상호 작용이 발생했는지 확인할 수 있습니다.

Verifying interaction in Spy
Java
1
2
3
4
5
6
7
8
9
10
11
 
def "should call save method once and print text to console"() {
    given:
        Transaction transaction = Stub(Transaction)
        UserService service = Spy(UserServiceImpl, constructorArgs: [transaction])
    when:
        service.save(new User(name: 'Katherine'))
    then:
        1 * service(_)
}
 

좋습니다. Mock과 다른 점은 무엇입니까? 답은 정말 간단합니다. save () 메소드의 동작을 변경하지 않았다는 것을 알 수 있습니다. 따라서 콘솔을 열면 UserServiceImpl에 정의 된 메시지가 출력 되는 것을 확인 할 수 있습니다.

Message printed by the implementation of UserServiceImpl
Java
1
2
3
4
5
6
 
"C:\Program Files...
Saving user Katherine - UserServiceImpl
 
Process finished with exit code 0
 

기본적으로, 특정 클래스의 메소드가 호출되었는지 확인하고 싶거나 여러가지 이유로 원래 구현했던 메소드가 실행하기 위해 Mock을 사용할 수 없을 때, Mock 대신 Spy를 사용해야합니다.

Specifying behaviour in Spy

Mock와 Stub과 같이 특정 메소드가 호출 될 때 수행해야 할 작업을 재정의할 수 있습니다. 다른 두 클래스(Mock, Stub)과는 달리, Spy는 명시적으로 오버라이드 할 메소드를 선택할 수 있고, 다른 메소드의 구현에는 아무런 영향을 미치지 않습니다.

Specifying behaviour in Spy
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
def "should override behaviour of one method only"() {
    given:
        Transaction transaction = Stub(Transaction)
        UserService service = Spy(UserServiceImpl, constructorArgs: [transaction])
        service.isServiceUp() >> true
    expect:
        if (service.isServiceUp()) {
            service.save(new User(name: 'Katherine'))
        }
}
 
 
"C:\Program Files...
Saving user Katherine - UserServiceImpl
 
Process finished with exit code 0
 

위의 예제에서는 isServiceUp () 메서드가 호출 될 때마다 true 값을 반환하도록 했습니다. 그럼에도 불구하고 다른 메소드는 변경되지 않았으므로 ,일단 호출되면 콘솔에 메시지를 출력합니다. 기본적으로 테스트에서 사용하는 클래스에서 하나 또는 여러 메소드의 구현을 재정의 필요하고, 동시에 다른 메소드의 구현은 그대로 두고 싶다면 Stub 대신 Spy를 사용해야 합니다.

저작자표시

'IT > Spock' 카테고리의 다른 글

Spock Testing – Spock tutorial ( 번역 ) 5/5 (0)	2017.03.28
Spock Testing – Spock tutorial ( 번역 ) 4/5 (0)	2017.03.28
Spock Testing – Spock tutorial ( 번역 ) 2/5 (0)	2017.03.28
Spock Testing – Spock tutorial ( 번역 ) 1/5 (0)	2017.03.28

한량 개발자