Spock

1. BDD?

- BDD (Behaviour-Driven Development)

- 이해하기 쉽게 시나리오 형태로 테스트 케이스를 작성하는 방법으로 같략히는 아래와 같은 형식으로 작성한다.

ex) given: 어떤 값이 주어졌을때 | when: 어떤 것을 실행하면 | then: 어떤 값이 나온다.

2. Spock

- Reference : http://spockframework.org

- Groovy로 만들어진 BDD기반 Test Framwork로 groovy언어 뿐만 아니라 같은 JVM (ex: java) 형태로도 작성할 수 있다.

3. Specification: 

4. Fields

- def target = new Target() : 상수처럼 사용되며 선언과 동시에 초기화 한다.

- @Shared // == setupSpec() : 여러 feature method 에서 공통으로 사용할 때 선언한다.

  sql = Sql.newInstance("jdbc:h2:mem:", "org.h2.Driver")

5. Fixture Methods

- def setupSpec() {}     // runs once -  before the first feature method

- def setup() {}           // runs before every feature method

- def cleanup() {}        // runs after every feature method

- def cleanupSpec() {}  // runs once -  after the last feature method

6. Block

- given: test data 설정

- when: 테스트 실행

- then: 결과 검증

- expect: 테스트 실행 & 결과 검증

- cleanup: test data 초기화

- where: data 반복 실행 (Data Driven Testing)

7. Expectation

- with: then, expect에서 주로 사용하며, 검증하는 객체의 호출 depth를 생략할 수 있다.

- verifyAll: soft assertions로 assert를 생략할 수 있다.

8. Documentation & Description

9. Annotations

@Unroll: where:에서 각 data set 별로 테스트 결과를 확인할 수 있도록 설정한다.

@Stepwise: 선언 된 순서대로 기능을 실행하려면 다음을 사용하여 스펙 클래스에 주석을 추가하십시오 

@Timeout: feature,  fixture method에서 실행을위한 타임 아웃을 설정한다.

@Requires({ os.windows })

@Ignore: 이 주석을 포함하는 모든 feature method를 무시한다.

@IgnoreRest: 이 annotation을 가지고있는 모든 feature method만 실행된다. 하나의 메소드 만 빠르게 실행하는 데 유용하다.

@IgnoreIf({ System.getProperty("os.name").contains("windows") })

@FailsWith: 첫째, 즉시 해결할 수없는 알려진 버그를 문서화하는 것이다. 둘째, 특정 조건에서 예외 조건을 바꿀 수 있다.

@Retry(count = 5)

@Retry(exceptions=[IOException])

@AutoCleanup("dispose"):  필드에 선언하며 close()메서드 를 호출

@See("http://spockframework.org/spec")

@Issue("http://my.issues.org/FOO-1")

@Title("This is easy to read")

@Narrative("""

As a user

I want foo

So that bar

""")

10. Comparison to JUnit

11. Test Double

- Mock

ex) def targetMock = Mock(Target) {

          getName() >> "a"

     }

- Stub

ex) Subscriber subscriber = Stub {

         receive("message1") >> "ok"

         receive("message2") >> "fail"

     }

- Spy

- interface가 아닌 class가 필요하고, 생성자를 선택할 수 도 있고, 기본 생성자를 사용할 수 도 있다.

ex) SubscriberImpl subscriber = Spy(constructorArgs: ["Fred"])

     subscriber.receive(_) >> "ok"

- Method 호출 횟수

ex) 1 * subscriber.receive(_)

- Mocking and Stubbing 조합

1 * subscriber.receive("message1") >> "ok"

1 * subscriber.receive("message2") >> "fail"

주의사항

아래 케이스는 then의 stub이 given의 stub을 override해서 null이 리턴됨

given:

subscriber.receive("message1") >> "ok"

when:

publisher.send("message1")

then:

1 * subscriber.receive("message1")

12. Returning Sequences of Values

- ">>"가 아닌 3개 ">>>"를 사용하면 특정 메소드가 여러번 호출될 때 리턴되는 값을 설정할 수 있다.

ex) subscriber.receive(_) >>> ["ok", "error", "error", "ok"]

13. Verify Return Values

subscriber.receive(_) >> { args -> args[0].size() > 3 ? "ok" : "fail" }

subscriber.receive(_) >> { String message -> message.size() > 3 ? "ok" : "fail" }

subscriber.receive(_) >> { throw new InternalError("ouch") }

subscriber.receive(_) >>> ["ok", "fail", "ok"] >> { throw new InternalError() } >> "ok"

14. Simple Groovy Express

java	groovy
String	def : java의 어떤 type도 def로 표현할 수 있다.
List<String>	["a", "b", "c"]
Map<String, Integer>	["a" : 1]
equals	==
get	.

15. Sample Code

- https://github.com/albothyl/project1006/tree/master/kanban-domain/src/test/groovy/com/project/kanban/domain/entity

- https://github.com/albothyl/spock_practice/tree/master/src/test/groovy/com/pratice/application/promotion

---

번 외

테스트의 종류

1. 1. 1. 블랙 박스 테스팅(Black box testing) 
      – 시스템의 내부 설계(Internal system design)는 이
      테스팅 유형에서 고려할 대상이 아니다. 테스트는 요구사항(Requirement) 및 기능성(Functionality)에
      기반해서 이루어진다.

      2. 화이트 박스 테스팅(White box testing) 
      – 이 테스팅은 애플리케이션의 코드 내부의
      로직(Logic)에 대한 지식을 기반으로 수행된다. 글래스 박스(유리상자 혹은 투명상자) 테스팅으로도
      알려져 있다. 이 유형의 테스팅을 수행하기 위해서는 내부적으로 소프트웨어와 코드가 어떻게
      동작하는지를 알고 있어야만 한다. 화이트 박스 테스트는 코드구문(Statements), 분기(Branches)
      경로(Paths), 조건(Conditions) 커버리지 등으로 분류할 수 있다.

      3. 유닛 테스팅(Unit testing) 
      – 각각의 소프트웨어 컴포넌트나 모듈 대상 테스팅을 의미한다.
      일반적으로 테스터가 아니라 프로그래머에 의해 수행되며, 이를 수행하기 위해서는 프로그램
      내부에서 수행되는 코드와 프로그램 설계에 대해 매우 해박한 지식을 가지고 있어야 한다. 테스트
      드라이브 모듈(Test drive modules)이나 테스트 하네스(Test harnesses) 개발이 필요할 수도 있다.

      4. 점진적인 통합 테스팅(Incremental integration testing) 
      – 바텀업(Bottom up) 방식의
      테스팅. 예를 들어, 애플리케이션에 새로운 기능이 추가되는 것에 대해 지속적으로 이어지는
      테스팅과 같은 것이다. 애플리케이션의 기능성과 모듈은 이미 각각 충분히 테스트 되어있는
      상태여야 한다. 프로그래머 혹은 테스터에 의해 수행된다.

      5. 통합 테스팅(Integration testing) 
      – 통합 이후에 결합된 기능들을 검증하기 위한 통합 모듈
      테스팅. 여기서 모듈은 일반적으로 코드 모듈, 개별 애플리케이션, 네트워크 상의 클라이언트와
      서버 애플리케이션 등이 될 수 있다. 이 유형의 테스팅은 특히 클라이언트/서버 및 분산 환경
      시스템에 적절하다.

      6. 기능 테스팅(Functional testing) 
      – 이 유형의 테스팅은 내부적인 부분을 무시하고 결과값이
      요구사항대로 나왔는지, 혹은 그렇지 않은지에 초점을 맞춘다. 블랙박스 타입의 테스팅이
      애플리케이션의 기능 요구사항 검증에 적합하다.

      7. 시스템 테스팅(System testing) 
      – 각각의 요구사항에 대해 전체 시스템이 테스트된다. 전체
      요구사항 명세에 기반한 블랙 박스 타입의 테스팅으로 모든 조합 가능한 시스템의 부분들을
      커버한다.

      8. 엔드-투-엔드 테스팅(End-to-end testing) 
      – 시스템 테스팅과 유사하며, 데이터베이스와
      네트워크 커뮤니케이션의 사용,혹은 다른 종류의 하드웨어, 애플리케이션, 혹은 시스템에 대한 상호
      작용과 같은 실제 사용자 환경을 모방한 환경에서 사용되는 모든 애플리케이션에 대한 테스팅을
      포함한다.

      9. 새너티 테스팅(Sanity testing) 
      – 새로운 소프트웨어 버전이 주요 테스팅 업무를 수행하기에
      충분히 적합한가를 판단하기 위해 수행하는 테스트. 만약 애플리케이션에서 사용 초기에
      크래시(Crash)가 발생한다면, 시스템은 더 이상의 테스팅을 수행할 정도로 충분히 안정적이라고
      말할 수 없으며, 빌드 혹은 애플리케이션은 이 부분을 수정해야 한다.

      10. 리그레션 테스팅(Regression testing) 
      – 애플리케이션의 모든 모듈 및 기능에 대한 수정
      사항을 테스팅 하는 것. 리그레션 테스팅에서 모든 시스템을 커버하는 것은 무척 어려운 일이므로
      일반적으로 이러한 유형의 테스팅에는 자동화 테스팅이 사용된다.

      11. 인수 테스팅(Acceptance testing) 
      – 일반적으로 이 유형의 테스팅은 시스템이 고객이 명세한
      요구사항을 충족했는지를 검증하기 위해 사용된다. 사용자 혹은 고객이 애플리케이션을
      인수(Accept)할 것인지를 결정하기 위해 수행한다.

      12. 부하 테스팅(Load testing) 
      – 어느 지점에서부터 시스템의 반응 시간이
      지연되거나(Degrades), 혹은 반응이 실패하는지를 알아보기 위해 부하의 범위 안에서 웹 사이트를
      테스트 하는 것과 같은, 부하가 걸리는 상황 하에서 시스템의 동작을 검사하기 위해 수행하는
      일종의 퍼포먼스 테스트.

      13. 스트레스 테스팅(Stress testing) 
      – 명세에서 허용된 것 이상의 스트레스를 가해서 어떻게
      그리고 언제 시스템에서 장애가 발생하는지를 체크하기 위한 테스트. 저장 용량을 초과하는
      데이터를 저장하거나, 복잡한 데이터베이스 쿼리를 입력하거나, 시스템에 지속적으로 입력값을
      입력하거나 혹은 데이터베이스에 부하를 거는 것과 같은 심각한 부하를 주는 테스트를 수행한다.

      14. 퍼포먼스 테스팅(Performance testing) 
      – ‘스트레스’ 혹은 ‘부하’ 테스팅과 종종 혼용되어
      사용되는 단어. 시스템이 퍼포먼스 요구사항을 충족하는지 검증하는 행위이다. 이를 위해 각기 다른
      퍼포먼스와 부하 툴을 사용한다.

      15. 사용성 테스팅(Usability testing) 
      – 사용자 친화적(User-friendliness)인지를 점검하는
      것. 애플리케이션의 플로우와 신규 사용자들이 쉽게 애플리케이션을 이해할 수 있는지, 사용자가
      원하는 어떤 시점에서도 적합한 도움말이 제공되는지 등이 테스트된다.

      16. 설치/삭제 테스팅(Install/uninstall testing) 
      – 각기 다른 하드웨어와 소프트웨어 환경 및
      다른 OS 하에서 전체, 부분, 혹은 업그레이드 설치/삭제 프로세스를 테스트한다.

      17. 회복 테스팅(Recovery testing) 
      – 크래쉬, 하드웨어 장애 혹은 다른 심각한 문제들로부터
      시스템이 어떻게 복구되는지를 테스트 하는 것

      18. 보안 테스팅(Security testing) 
      – 해킹이 시스템을 뚫고 들어갈 수 있는지를 검증하는 것. 인가
      받지 않은 내부 혹은 외부의 액세스로부터 시스템이 어떻게 스스로를 방어하는지에 대해
      테스트한다. 외부 공격으로부터 시스템, 데이터베이스가 안전한지를 체크한다.

      19. 호환성 테스팅(Compatibility testing) 
      – 특정한 하드웨어/소프트웨어/OS/네트워크 환경 및
      각기 다른 조합 하에서 소프트웨어가 어떻게 동작하는지를 테스트한다.

      20. 비교 테스팅(Comparison testing) 
      – 앞서 출시된 제품 혹은 유사한 제품과 비교해 제품의
      장단점을 비교함

      21. 알파 테스팅(Alpha testing) 
      – 이 유형의 테스팅을 위해 사내에서 가상 유저 환경이 조성될 수
      있다. 개발의 마지막 부분에서 이 테스트가 수행된다. 이 테스팅의 결과로 사소한 디자인 변경 등이
      이루어 질 수 있다.

      22. 베타 테스팅(Beta testing) 
      – 일반적으로 엔드 유저에 의해 완료되는 테스팅. 상용화를 위한 애플
      리케이션 릴리즈 이전의 최종 테스팅이다.

      23. A/B 테스팅 
      - 사용자가 같은 기능을 실행했을때 조건에 따라 다른 결과를 보여줘서 어느 결과가 더 좋은지 확인하는 테스팅이다.

2. 테스트와 관련된 유용한 유틸 
   
   1. random-beans : 지정한 클래스의 필드를 램덤한 값으로 채워준다. 
   2. wiremock : 가상 서버를 띄워 사용자가 입력한 응답을 리턴하도록 한다.
3. 테스트 더블(Test Double)
   
   1. Stub : 사용자가 입력한 input에 따라 다른 응답을 리턴한다.
   2. Mock : 사용자가 지정한 응답을 리턴한다.
4. UI tests
   
   1. Karma.js
5. AngularJS integration tests
   
   1. Protractor
6. Behaviour-driven
   
   1. Cucumber
   2. Spock
7. Performance tests
   
   1. Gatling
   2. Jmeter