블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 받은 트랙백

글 보관함

calendar

          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            


Specification Re-use in Rest-Assured with ResponseSpecBuilder and RequestSpecBuilder





Rest-Assured로 여러분의 API에서 테스트를 작성할 때마다 확인해야 할 공통된 expected results가 있을 수 있습니다. API Call마다 매번 체크해야할 expected results 같은 것들 말이죠. 




아래 간단한 테스트를 한번 예를 들어 보겠습니다.




@Test
public void testSomeApi()
{
    when().
        get("http://yourWebsiteAddress.com/someAPIcall").
    then().
        statusCode(200).
        body(containsString("Your Website Title"));
}


이 테스트는 http://yourWebsiteAddress.com 의 someAPIcall을 호출 하는 것입니다. 

그리고 나서 HTTP response의 status code가 200 임을 확인하고 (OK response) response의 body에 “Your Website Title“ 라는 string을 포함하는 지의 여부를 체크 하는 것입니다.


여러분의 웹사이트에 대해 아주 많은 API call을 테스트 해야 된다고 가정해 봅시다.

아마도 모든 API 호출이 200의 상태 코드를 반환하고 'Your Website Title'문자열이 모든 호출 본문에 존재하는지 테스트하는 것이 합리적 일 것입니다. 매번 테스트에 이것을 사용하는 대신, 다음과 같이 @BeforeClass 어노테이션 된 메소드에서 테스트 클래스의 맨 위에 ResponseSpecBuilder를 지정할 수 있습니다.



import com.jayway.restassured.builder.ResponseSpecBuilder;
import com.jayway.restassured.specification.ResponseSpecification;
import org.junit.BeforeClass;

import static org.hamcrest.Matchers.containsString;

public class ResponseSpecTest {
    
    public static ResponseSpecBuilder builder;
    public static ResponseSpecification responseSpec;
    
    @BeforeClass
    public static void setupResponseSpecBuilder()
    {
        builder = new ResponseSpecBuilder();
        
        builder.expectStatusCode(200);
        
        builder.expectBody(containsString("Your Website Title"));
        
        responseSpec = builder.build();
    }
}




이제 여러분은  testSomeApi()를 아래와 같이 재작성 하실 수 있습니다.


@Test
public void testSomeApi()
{
    when().
        get("http://yourWebsiteAddress.com/someAPIcall").
    then().
        spec(responseSpec);
}


이렇게 간단히 request 의 then() 부분에 spec(responseSpec) 만 호출하면 됩니다. 그러면 status code 200을 확인하고 response의 body에 해당 string이 있는지 확인 하게 됩니다.


그리고 다른 테스트에서도 이 request data를 재사용하고 싶다면 이와 비슷하게 하기만 하면 됩니다. 

아래 테스트에서 API에 POST 요청을 할 때 헤더에 인증 코드를 지정하고 로그인 ID 매개 변수를 지정합니다.



@Test
public void testAnApiPostCall()
{
    given().
        header("Authorization", "abcd-1234-xyz").
        param("loginID", "joebloggs").
    when().
        post("http://yourWebsiteAddress.com/somePostAPI").
    then().
        body("result.message", equalTo("success"));
}



테스트에서 POST 호출을 할 때마다 항상 헤더에 권한 코드를 지정하고 매개 변수로 loginID를 지정해야한다고 가정합니다. 아래 예제와 같이 테스트 코드의 시작 부분에 RequestSpecBuilder를 지정할 수 있습니다.



import com.jayway.restassured.builder.RequestSpecBuilder;
import com.jayway.restassured.specification.RequestSpecification;
import org.junit.BeforeClass;

public class RequestSpecTest {

    public static RequestSpecBuilder builder;
    public static RequestSpecification requestSpec;

    @BeforeClass
    public static void setupRequestSpecBuilder()
    {
        builder = new RequestSpecBuilder();

        builder.addHeader("Authorization", "abcd-123-xyz");

        builder.addParameter("loginID", "joebloggs");

        requestSpec = builder.build();
    }

}




이제 아래와 같이 원래의 testAnApiPostCall () 테스트를 다시 작성할 수 있으며, 인증 헤더와 loginID 매개 변수를 필요로하는 모든 API 호출에서 requestSpec을 재사용 할 수 있습니다.


@Test
public void testAnApiPostCall()
{
    given().
        spec(requestSpec).
    when().
        post("http://yourWebsiteAddress.com/somePostAPI").
    then().
        body("result.message", equalTo("success"));
}

이 예제가 유용하게 사용되기를 바랍니다. 이 기능은 테스트 할 여러 가지 API가 많지만 모두 공통된 결과를 산출하는 경우에 특히 유용합니다. 최소한 모든 API 호출이 응답 코드 200을 리턴하는지 확인하기위한 점검을 추가하는 것이 유용합니다.




[Hamcrest] The Hamcrest Tutorial

2017.05.18 14:48 | Posted by 솔웅


The Hamcrest Tutorial



Introduction

Hamcrest is a framework for writing matcher objects allowing 'match' rules to be defined declaratively. There are a number of situations where matchers are invaluble, such as UI validation, or data filtering, but it is in the area of writing flexible tests that matchers are most commonly used. This tutorial shows you how to use Hamcrest for unit testing.


Hamcrest는 'match'rule을 선언적으로 정의 해 matcher objects를 작성하기위한 framework입니다. UI 유효성 UI validation 또는 데이터 필터링과 같이 matchers가 사용할 수 없는 상황도 많이 있지만 matcher가 가장 일반적으로 사용되는 곳은 flexible tests를 작성하는 영역에 있습니다. 이 tutorial에서는 unit testing를 위해 Hamcrest를 사용하는 방법을 보여줍니다.


When writing tests it is sometimes difficult to get the balance right between overspecifying the test (and making it brittle to changes), and not specifying enough (making the test less valuable since it continues to pass even when the thing being tested is broken). Having a tool that allows you to pick out precisely the aspect under test and describe the values it should have, to a controlled level of precision, helps greatly in writing tests that are "just right". Such tests fail when the behaviour of the aspect under test deviates from the expected behaviour, yet continue to pass when minor, unrelated changes to the behaviour are made.


테스트를 작성할 때 테스트를 지나치게 자세하게 지정하는 것 (그리고 수정이 어렵게 하는 것)과 충분한 테스트를 하지 않는 것 사이의 균형을 잡기가 어렵기 때문에 (이럴 경우 테스트 대상에 문제가 생긴 경우에도 테스트가 pass 될 수 있어 해당 테스트가 유효하지 않게 됩니다.) 테스트 할 aspect를 정확하게 선택할 수 있도록 하고, 가져야 할 값을 describe 해서 정밀하게 제여할 수 있도록 하는 도구를 사용하면 "just right" 테스트를 작성하는 데 크게 도움이됩니다. 이러한 테스트는 테스트중인 aspect의 동작이 예상되는 벗어나는 경우 fail 하고 , minor 한 변화나 테스트 범위에서 벗어난 변경이 있는 경우 pass 해야 합니다.



My first Hamcrest test

We'll start by writing a very simple JUnit 3 test, but instead of using JUnit's assertEquals methods, we use Hamcrest's assertThatconstruct and the standard set of matchers, both of which we statically import:


아래 간단한 JUnit 3 test를 작성할 겁니다. JUnit의 assertEquals methods를 사용하는 대신에 Hamcrest의 assertThat construct와 matchers의 표준 세트를 사용할 겁니다. 이 둘은 정적으로 import 합니다.



``` import static org.hamcrest.MatcherAssert.assertThat; import static org.hamcrest.Matchers.*;


import junit.framework.TestCase;


public class BiscuitTest extends TestCase { public void testEquals() { Biscuit theBiscuit = new Biscuit("Ginger"); Biscuit myBiscuit = new Biscuit("Ginger"); assertThat(theBiscuit, equalTo(myBiscuit)); } } ```



The assertThat method is a stylized sentence for making a test assertion. In this example, the subject of the assertion is the object biscuit that is the first method parameter. The second method parameter is a matcher for Biscuit objects, here a matcher that checks one object is equal to another using the Object equals method. The test passes since the Biscuit class defines an equals method.


assertThat method는 test assertion을 만들기 위한 양식화 된 문장입니다. 이 예에서는 assertion의 subject는 첫 번째 method 매개 변수 인 object biscuit입니다. 두 번째 method 매개 변수는 Biscuit objects에 대한 matcher입니다. 여기에서 한 object를 검사하는 matcher는 Object equals method를 사용하는것과 같습니다. 이 테스트는 Biscuit 클래스가 equals method를 정의하기 때문에 pass 하게 됩니다.



If you have more than one assertion in your test you can include an identifier for the tested value in the assertion:


하나 이상의 assertion이 있는 경우 테스트 된 값에 대한 identifier를 assertion에 포함 할 수 있습니다.


assertThat("chocolate chips", theBiscuit.getChocolateChipCount(), equalTo(10)); assertThat("hazelnuts", theBiscuit.getHazelnutCount(), equalTo(3));



Other test frameworks



Hamcrest has been designed from the outset to integrate with different unit testing frameworks. For example, Hamcrest can be used with JUnit 3 and 4 and TestNG. (For details have a look at the examples that come with the full Hamcrest distribution.) It is easy enough to migrate to using Hamcrest-style assertions in an existing test suite, since other assertion styles can co-exist with Hamcrest's.


Hamcrest는 처음부터 다른 unit testing framework와 통합되도록 설계되었습니다. 예를 들어, Hamcrest는 JUnit 3과 4 및 TestNG와 함께 사용할 수 있습니다. (자세한 내용은 전체 Hamcrest distribution과 함께 제공되는 예제를 참조하십시오.) 다른 assertion 스타일이 Hamcrest와 같이 사용될 수 있기 때문에 기존 test suite에서 Hamcrest-style assertions를 사용하는 것으로 마이그레이션하는 것은 쉽습니다.


Hamcrest can also be used with mock objects frameworks by using adaptors to bridge from the mock objects framework's concept of a matcher to a Hamcrest matcher. For example, JMock 1's constraints are Hamcrest's matchers. Hamcrest provides a JMock 1 adaptor to allow you to use Hamcrest matchers in your JMock 1 tests. JMock 2 doesn't need such an adaptor layer since it is designed to use Hamcrest as its matching library. Hamcrest also provides adaptors for EasyMock 2. Again, see the Hamcrest examples for more details.


Hamcrest는 또한 mock objects framework와 같이 사용 될 수 있습니다. 그러려면 mock objects framework의 matcher와 Hamcrest의 matcher 에 대한 concept을 연결해 주도록 adaptors를 사용하면 됩니다. 예를 들어, JMock 1의 constraints는 Hamcrest의 matchers입니다. Hamcrest는 JMock 1 테스트에서 Hamcrest matchers를 사용할 수 있도록 JMock 1 어댑터를 제공합니다. JMock 2는 Hamcrest를 매칭 라이브러리로 사용하기 때문에 그러한 adaptor layer가 필요하지 않습니다. Hamcrest는 EasyMock 2 용 어댑터도 제공합니다. 자세한 내용은 Hamcrest 예제를 참조하십시오.



A tour of common matchers



Hamcrest comes with a library of useful matchers. Here are some of the most important ones.


Hamcrest는 유용한 matchers 라이브러리를 제공합니다. 그 중에 중요한 것들 입니다.



    Core
    • anything - always matches, useful if you don't care what the object under test is
    • describedAs - decorator to adding custom failure description
    • is - decorator to improve readability - see "Sugar", below

  • Logical
    • allOf - matches if all matchers match, short circuits (like Java &&)
    • anyOf - matches if any matchers match, short circuits (like Java ||)
    • not - matches if the wrapped matcher doesn't match and vice versa

  • Object
    • equalTo - test object equality using Object.equals
    • hasToString - test Object.toString
    • instanceOfisCompatibleType - test type
    • notNullValuenullValue - test for null
    • sameInstance - test object identity

  • Beans
    • hasProperty - test JavaBeans properties

  • Collections
    • array - test an array's elements against an array of matchers
    • hasEntryhasKeyhasValue - test a map contains an entry, key or value
    • hasItemhasItems - test a collection contains elements
    • hasItemInArray - test an array contains an element

  • Number
    • closeTo - test floating point values are close to a given value
    • greaterThangreaterThanOrEqualTolessThanlessThanOrEqualTo - test ordering

  • Text
    • equalToIgnoringCase - test string equality ignoring case
    • equalToIgnoringWhiteSpace - test string equality ignoring differences in runs of whitespace
    • containsStringendsWithstartsWith - test string matching



Sugar


Hamcrest strives to make your tests as readable as possible. For example, the is matcher is a wrapper that doesn't add any extra behavior to the underlying matcher. The following assertions are all equivalent:


Hamcrest는 여러분이 최대한 readable한 테스트를 만들 수 있도록 노력합니다. 예를 들어, is matcher는 기본이되는 matcher에 추가의 동작을 추가하지 않는 wrapper 입니다. (어떤 동작을 하지는 않고 단지 가독성 -readable- 을 제공하기 위한 것).

아래 assertion 들은 다 똑 같습니다.



assertThat(theBiscuit, equalTo(myBiscuit)); assertThat(theBiscuit, is(equalTo(myBiscuit))); assertThat(theBiscuit, is(myBiscuit));


The last form is allowed since is(T value) is overloaded to return is(equalTo(value)).


마지막 form은 is(T value)가 is(equalTo (value))를 return하도록 overload 되어 있기 때문에 가능합니다.



Writing custom matchers



Hamcrest comes bundled with lots of useful matchers, but you'll probably find that you need to create your own from time to time to fit your testing needs. This commonly occurs when you find a fragment of code that tests the same set of properties over and over again (and in different tests), and you want to bundle the fragment into a single assertion. By writing your own matcher you'll eliminate code duplication and make your tests more readable!


Hamcrest는 많은 유용한 matchers와 함께 번들로 제공되지만, 테스트 요구에 맞추기 위해 수시로 자신 만의 템플릿을 만들어야 할 필요가있을 것입니다. 이것은 일반적으로  동일한 properties set을 반복적으로 테스트 하는 (다른 테스트 들에서도) code의 fragment를 발견 했을 때 그리고 이 fragment를 단일 assertion으로 묶으려는 경우에 해당 될 겁니다. 자신 만의 matcher를 작성함으로써 코드 중복을 제거하고 테스트의 가독성을 훨씬 높일 수 있습니다!



Let's write our own matcher for testing if a double value has the value NaN (not a number). This is the test we want to write:


double 값의 값이 NaN (숫자가 아님) 인 경우를 테스트하기 위해 자체 matcher를 작성해 보겠습니다. 아래 그 예제가 있습니다.



public void testSquareRootOfMinusOneIsNotANumber() { assertThat(Math.sqrt(-1), is(notANumber())); }


And here's the implementation:


``` package org.hamcrest.examples.tutorial;

import org.hamcrest.Description; import org.hamcrest.Factory; import org.hamcrest.Matcher; import org.hamcrest.TypeSafeMatcher;

public class IsNotANumber extends TypeSafeMatcher {

@Override public boolean matchesSafely(Double number) { return number.isNaN(); }

public void describeTo(Description description) { description.appendText("not a number"); }

@Factory public static Matcher notANumber() { return new IsNotANumber(); }

} ```



The assertThat method is a generic method which takes a Matcher parameterized by the type of the subject of the assertion. We are asserting things about Double values, so we know that we need a Matcher<Double>. For our Matcher implementation it is most convenient to subclass TypeSafeMatcher, which does the cast to a Double for us. We need only implement the matchesSafely method - which simply checks to see if the Double is NaN - and the describeTo method - which is used to produce a failure message when a test fails. Here's an example of how the failure message looks:


assertThat method는, assertion의 subject의 type에 의해 파라미터 화 된 Matcher를 취하는 generic method입니다. 우리는 Double 값에 대해 asserting하고 있으므로 Matcher <Double>이 필요하다는 것을 알고 있습니다. 이 Matcher를 구현하는데 있어 TypeSafeMatcher를 서브 클래스로 implement 하는 것이 가장 좋습니다. TypeSafeMatcher는 Double로 형변환을 하게 됩니다. matchesSafely method와 describeTo method만 implement 하면 됩니다. matchesSafely method는 단순히 Double이 NaN인지 확인하고 describeTo method 테스트가 fail 할 경우 오류 메시지를 생성하는 데 사용됩니다. 다음은 failure message가 표시되는 예입니다.



assertThat(1.0, is(notANumber()));


fails with the message


java.lang.AssertionError: Expected: is not a number got : <1.0>



The third method in our matcher is a convenience factory method. We statically import this method to use the matcher in our test:


우리의 matcher에서 세 번째 method는 편리한 factory method 입니다. test에서 matcher를 사용하기 위해 이 method를 정적(statically)으로 가져옵니다.


``` import static org.hamcrest.MatcherAssert.assertThat; import static org.hamcrest.Matchers.*;

import static org.hamcrest.examples.tutorial.IsNotANumber.notANumber;

import junit.framework.TestCase;

public class NumberTest extends TestCase {

public void testSquareRootOfMinusOneIsNotANumber() { assertThat(Math.sqrt(-1), is(notANumber())); } } ```



Even though the notANumber method creates a new matcher each time it is called, you should not assume this is the only usage pattern for your matcher. Therefore you should make sure your matcher is stateless, so a single instance can be reused between matches.


비록 notANumber method가 호출 될 때마다 new matcher를 생성하지만, 이것이 matcher의 유일한 사용 patter 이라고 예단 해서는 안됩니다. 여러분은 이 matcher가 stateless 임을 유념해야 합니다. single instance 가 matcher들 사이에서 재사용 될 수 있습니다.



Sugar generation



If you produce more than a few custom matchers it becomes annoying to have to import them all individually. It would be nice to be able to group them together in a single class, so they can be imported using a single static import much like the Hamcrest library matchers. Hamcrest helps out here by providing a way to do this by using a generator.


여러가지 custom matchers를 만들었다면 이들을 각각 import 하는 일이 성가실 겁니다. 하나의 클래스에서 이들을 그룹화 하면 좋겠죠. 그렇게 하면 Hamcrest 라이브러리 matchers와 같이 single static import를 사용하여 한꺼번에 import 할 수 있을 겁니다. Hamcrest는 generator를 사용하여 이를 수행 할 수있는 방법을 제공합니다.


First, create an XML configuration file listing all the Matcher classes that should be searched for factory methods annotated with the org.hamcrest.Factory annotation. For example:


먼저, 모든 Matcher classes을 리스팅 한 XML configuration file을 생성합니다. 이것은 org.hamcrest.Factory annotation과 함께 factory methods annotated를 하기 위해 검색 될 겁니다. 예 :


```

```


Second, run the org.hamcrest.generator.config.XmlConfigurator command-line tool that comes with Hamcrest. This tool takes the XML configuration file and generates a single Java class that includes all the factory methods specified by the XML file. Running it with no arguments will display a usage message. Here's the output for the example.


둘째, Hamcrest와 함께 제공되는 org.hamcrest.generator.config.XmlConfigurator command-line tool를 실행하십시오. 이 도구는 XML 구성 파일을 사용하여 XML 파일에 지정된 모든 팩토리 method를 포함하는 단일 Java 클래스를 생성합니다. 인수없이 실행하면 사용법 메시지가 표시됩니다. 이 예제의 결과는 다음과 같습니다.



``` // Generated source. package org.hamcrest.examples.tutorial;

public class Matchers {

public static org.hamcrest.Matcher is(T param1) { return org.hamcrest.core.Is.is(param1); }

public static org.hamcrest.Matcher is(java.lang.Class param1) { return org.hamcrest.core.Is.is(param1); }

public static org.hamcrest.Matcher is(org.hamcrest.Matcher param1) { return org.hamcrest.core.Is.is(param1); }

public static org.hamcrest.Matcher notANumber() { return org.hamcrest.examples.tutorial.IsNotANumber.notANumber(); }

} ```



Finally, we can update our test to use the new Matchers class.


마지막으로 new Matchers class를 사용하도록 아래처럼 업데이트 합니다.



``` import static org.hamcrest.MatcherAssert.assertThat;

import static org.hamcrest.examples.tutorial.Matchers.*;

import junit.framework.TestCase;

public class CustomSugarNumberTest extends TestCase {

public void testSquareRootOfMinusOneIsNotANumber() { assertThat(Math.sqrt(-1), is(notANumber())); } } ```



Notice we are now using the Hamcrest library is matcher imported from our own custom Matchers class.


Notice 우리는 custom Matchers class 에서 importe된 matcher 인 Hamcrest library를 사용하게 됩니다.



Where next?

See FurtherResources.

--Tom White







Testing and validating REST services in Java is harder than in dynamic languages such as Ruby and Groovy. REST Assured brings the simplicity of using these languages into the Java domain. For example if your HTTP server returns the following JSON at “http://localhost:8080/lotto/{id}”:


Ruby 및 Groovy와 같은 동적 언어보다 Java에서 REST 서비스를 테스트하고 유효성을 검사하는 것은 더 어렵습니다. REST Assured는 이러한 언어를 Java 도메인에서

 사용하는 간단한 방법을 제공합니다. 예를 들어 HTTP 서버가 "http : // localhost : 8080 / lotto / {id}"에 다음 JSON을 반환하는 경우 :


{
   "lotto":{
      "lottoId":5,
      "winning-numbers":[2,45,34,23,7,5,3],
      "winners":[
         {
            "winnerId":23,
            "numbers":[2,45,34,23,3,5]
         },
         {
            "winnerId":54,
            "numbers":[52,3,12,11,18,22]
         }
      ]
   }
}


You can easily use REST Assured to validate interesting things from the response:

REST Assured를 사용하여 response에서 원하는 것을 검증 할 수 있습니다.


@Test public void
lotto_resource_returns_200_with_expected_id_and_winners() {
    
    when().
            get("/lotto/{id}", 5).
    then().
            statusCode(200).
            body("lotto.lottoId", equalTo(5), 
                 "lotto.winners.winnerId", containsOnly(23, 54));

}


Looks easy enough? Why not give it a spin? See getting starting and usage guide.


정말 쉽죠? 널리 알려 주세요? getting starting 및 usage guide를 참조하세요.





Getting Started


Maven / Gradle Users


Add the following dependency to your pom.xml:


아래 dependency를 pom.xml에 추가하세요.


REST Assured

Includes JsonPath and XmlPath

Maven:

<dependency>
      <groupId>io.rest-assured</groupId>
      <artifactId>rest-assured</artifactId>
      <version>3.0.3</version>
      <scope>test</scope>
</dependency>

Gradle:

testCompile 'io.rest-assured:rest-assured:3.0.3'

Notes

  1. You should place rest-assured before the JUnit dependency declaration in your pom.xml / build.gradle in order to make sure that the correct version of Hamcrest is used.
  2. REST Assured includes JsonPath and XmlPath as transitive dependencies
Notes

1. Hamcrest의 올바른 버전이 사용되는지 확인하기 위해 pom.xml / build.gradle에서 JUnit dependency declaration 앞에 rest-assured를 넣어야 합니다.
2. REST Assured는 JsonPath 및 XmlPath를 transitive dependencies로 include합니다.

JsonPath


Standalone JsonPath (included if you depend on the rest-assured artifact). Makes it easy to parse JSON documents. Note that this JsonPath implementation uses Groovy's GPath syntax and is not to be confused with Kalle Stenflo's JsonPath implementation.

Standalone JsonPath (rest-assured artifact에 의존하는 경우 포함됨). 이렇게 함으로서 JSON 문서를 쉽게 파싱 할 수 있습니다. 이 JsonPath 구현은 Groovy의 GPath 구문을 사용하므로 Jayway의 다른 JsonPath 구현과 혼동하지 않아야합니다.


Maven:

<dependency>
      <groupId>io.rest-assured</groupId>
      <artifactId>json-path</artifactId>
      <version>3.0.3</version>
</dependency>

Gradle:

compile 'io.rest-assured:json-path:3.0.3'


XmlPath


Stand-alone XmlPath (included if you depend on the rest-assured artifact). Makes it easy to parse XML documents.

 Stand-alone XmlPath (rest-assured artifact에 의존하는 경우 포함됨). 이렇게 함으로서 XML 문서를 쉽게 파싱 할 수 있습니다.


Maven:

<dependency>
      <groupId>io.rest-assured</groupId>
      <artifactId>xml-path</artifactId>
      <version>3.0.3</version>
</dependency>

Gradle:

compile 'io.rest-assured:xml-path:3.0.3'


JSON Schema Validation


If you want to validate that a JSON response conforms to a Json Schema you can use the json-schema-validator module:

JSON 응답이 Json Schema를 따르는 지 확인하려면 json-schema-validator 모듈을 사용할 수 있습니다.


Maven:

<dependency>
      <groupId>io.rest-assured</groupId>
      <artifactId>json-schema-validator</artifactId>
      <version>3.0.3</version>
      <scope>test</scope>
</dependency>

Gradle:

testCompile 'io.rest-assured:json-schema-validator:3.0.3'


Refer to the documentation for more info.

자세한 내용은 설명서를 참조하십시오.


Spring Mock Mvc


If you're using Spring Mvc you can now unit test your controllers using the RestAssuredMockMvc API in the spring-mock-mvc module. For this to work you need to depend on the spring-mock-mvc module:

Spring Mvc를 사용하고 있다면 Spring Mock-mvc 모듈의 RestAssuredMockMvc API를 사용하여 controllers를 유닛 테스트 할 수 있습니다. 이 작업을 하기 위해서는 spring-mock-mvc 모듈에 의존해야합니다.


Maven:

<dependency>
      <groupId>io.rest-assured</groupId>
      <artifactId>spring-mock-mvc</artifactId>
      <version>3.0.3</version>
      <scope>test</scope>
</dependency>

Gradle:

testCompile 'io.rest-assured:spring-mock-mvc:3.0.3'


Scala Support


If you're using Scala you may leverage the scala-support module. For this to work you need to depend on the scala-support module:


Scala를 사용하는 경우 Scala 지원 모듈을 활용할 수 있습니다. 이 작업을 수행하려면 scala-support 모듈에 의존해야합니다.


SBT:

libraryDependencies += "io.rest-assured" % "scala-support" % "3.0.3"

Maven:

<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>scala-support</artifactId>
    <version>3.0.3</version>
    <scope>test</scope>
</dependency>

Gradle:

testCompile 'io.rest-assured:scala-support:3.0.3'


Non-maven users


Download REST Assured and Json Schema Validator (optional). You can also download XmlPath and/or JsonPath separately if you don't need REST Assured. If you're using Spring Mvc then you can download the spring-mock-mvc module as well. If you're using Scala you may optionally download the scala-support module. Extract the distribution zip file and put the jar files in your class-path.


REST Assured 및 Json Schema Validator (선택 사항)를 다운로드하십시오. REST Assured가 필요하지 않은 경우 XmlPath 와 JsonPath를 별도로 다운로드 할 수도 있습니다. 당신이 Spring Mvc를 사용하고 있다면 당신은 spring-mock-mvc 모듈을 다운로드 할 수있습니다. Scala를 사용하는 경우 선택적으로 Scala 지원 모듈을 다운로드 할 수 있습니다. 배포 zip 파일의 압축을 풀고 jar 파일을 클래스 경로에 넣습니다.





Static imports


In order to use REST assured effectively it's recommended to statically import methods from the following classes:

REST assured를 효과적으로 사용하려면 다음 클래스에서 메소드를 정적으로 가져 오는 것이 좋습니다.


io.restassured.RestAssured.*
io.restassured.matcher.RestAssuredMatchers.*
org.hamcrest.Matchers.*


If you want to use Json Schema validation you should also statically import these methods:

Json Schema 유효성 검사를 사용하려면 다음 메소드를 정적으로 가져와야합니다.


io.restassured.module.jsv.JsonSchemaValidator.*


Refer to Json Schema Validation section for more info.

자세한 내용은 Json 스키마 유효성 검사 섹션을 참조하십시오.


If you're using Spring MVC you can use the spring-mock-mvc module to unit test your Spring Controllers using the Rest Assured DSL. To do this statically import the methods from RestAssuredMockMvc instead of importing the methods from io.rest-assured.RestAssured and io.rest-assured.matcher.RestAssuredMatchers:


Spring MVC를 사용한다면, Spring-mock-mvc 모듈을 사용하여 Rest Assured DSL을 사용하여 Spring Controllers를 테스트 할 수있다. 이렇게하려면 io.rest-assured.RestAssured 및 io.rest-assured.matcher.RestAssuredMatchers에서 메서드를 가져 오는 대신 RestAssuredMockMvc에서 메서드를 정적으로 가져옵니다.


io.restassured.module.mockmvc.RestAssuredMockMvc.*
io.restassured.matcher.RestAssuredMatchers.*


Version 2.x


If you need to depend on an older version replace groupId io.rest-assured with com.jayway.restassured.


이전 버전에 의존해야한다면 com.jayway.restassured로 groupId io.rest-assured를 교체하십시오.


Documentation


When you've successfully downloaded and configured REST Assured in your classpath please refer to the usage guide for examples.


클래스 패스에 REST Assured를 성공적으로 다운로드하고 구성한 경우 예제를 보려면 사용 설명서를 참조하십시오.






Usage Guide




Note that if you're using version 1.9.0 or earlier please refer to the legacy documentation.


버전 1.9.0 이전 버전을 사용하는 경우 기존 설명서를 참조하십시오.


REST Assured is a Java DSL for simplifying testing of REST based services built on top of HTTP Builder. It supports POST, GET, PUT, DELETE, OPTIONS, PATCH and HEAD requests and can be used to validate and verify the response of these requests.


REST Assured는 HTTP 빌더 위에 구축 된 REST 기반 서비스의 테스트를 단순화하기위한 Java DSL입니다. POST, GET, PUT, DELETE, OPTIONS, PATCH 및 HEAD 요청을 지원하며 이러한 요청의 응답을 확인하고 검증하는 데 사용할 수 있습니다.




Contents

  1. Static imports
  2. Examples
  3. JSON Example
  4. JSON Schema Validation
  5. XML Example
  6. Advanced
  7. XML
  8. JSON
  9. Additional Examples
  10. Note on floats and doubles
  11. Note on syntax (syntactic sugar)
  12. Getting Response Data
  13. Extracting values from the Response after validation
  14. JSON (using JsonPath)
  15. XML (using XmlPath)
  16. Single Path
  17. Headers, cookies, status etc
  18. Multi-value headers
  19. Multi-value cookies
  20. Detailed Cookies
  21. Specifying Request Data
  22. Invoking HTTP resources
  23. Parameters
  24. Multi-value Parameter
  25. No-value Parameter
  26. Path Parameters
  27. Cookies
  28. Headers
  29. Content-Type
  30. Request Body
  31. Verifying Response Data
  32. Response Body
  33. Cookies
  34. Status
  35. Headers
  36. Content-Type
  37. Full body/content matching
  38. Use the response to verify other parts of the response
  39. Measuring response time
  40. Authentication
  41. Basic
  42. Preemptive
  43. Challenged
  44. Digest
  45. Form
  46. CSRF
  47. OAuth
  48. OAuth1
  49. OAuth2
  50. Multi-part form data
  51. Object Mapping
  52. Serialization
  53. Content-Type based Serialization
  54. Create JSON from a HashMap
  55. Using an Explicit Serializer
  56. Deserialization
  57. Content-Type based Deserialization
  58. Custom Content-Type Deserialization
  59. Using an Explicit Deserializer
  60. Configuration
  61. Custom
  62. Parsers
  63. Custom
  64. Default
  65. Default Values
  66. Specification Re-use
  67. Filters
  68. Ordered Filters
  69. Response Builder
  70. Logging
  71. Request Logging
  72. Response Logging
  73. Log if validation fails
  74. Root Path
  75. Path Arguments
  76. Session Support
  77. Session Filter
  78. SSL
  79. SSL invalid hostname
  80. URL Encoding
  81. Proxy Configuration
  82. Static Proxy Configuration
  83. Request Specification Proxy Configuration
  84. Detailed configuration
  85. Encoder Config
  86. Decoder Config
  87. Session Config
  88. Redirect DSL
  89. Connection Config
  90. JSON Config
  91. HTTP Client Config
  92. SSL Config
  93. Param Config
  94. Spring Mock Mvc Module
  95. Bootstrapping RestAssuredMockMvc
  96. Asynchronous Requests
  97. Adding Request Post Processors
  98. Adding Result Handlers
  99. Using Result Matchers
  100. Interceptors
  101. Specifications
  102. Resetting RestAssuredMockMvc
  103. Spring MVC Authentication
    1. Using Spring Security Test
    2. Injecting a User
  104. Note on parameters
  105. Scala Support Module
  106. Kotlin
  107. More Info






Using Hamcrest for testing - Tutorial





1. Purpose of the Hamcrest matcher framework


Hamcrest is a framework for software tests. Hamcrest allows checking for conditions in your code via existing matchers classes. It also allows you to define your custom matcher implementations.


Hamcrest는 소프트웨어 테스트를위한 framework입니다. Hamcrest는 기존 matchers 클래스를 통해 코드의 조건을 확인할 수 있습니다. 또한 사용자 정의 matcher implementations 을 정의 할 수 있습니다.


To use Hamcrest matchers in JUnit you use the assertThat statement followed by one or several matchers.


JUnit에서 Hamcrest matcher를 사용하려면 assertThat 문 뒤에 하나 또는 여러 개의 matchers를 사용합니다.


Hamcrest is typically viewed as a third generation matcher framework. The first generation used assert(logical statement) but such tests were not easily readable. The second generation introduced special methods for assertions, e.g., assertEquals(). This approach leads to lots of assert methods. Hamcrest uses assertThat method with a matcher expression to determine if the test was succesful. See Wiki on Hamcrest for more details.


Hamcrest는 일반적으로 3 세대 정규식 framework로 간주됩니다. 1 세대는 assert(logical statement)을 사용했지만 그러한 테스트는 쉽게 읽을 수 없었습니다. 2 세대에서는 assertEquals()와 같은 assertions을 위한 특수한 메소드가 도입되었습니다. 이 접근법은 많은 assert methods 를 필요로 합니다. Hamcrest는 assertThat 메서드를 사용하여 테스트가 성공적인지 여부를 확인하는 matcher expression을 사용합니다. 자세한 내용은 Hamcrest의 Wiki를 참조하십시오.




Hamcrest has the target to make tests as readable as possible. For example, the is method is a thin wrapper for equalTo(value).


Hamcrest는 최대한 가독성있는 test scripts를 가지는 것을 목표로 하고 있습니다. 예를 들어, is 메소드는 equalTo(value)에 대한 thin wrapper입니다.


import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.is;
import static org.hamcrest.Matchers.equalTo;

boolean a;
boolean b;

// all statements test the same
assertThat(a, equalTo(b));
assertThat(a, is(equalTo(b)));
assertThat(a, is(b));


The following snippets compare pure JUnit 4 assert statements with Hamcrest matchers.


다음 snippets은 순수 JUnit 4 assert statements와 Hamcrest matchers를 비교합니다.


// JUnit 4 for equals check
assertEquals(expected, actual);
// Hamcrest for equals check
assertThat(actual, is(equalTo(expected)));

// JUnit 4 for not equals check
assertNotEquals(expected, actual)
// Hamcrest for not equals check
assertThat(actual, is(not(equalTo(expected))));

It is also possible to chain matchers, via the anyOf of allOf method.


allOf 메소드의 anyOf를 통해 matcher를 연결할 수도 있습니다.


assertThat("test", anyOf(is("testing"), containsString("est")));

In general the Hamcrest error messages are also much easier to read.


일반적으로 Hamcrest 오류 메시지는 읽기가 훨씬 쉽습니다.


assertTrue(result instanceof String);
// error message:
java.lang.AssertionError
    at org.junit.Assert.fail(Assert.java:86)
    at org.junit.Assert.assertTrue(Assert.java:41)
    at org.junit.Assert.assertTrue(Assert.java:52)
// ...


assertEquals(String.class, result.getClass());
// error message:
java.lang.NullPointerException
    at com.vogella.hamcrest.HamcrestTest.test(HamcrestTest.java:30)
// ....


assertThat(result, instanceOf(String.class));
// error message:
java.lang.AssertionError:
Expected: an instance of java.lang.String
     but: null
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
// ...


Using Hamcrest matchers also provides more type safety as these matchers use generics.


Hamcrest matchers를 사용하면 matcher가 generics를 사용하므로 더 많은 type safety을 제공합니다.





2. Using Hamcrest matchers


2.1. Defining a Hamcrest dependency for Gradle


To use Hamcrest matchers for a project based on the Gradle build system, add the following dependencies to it.

Gradle 빌드 시스템을 기반으로하는 프로젝트에 Hamcrest matchers를 사용하려면 다음 dependencies를 추가하십시오.


dependencies {
    // Unit testing dependencies
    testCompile 'junit:junit:4.12'
    // Set this dependency if you want to use Hamcrest matching
    testCompile 'org.hamcrest:hamcrest-library:1.3'
}


2.2. Defining a Hamcrest dependency for Maven


To use the library for a Maven based project, the following dependency to your pom file.


Maven 기반 프로젝트에 라이브러리를 사용하려면, pom 파일에 다음과 같은 dependencies를 부여하십시오.


<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-library</artifactId>
<version>1.3</version>
<scope>test</scope>
</dependency>



2.3. Adding Hamcrest directly to the classpath in Eclipse



The JUnit distribution included in Eclipse only contain the core Hamcrest matcher. To use all available matchers, download the latest hamcrest-all-*.jar from https://code.google.com/p/hamcrest/downloads/list and add it to your projects classpath.


Eclipse에 포함 된 JUnit 배포판에는 core Hamcrest matcher 만 포함됩니다. 사용 가능한 모든 matcher를 사용하려면 https://code.google.com/p/hamcrest/downloads/list에서 최신 hamcrest-all - * .jar 파일을 다운로드하여 프로젝트 classpath에 추가하십시오.


If you get the following exception "java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classes in the same package", ensure that the hamcrest jar is before the Junit library in the build path. You an configure the order in the project properties in the Eclipse IDE under Java Build Path on the Order and Export tab.


"java.lang.SecurityException : class"org.hamcrest.Matchers "의 서명자 정보가 같은 패키지의 다른 클래스의 서명자 정보와 일치하지 않는 경우"hamcrest jar가 Junit 라이브러리보다 앞에 있는지 확인하십시오. 빌드 경로. Eclipse IDE의 프로젝트 특성에서 순서 및 내보내기 탭의 Java 빌드 경로 아래에 순서를 구성하십시오.







3. Using Hamcrest


3.1. Example


The usage of Hamcrest matchers is demonstrates by the following code snippet.


Hamcrest matchers의 사용법은 다음 code snippet을 통해 보여줍니다.


assertThat(Long.valueOf(1), instanceOf(Integer.class));
// shortcut for instanceOf
assertThat(Long.valueOf(1), isA(Integer.class));


3.2. Static import


To make all matchers available in your file add an static import. This also makes it easier to find matchers through code completion.


파일에서 모든 matcher를 사용할 수 있게 하려면 static import를 추가하십시오. 이러면 code completion을 통해 matcher를 쉽게 찾을 수 있도록 해 주기도 합니다.


import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.*;



3.3. Hamcrest matchers for lists


The usage of the Hamcrest matchers for lists are demonstrated by the following example.


lists에 대한 Hamcrest matchers의 사용법은 다음 예제에서 보여 줍니다.


import org.junit.Test;

import java.util.Arrays;
import java.util.List;

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.contains;
import static org.hamcrest.Matchers.containsInAnyOrder;
import static org.hamcrest.Matchers.greaterThan;
import static org.hamcrest.collection.IsCollectionWithSize.hasSize;
import static org.hamcrest.core.Every.everyItem;

public class HamcrestListMatcherExamples {
    @Test
    public void listShouldInitiallyBeEmpty() {
        List<Integer> list = Arrays.asList(5, 2, 4);

        assertThat(list, hasSize(3));

        // ensure the order is correct
        assertThat(list, contains(5, 2, 4));

        assertThat(list, containsInAnyOrder(2, 4, 5));

        assertThat(list, everyItem(greaterThan(1)));

    }
}
// Check that a list of objects has a property race and
// that the value is not ORC
assertThat(fellowship, everyItem(hasProperty("race", is(not((ORC))))));



3.4. Overview of Hamcrest mather



The following are the most important Hamcrest matchers:


다음은 가장 중요한 Hamcrest matchers들 입니다.


  • allOf - matches if all matchers match (short circuits)

  • anyOf - matches if any matchers match (short circuits)

  • not - matches if the wrapped matcher doesn’t match and vice

  • equalTo - test object equality using the equals method

  • is - decorator for equalTo to improve readability

  • hasToString - test Object.toString

  • instanceOfisCompatibleType - test type

  • notNullValuenullValue - test for null

  • sameInstance - test object identity

  • hasEntryhasKeyhasValue - test a map contains an entry, key or value

  • hasItemhasItems - test a collection contains elements

  • hasItemInArray - test an array contains an element

  • closeTo - test floating point values are close to a given value

  • greaterThangreaterThanOrEqualTolessThanlessThanOrEqualTo

  • equalToIgnoringCase - test string equality ignoring case

  • equalToIgnoringWhiteSpace - test string equality ignoring differences in runs of whitespace

  • containsStringendsWithstartsWith - test string matching


To see all matchers, use API reference.


모든 matchers를 보려면 API 참조를 사용하십시오.


4. Exercise - Writing a custom Hamcrest matcher using FeatureMatcher


4.1. Target



The target of this exercise is to write a custom matcher with Hamcrest.


이 exercise의 목표는 Hamcrest 에서 custom matcher를 작성하는 것입니다.



4.2. Create Hamcrest Matchers


Define a custom matcher for Hamcrest which provides the length matcher for a String. We want to use the class FeatureMatcher. With FeatureMatcher we can wrap an existing Matcher, decide which field of the given Object under test to match and provide a nice error message. The constructor of FeatureMatcher takes the following arguments in this order:


Hamcrest를위한 custom matcher를 정의하여 String에 대한 length matcher를 제공합니다. 우리는 FeatureMatcher 클래스를 사용하고자합니다. FeatureMatcher를 사용하면 기존 Matcher를 wrap하고 테스트 할 대상 객체의 필드를 결정하여 나은 오류 메시지를 제공 할 수 있습니다. FeatureMatcher의 생성자는 다음 순서로 인수를 취합니다.



  • The matcher we want to wrap

  • a description of the feature that we tested

  • a description of the possible mismatch


The only method we have to overwrite is featureValueOf(T actual) which returns the value which will get passed into the wrapped matches()/matchesSafely() method.


overwrite하는 유일한 방법은 wrapped matches () / matchesSafely () 메서드에 전달 될 값을 반환하는 featureValueOf (T actual)입니다.


public static Matcher<String> length(Matcher<? super Integer> matcher) {
    return new FeatureMatcher<String, Integer>(matcher, "a String of length that", "length") {
        @Override
        protected Integer featureValueOf(String actual) {
            return actual.length();
        }
    };
}


4.3. Validate



Use your custom matcher to check that "Gandalf" has a lenght of 8.


Gandalf의 길이가 8인지에 대해 여러분의 custom matcher 를 사용해서 확인해 보세요.


@Test
public void fellowShipOfTheRingShouldContainer7() {
        assertThat("Gandalf", length(is(8)));
}
public static  Matcher<String> length(Matcher<? super Integer> matcher) {
        return new FeatureMatcher<String, Integer>(matcher, "a String of length that", "length") {
                @Override
                protected Integer featureValueOf(String actual) {
                  return actual.length();
                }
        };
}



5. Exercise: Writing your custom Hamcrest matcher using TypeSafeMatcher



It is possible to write your custom Hamcrest matcher by extending TypeSafeMatcher. In contrast to BaseMatcher the TypeSafeMatcher class automatically checks for null values, checks the type and casts appropriately before delegating to matchesSafely(). It provides type safety by default. The following is an example for defining a matcher which allows testing if a String matches a regular expression.


TypeSafeMatcher를 extends하여 custom Hamcrest matcher를 작성할 수 있습니다. BaseMatcher와 달리 TypeSafeMatcher 클래스는 자동으로 null 값을 확인하고, types를 검사하고 matchesSafely ()에 위임하기 전에 적절하게 형 변환합니다. 기본적으로 type safety 을 제공합니다. 다음은 문자열이 정규 표현식 regular expression 과 일치하는지 테스트 할 수있는 matcher를 정의하는 예제입니다.


import org.hamcrest.Description;
import org.hamcrest.TypeSafeMatcher;

public class RegexMatcher extends TypeSafeMatcher<String> {

        private final String regex;

        public RegexMatcher(final String regex) {
                this.regex = regex;
        }

        @Override
        public void describeTo(final Description description) {
                description.appendText("matches regular expression=`" + regex + "`");
        }

        @Override
        public boolean matchesSafely(final String string) {
                return string.matches(regex);
        }


         // matcher method you can call on this matcher class
    public static RegexMatcher matchesRegex(final String regex) {
        return new RegexMatcher(regex);
    }
}


The following snippet gives an example how to use it.


다음 snippet에는 이를 사용하는 예가 나와 있습니다.


package com.vogella.android.testing.applicationtest;


import org.junit.Test;

import static org.hamcrest.MatcherAssert.assertThat;

public class TestCustomMatcher {

    @Test
    public void testRegularExpressionMatcher() throws Exception {
        String s ="aaabbbaaaa";
        assertThat(s, RegexMatcher.matchesRegex("a*b*a*"));
    }

}


6. Exercise: Combining matchers


Combining matchers is supported by Hamcrest out of the box but it has the limitation that the error is hard to read:


matchers를 결합하는 것은 Hamcrest에 오류가 읽기 어렵다는 제한이 있습니다.

@Test
public void () {
    List<Integer> list = new ArrayList<>();
    assertThat(list, both(hasSize(1)).and(contains(42)));
}
Expected: (a collection with size <1> and iterable containing [<42>])
     but: a collection with size <1> collection size was <0>.


This not very readable.


이렇게 가독성이 떨어집니다.



6.1. Target



We want to write our own MatcherCombiner that provides us with a readable error message, even when multiple matchers fail.


우리는 multiple matchers가 fail하더라도 가독성있는 에러 메시지를 제공하는 MatcherCombiner를 별도로 작성하려고합니다.



6.2. Create MatchCombiner



We do this by inheriting from BaseMatch and by providing a starting method that let’s us chain matchers together. The matchers get saved in a list that we iterate over during the matching phase.


우리는 BaseMatch로부터 상속하고 chain matcher를 함께 묶어주는 것을 시작하면서 이 작업을 수행합니다. matchers는 matching phase 동안에 반복되는 list 저장됩니다.


public class MatcherCombinator<T> extends BaseMatcher<T> {
    private final List<Matcher<? super T>> matchers = new ArrayList<>();
    private final List<Matcher<? super T>> failedMatchers = new ArrayList<>();

    private MatcherCombinator(final Matcher<? super T> matcher) {
        matchers.add(matcher);
    }

    public MatcherCombinator<T> and(final Matcher<? super T> matcher) {
        matchers.add(matcher);
        return this;
    }

    @Override
    public boolean matches(final Object item) {
        boolean matchesAllMatchers = true;
        for (final Matcher<? super T> matcher : matchers) {
            if (!matcher.matches(item)) {
                failedMatchers.add(matcher);
                matchesAllMatchers = false;
            }
        }
        return matchesAllMatchers;
    }

    @Override
    public void describeTo(final Description description) {
        description.appendValueList("\n", " " + "and" + "\n", "", matchers);
    }

    @Override
    public void describeMismatch(final Object item, final Description description) {
        description.appendText("\n");
        for (Iterator<Matcher<? super T>> iterator = failedMatchers.iterator(); iterator.hasNext();) {
            final Matcher<? super T> matcher = iterator.next();
            description.appendText("Expected: <");
            description.appendDescriptionOf(matcher).appendText(" but ");
            matcher.describeMismatch(item, description);
            if (iterator.hasNext()) {
                description.appendText(">\n");
            }
        }
    }

    public static <LHS> MatcherCombinator<LHS> matches(final Matcher<? super LHS> matcher) {
        return new MatcherCombinator<LHS>(matcher);
    }
}


To validate the implementation we write a new test.


implementation을 validate하기 위해 새로운 테스트를 작성합니다.


@Test
public void test() {
    List<Integer> list = new ArrayList<>();
    assertThat(list, matches(hasSize(1)).and(contains(42)));
}
java.lang.AssertionError:
Expected:
<a collection with size <1>> and
<iterable containing [<42>]>
     but:
Expected: <a collection with size <1> but collection size was <0>>
Expected: <iterable containing [<42>] but No item matched: <42>.


You can adjust this output in the describeMismatch method.


describeMismatch method 에서 이 output을 adjust 할 수 있습니다.



7. Grouping your matchers for import



If you define many custom matchers it might become tedious to import them one by one into your test files. By grouping them into a single class you can import them with one statement. You can also group them together with Hamcrest matchers.


많은 custom matchers를 정의하면 테스트 파일에 하나씩 import하는 것이 불편 할 수 있습니다. single class로 그룹화하여 하나의 statement로 가져올 수 있습니다. Hamcrest matchers와 함께 그룹화 할 수도 있습니다.



package com.vogella.hamcrest;
import com.vogella.hamcrest.matchers.RegexMatcher;
import org.hamcrest.Matcher;
import org.hamcrest.Matchers;

public class MyMatchers
{
    public static <T> Matcher<T> instanceOf(Class<T> target) {
        return Matchers.instanceOf(target);
    }

   public static Matcher<String> matchesRegex(String target) {
          return RegexMatcher.matchesRegex(target);
   }
}


In your test file:

import static com.vogella.hamcrest.MyMatchers.*;


















이전 1 다음