블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 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  


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

저작자 표시 비영리 동일 조건 변경 허락
신고


Asynchronous Testing with Protractor’s ControlFlow


Protractor is an end-to-end testing framework for AngularJS applications that uses a real browser, just as a real user would. It is built on top of NodeJS and WebDriverJS and taps into the internals of Angular to know when Angular is done processing and updating bindings.



Protractor는 real user would와 마찬가지로 실제 브라우저를 사용하는 AngularJS 응용 프로그램의 end-to-end testing framework입니다. NodeJS 및 WebDriverJS 위에 구축되며 Angular의 내부를 tap해서 Angular가 바인딩 처리 및 업데이트를 완료 한 시점을 알 수 있습니다.


The joy of Protractorand WebDriverJS is that we can write our tests in a synchronous style, and still have the added benefits of asynchronous code. 


Protractor와 WebDriverJS의 강점은 동기식 스타일로 테스트를 작성할 수 있으며 비동기 코드의 부가적인 이점을 여전히 가지고 있다는 것입니다.

We are currently using Protractor for testing a Rails and Angular application that we’re developing here in the Detroit office. We were faced with a problem: “How do we write our own functions which are asynchronous but appear in the same synchronous style that Protractor tests are written in?” This is especially handy for performing REST requests for seeding data into the test database using something like the rails Hangar gem. 


우리는 현재 디트로이트 사무실에서 개발중인 Rails 및 Angular 응용 프로그램을 테스트하기 위해 Protractor를 사용하고 있습니다. "비동기식이지만 Protractor로 작성된 동기식으로 보이는 함수는 어떻게 작성합니까"  이것은 rails Hangar gem 같은 것을 사용해서 테스트 데이터베이스에 데이터를 넣기 위한 REST requests를 수행 할 때 특히 유용합니다. 


The ControlFlow


This required diving into the internals of how Protractor and WebDriverJS handle asynchrony. WebDriverJS uses an object called theControlFlow, which coordinates the scheduling and execution of commands operating on a queue. 


Any time an asynchronous command is invoked, it’s put in the queue where it will wait for all previous commands to complete prior to execution. The ControlFlow allows us to write code like this:


Protractor와 WebDriverJS가 어떻게 비동기를 처리하는지에 대해 좀 더 깊이 들어가겠습니다. WebDriverJS는 theControlFlow라는 객체를 사용합니다. 이 객체는 queue에서 작동하는 명령의 일정과 실행을 조정합니다.


비동기 명령이 호출 될 때마다 queue에 저장되어 실행 되기 전 모든 이전 명령들이 완료 될 때까지 대기합니다. ControlFlow를 사용하면 다음과 같은 코드를 작성할 수 있습니다.


driver.get(“http://www.google.com”);
driver.findElement(webdriver.By.name('q')).sendKeys('webdriver');
driver.findElement(webdriver.By.name('btnG')).click();
driver.getTitle().then(function(title) {
  console.log(title);
});


That really performs in a synchronous manner such as this:

이것은 아래와 같이 동기화 방식으로 처리 됩니다.


driver.get(“http://www.google.com”).
    then(function() {
      return driver.findElement(webdriver.By.name('q'));
    }).
    then(function(q) {
      return q.sendKeys('webdriver');
    }).
    then(function() {
      return driver.findElement(webdriver.By.name('btnG'));
    }).
    then(function(btnG) {
      return btnG.click();
    }).
    then(function() {
      return driver.getTitle();
    }).
    then(function(title) {
      console.log(title);
    });


Behind the scenes of WebDriver, each call that interacts with the browser, such as get()findElement()sendKeys(), and click(), is being scheduled and pushed onto the WebDriver ControlFlow, allowing us to not have to worry about using .then() on the resulting promises (unless we specifically want the result returned by the call). 

WebDriver의 이면에서 get (), findElement (), sendKeys () 및 click ()과 같이 브라우저와 상호 작용하는 각 호출이 예약되고 WebDriver ControlFlow에 푸시되므로 resulting promises 에 대해 걱정할 필요가 없습니다 (호출에 의해 반환 된 결과가 특별히 필요하지 않는 한)


Using the WebDriverJS Promises



The ControlFlow queues functions based on promises. The following code exhibits how to take a callback based function and wrap it into WebDriver’s Promise API. We will be using the Restler NodeJS library.


ControlFlow 대기열 기능은 promises를 기반으로합니다. 아래 코드는 callback 기반 함수를 WebDriver의 Promise API로 래핑하는 방법을 보여줍니다. 우리는 Restler NodeJS 라이브러리를 사용할 것입니다.

To create a WebDriver/Protractor deferred using their promise API:

promise API를 사용하여 지연된 WebDriver / Protractor를 만들려면 :


deferred = protractor.promise.defer()


Then fullfill or reject the promise based on Restler’s events and return the deferred promise:


restler.postJson(url, requestData, options).once('success', function() {
  return deferred.fulfill();
}).once('error', function() {
  return deferred.reject();
}).once('fail', function() {
  return deferred.reject();
});
 
deferred.promise;


Pushing the Promise Onto the ControlFlow



To solve our problem of invoking a synchronous REST request, we have to interact with WebDriver’s ControlFlow. 

To get the instance of the ControlFlow that is shared with protractor:


synchronous REST request를 invoking하는 문제를 해결하려면 WebDriver의 ControlFlow와 상호 작용해야합니다.

Protractor와 공유되는 ControlFlow의 인스턴스를 얻으려면 :


var flow = browser.controlFlow()


Then we can use the ControlFlow’s execute() function, assuming we created a based on the above code that wraps restler’s callbacks and returns a WebDriverJS promise:


그런 다음 Restler의 콜백을 래핑하고 WebDriverJS 약속을 반환하는 위 코드를 기반으로 ControlFlow의 execute () 함수를 사용할 수 있다고 가정합니다.


flow.execute(restFunction)


Chaining Promises and Getting Results



The good news is that ControlFlow’s execute() function returns a new promise that will be fulfilled when our original promise is executed by the scheduler. We can use use the all() function, which returns a new promise once all of the control flow’s promises are fulfilled:

좋은 소식은 ControlFlow의 execute () 함수가 새 promise를 반환한다는 겁니다. 이렇게 함으로서 원래 약속이 스케줄러에 의해 실행될 때 수행 될 이 조건이 충족되게 됩니다. 모든 control flow의 promises가 충족 됐을 때 new promise 가 반환되는 all () 함수를 사용할 수 있습니다.


var allPromise = protractor.promise.all(flow.execute(restFunction1), flow.execute(restFunction2))



When allPromise is fulfilled, it will return an array of the results of all the promises passed to all() as arguments. 

allPromise가 수행되면 all ()에 전달 된 모든 promises의 결과 배열을 인수로 반환합니다.


Ideally the implementation of your helper functions would abstract the intermediary promises that are being passed to the ControlFlow and purely operate based upon the promises returned from the ControlFlow’s execute function.

이상적으로 helper 함수의 구현은 ControlFlow로 전달되는 intermediary promises을 abstract화하고 ControlFlow의 실행 함수에서 반환 된 promises를 기반으로 작동합니다.


저작자 표시 비영리 동일 조건 변경 허락
신고







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



저작자 표시 비영리 동일 조건 변경 허락
신고



README.md


Protractor-Perf


Just like Protractor is the end to end test case runner for AngularJS to check for functional regressions, this project is a way check for performance regressions while reusing the same test cases.


Protractor가 기능적 회귀 (functional regressions) 를 검사하는 end to end test case runner 인 것처럼,  이 프로젝트는 동일한 테스트 케이스를 재사용하면서 performance regressions를 확인하는 방법입니다.




Usage


Install protractor-perf using npm install -g protractor-perf.


npm install -g protractor-perf를 사용해 protractor-perf 를 설치하세요.


Protractor test cases are re-used to run scenarios where performance needs to be measured. Protractor-perf can be used just like protractor, just that the test-cases need to be instrumented to indicated when to start and stop measuring performance.


Protractor 테스트 케이스는 performance을 측정해야하는 시나리오를 실행하기 위해 재사용됩니다. Protractor-perf는 Protractor처럼 사용할 수 있습니다. performance를 측정하기 위해 시작점과 끝나는 지점을 테스트 케이스 내에 정해주고 난 후 측정할 수 있습니다 


Protractor is usually invoked using $ protractor conf.js. Use $ protractor-perf conf.js instead to start measuring performance.


Protractor는 일반적으로 $ protractor conf.js.를 사용하여 호출됩니다. $ protractor-perf conf.js를 사용하여 성능 측정을 시작하십시오.



The config file is the same configuration file used for protractor tests.


config 파일은 Protractor 테스트에 사용되는 것과 동일한 구성 파일입니다.



Note: If you run selenium using protractor's webdriver-manager, you would need to specify seleniumPort and selenium keys in the config file, to explicitly specify the port on which the selenium server will run. This port will also be picked up by protractor-perf. See ./test/conf.js as an example.


참고 : Protractor의 webdriver-manager를 사용하여 selenium을 실행하는 경우 seleniumPort와 selenium keys를 config 파일에 명시합니다. 이렇게 함으로서 셀레니엄 서버가 돌아갈 포트를 특정할 수 있습니다.  ./test/conf.js 의 예를 참조하십시오.


When the instrumented test cases are run using protractor, the code related to performance is a no-op. This way, adding instrumentation does not break your ability to run protractor to just test for functionality.


퍼포먼스 테스팅이 구현 된 테스트 케이스가 Protractor를 사용하여 실행될 때 성능과 관련된 코드는 작동하지 않습니다. 이런 방법으로 이 기능을 추가해도 Protractor를 작동시켜 functionalityㄹ으 테스트하는 기능은 영향을 받지 않습니다.




Instrumenting the test cases

The test case need to specify when to start and stop measuring performance metrics for a certain scenario. The following code is an example of a test case, with perf code snippets added.


테스트 케이스에 특정 시나리오에 대한 performance metrics 측정을 시작하고 중지 할 시기를 지정합니다. 다음 코드는 perf 코드 snippets이 추가 된 테스트 사례의 예입니다.


var PerfRunner = require('..');
describe('angularjs homepage todo list', function() {
	var perfRunner = new PerfRunner(protractor, browser);

	it('should add a todo', function() {
		browser.get('http://www.angularjs.org');
		perfRunner.start();

		element(by.model('todoList.todoText')).sendKeys('write a protractor test');
		element(by.css('[value="add"]')).click();

		perfRunner.stop();

		if (perfRunner.isEnabled) {
			expect(perfRunner.getStats('meanFrameTime')).toBeLessThan(60);
		};

		var todoList = element.all(by.repeater('todo in todoList.todos'));
		expect(todoList.count()).toEqual(3);
		expect(todoList.get(2).getText()).toEqual('write a protractor test');

	});
});


The four statements to note are

메모 할 4 가지 문구는 다음과 같습니다.


  1. Initialize the Perf monitor using new ProtractorPerf(protractor, browser)
  2. To start measuring the perf, use perf.start()
  3. Once the scenario that you would like to perf test completes, use perf.stop()
  4. Finally, use perf.getStats('statName') in expect statements to ensure that all the performance metrics are within the acceptable range.

The perf.isEnabled is needed to ensure that perf metrics are not tested when the test case is run using protractor directly.


1. new ProtractorPerf (Protractor, browser)를 사용하여 Perf 모니터를 초기화하십시오.

2. perf를 측정하려면 perf.start ()를 사용하십시오.

3. perf 테스트를 수행하려는 시나리오가 완료되면 perf.stop () 를 사용하십시오.

4. 마지막으로 expect 문에서 perf.getStats ( 'statName')를 사용하여 모든 performance metrics이 허용되는 범위 내에 있는지 확인하십시오.


perf.isEnabled는 Protractor를 사용하여 테스트 케이스를 직접 실행할 때 perf metrics을 테스트하지 않도록하기 위해 필요합니다.



Metrics measured


protractor-perf is based on browser-perfbrowser-perf measures the metrics that can be tested for regressions. Look at browser-perf's wiki page for more information about the project.


protractor-perf는 browser-perf를 기반으로합니다. browser-perf는 regressions 테스트 할 수있는 metrics을 측정합니다. 프로젝트에 대한 자세한 내용은 browser-perf의 wiki 페이지를 참조하십시오.




Grunt Integration


Invoke protractor-perf from a GruntFile as below


아래와 같이 GruntFile 에서 protractor-perf를 Invoke 시키세요.


module.exports = function(grunt) {
  var protractorperf = require('protractor-perf');
  grunt.registerTask('protractorperf', function() {
    var donerun = this.async();
    // Optional config Object that overwrites properties of conf.js.
    // Useful to set property values from grunt.option()
    var argv = {
      selenium: 'http://localhost:54321/wd/hub',
      seleniumPort: 54321
    };
    protractorperf.run('./merci-perf-conf.js', donerun, argv); // config file
  });
  grunt.registerTask('run', ['protractorperf']);
};



저작자 표시 비영리 동일 조건 변경 허락
신고




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.*;


















저작자 표시 비영리 동일 조건 변경 허락
신고


Cucumber Introduction:


Cucumber is a tool based on Behavior Driven Development (BDD) framework which is used to write acceptance tests for web application. It allows automation of functional validation in easily readable and understandable format (like plain English) to Business Analysts, Developers, Testers, etc.


Cucumber는 BDD (Behavior Driven Development) 프레임 워크를 기반으로 웹 응용 프로그램에 대한 acceptance 테스트를 작성하는 데 사용되는 도구입니다. 비즈니스 분석가, 개발자, 테스터 등이 쉽게 읽을 수 있고 이해할 수있는 형식 (일반 영어와 같은)으로 기능 검증을 자동화 할 수 있습니다.


Cucumber feature files can serve as a good document for all. There are many other tools like JBehave which also support BDD framework. Initially Cucumber was implemented in Ruby and then extended to Java framework. Both the tools support native JUnit.


Cucumber feature 파일은 훌륭한 문서 역할을 할 수 있습니다. BDD 프레임 워크를 지원하는 툴 들 로는 JBehave 등과 같은 다른 많은 도구들도 있습니다. 처음에 Cucumber는 Ruby에서 구현되었고 Java 프레임 워크로 확장되었습니다. 두 도구 모두 native JUnit을 지원합니다.


Behavior Driven Development is extension of Test Driven Development and it is used to test the system rather than testing the particular piece of code. We will discuss more about the BDD and style of writing BDD tests.


Behavior Driven Development는 Test Driven Development의 확장이며 특정 코드를 테스트하는 대신 시스템을 테스트하는 데 사용됩니다. 아래에 BDD 및 BDD 테스트 작성 스타일에 대해 자세히 설명합니다.


Cucumber can be used along with Selenium, Watir, and Capybara etc. Cucumber supports many other languages like Perl, PHP, Python, .Net etc. In this tutorial we will concentrate on Cucumber with Java as a language.


Cucumber는 Selenium, Watir, Capybara 등과 함께 사용할 수 있습니다. Cucumber는 Perl, PHP, Python, .NET 등의 많은 다른 언어를 지원합니다.이 튜토리얼에서는 Java와 함께 Cucumber를 언어로 사용합니다.




Cucumber Basics:


In order to understand cucumber we need to know all the features of cucumber and its usage.


Cucumber를 이해하기 위해서는 Cucumber의 모든 특징과 사용법을 알아야합니다.


#1) Feature Files:


Feature files are essential part of cucumber which is used to write test automation steps or acceptance tests. This can be used as live document. The steps are the application specification. All the feature files ends with .feature extension.


Feature file은 테스트 자동화 단계 또는 acceptance 테스트를 작성하는 데 사용되는 Cucumber의 핵심 부분입니다. 이것은 live document로 사용할 수 있습니다. steps는 application specification입니다. 모든 Feature file은 .feature 확장자로 끝납니다.



Sample feature file:

Feature: Login Functionality Feature

In order to ensure Login Functionality works,
I want to run the cucumber test to verify it is working

Scenario: Login Functionality

Given user navigates to SOFTWARETETINGHELP.COM
When user logs in using Username as “USER” and Password “PASSWORD”
Then login should be successful

Scenario: Login Functionality

Given user navigates to SOFTWARETETINGHELP.COM
When user logs in using Username as “USER1” and Password “PASSWORD1”
Then error message should be thrown


#2) Feature:


This gives information about the high level business functionality (Refer to previous example) and the purpose of Application under test. Everybody should be able to understand the intent of feature file by reading the first Feature step. This part is basically kept brief.


여기에는 대략적인 개념의 business functionality (이전 예 참조) 및 테스트중 인 응용 프로그램의 목적에 대한 정보가 있습니다. 첫 번째 Feature step을 읽으면 누구나 이 Feature file의 의도를 이해할 수 있어야 합니다. 이 부분은 기본적으로 간략하게 작성합니다.


#3) Scenario:

Basically a scenario represents a particular functionality which is under test. By seeing the scenario user should be able to understand the intent behind the scenario and what the test is all about. Each scenario should follow given, when and then format. This language is called as “gherkin”.


기본적으로 시나리오는 테스트중인 특정 기능을 나타냅니다. 시나리오 사용자는 시나리오의 의도와 그 테스트가 무엇인지 이해할 수 있어야합니다. 각 시나리오는 주어진 시간과 형식을 따라야합니다. 이 언어는 "작은 Cucumber (gherkin)"라고 불립니다.


  1. Given: As mentioned above, given specifies the pre-conditions. It is basically a known state.
  2. When: This is used when some action is to be performed. As in above example we have seen when the user tries to log in using username and password, it becomes an action.
  3. Then: The expected outcome or result should be placed here. For Instance: verify the login is successful, successful page navigation.
  4. Background: Whenever any step is required to perform in each scenario then those steps needs to be placed in Background. For Instance: If user needs to clear database before each scenario then those steps can be put in background.
  5. And: And is used to combine two or more same type of action.

Example:

Feature: Login Functionality Feature

Scenario: Login Functionality
Given user navigates to SOFTWARETETINGHELP.COM
When user logs in using Username as “USER”
And password as “password”
Then login should be successful
And Home page should be displayed

Example of Background:

Background:

Given user logged in as databases administrator
And all the junk values are cleared


#4) Scenario Outline:

Scenario outlines are used when same test has to be performed with different data set. Let’s take the same example. We have to test login functionality with multiple different set of username and password.

시나리오 개요는 동일한 테스트가 여러 다른 data set로 수행되어야 할 때 사용됩니다. 같은 예를 들어 봅시다. 여러 다른 사용자 이름 및 비밀번호 세트로 로그인 기능을 테스트해야합니다.


Feature: Login Functionality Feature

In order to ensure Login Functionality works,
I want to run the cucumber test to verify it is working

Scenario Outline: Login Functionality

Given user navigates to SOFTWARETESTINGHELP.COM
When user logs in using Username as <username> and Password <password>
Then login should be successful

Examples:
|username         |password          |
|Tom                     |password1        |
|Harry                   |password2        |
|Jerry                    |password3        |

Note:

  1. As shown in above example column names are passed as parameter to When statement.
  2. In place of Scenario, you have to use Scenario Outline.
  3. Examples are used to pass different arguments in tabular format. Vertical pipes are used to separate two different columns. Example can contain many different columns.

     
    위의 예에서와 같이 열 이름은 매개 변수로 When 문에 전달됩니다.
    Scenario 대신 Scenario Outline을 사용해야합니다.
    이 예제는 다른 인수를 표 형식으로 전달하는 데 사용됩니다. Vertical pipes는 두 개의 서로 다른 columns을 분리하는 데 사용됩니다. 이 예제에 많은 다른 열을 포함 할  수 있습니다.




#5) Tags:

Cucumber by default runs all scenarios in all the feature files. In real time projects there could be hundreds of feature file which are not required to run at all times.


기본적으로 Cucumber는 모든 Feature file에서 모든 시나리오를 실행합니다. 실시간 프로젝트에는 항상 실행될 필요가 없는 수백 개의 Feature file이있을 수 있습니다.


For instance: Feature files related to smoke test need not run all the time. So if you mention a tag as smokeTest in each feature file which is related to smoke test and run cucumber test with @SmokeTest tag . Cucumber will run only those feature files specific to given tags. Please follow the below example. You can specify multiple tags in one feature file.


예 : smoke test와 관련된 Feature file은 항상 실행될 필요는 없습니다. 따라서 smoke test와 관련된 각 Feature file에서 smokeTest로 태그를 언급하고 @SmokeTest 태그로 Cucumber 테스트를 실행하면됩니다. Cucumber는 특정 태그에 해당하는 Feature file 만 실행합니다. 아래의 예를 따르십시오. 하나의 Feature file에 여러 개의 태그를 지정할 수 있습니다.


Example of use of single tags:


@SmokeTest

Feature: Login Functionality Feature

In order to ensure Login Functionality works,
I want to run the cucumber test to verify it is working

Scenario Outline: Login Functionality

Given user navigates to SOFTWARETESTINGHELP.COM
When user logs in using Username as <username> and Password <password>
Then login should be successful

Examples:
|username         |password          |
|Tom     |password1        |
|Harry   |password2        |
|Jerry    |password3        |

Example of use of multiple tags:


As shown in below example same feature file can be used for smoke test scenarios as well as for login test scenario. When you intend to run your script for smoke test then use @SmokeTest. Similarly when you want your script to run for Login test use @LoginTest tag.

아래 예제에서와 같이 로그인 테스트 시나리오는 물론 Smoke Test 시나리오에도 동일한 Feature file을 사용할 수 있습니다. Smoke Test를 위해 스크립트를 실행하려면 @SmokeTest를 사용하십시오. 마찬가지로 로그인 테스트를 위해 스크립트를 실행하려면 @LoginTest 태그를 사용하십시오.


Any number of tags can be mentioned for a feature file as well as for scenario.


Feature file뿐만 아니라 시나리오에 대해서도 임의의 수의 태그를 사용 할 수 있습니다.


@SmokeTest @LoginTest


Feature: Login Functionality Feature

In order to ensure Login Functionality works,
I want to run the cucumber test to verify it is working

Scenario Outline: Login Functionality

Given user navigates to SOFTWARETETINGHELP.COM
When user logs in using Username as <username> and Password <password>
Then login should be successful

Examples:
|username         |password          |
|Tom     |password1        |
|Harry   |password2        |
|Jerry    |password3        |


Similarly you can specify tags to run specific scenario in a feature file. Please check below example to run specific scenario.


마찬가지로 태그를 지정하여 Feature file에서 특정 시나리오를 실행할 수 있습니다. 특정 시나리오를 실행하려면 아래 예제를 확인하십시오.


Feature: Login Functionality Feature

In order to ensure Login Functionality works,
I want to run the cucumber test to verify it is working

@positiveScenario
Scenario: Login Functionality

Given user navigates to SOFTWARETETINGHELP.COM
When user logs in using Username as “USER” and Password “PASSWORD”
Then login should be successful

@negaviveScenario
Scenario: Login Functionality

Given user navigates to SOFTWARETETINGHELP.COM
When user logs in using Username as “USER1” and Password “PASSWORD1”
Then error message should throw



#6) Junit Runner:


To run the specific feature file cucumber uses standard Junit Runner and specify tags in @Cucumber. Options. Multiple tags can be given by using comma separate. Here you can specify the path of the report and type of report you want to generate.


특정 Feature file을 실행하려면 cucumber가 표준 Junit Runner를 사용하고 @Cucumber에 태그를 지정하십시오. 옵션. 쉼표로 구분하여 여러 태그를 지정할 수 있습니다. 여기에서 생성하려는 보고서의 경로와 유형을 지정할 수 있습니다.


Example of Junit Runner:

1import cucumber.api.junit.Cucumber;</pre>
2import org.junit.runner.RunWith;
3@RunWith(Cucumber.class)
4@Cucumber.Options(format={"SimpleHtmlReport:report/smokeTest.html"},tags={"@smokeTest"})
5Public class JUnitRunner {
6}


Similarly you can give instruction to cucumber to run multiple tags. Below example illustrates how to use multiple tags in cucumber to run different scenarios.


마찬가지로 여러 개의 태그를 실행하기 위해 Cucumber에게 지시를 내릴 수 있습니다. 아래 예제는 Cucumber에서 여러 개의 태그를 사용하여 다른 시나리오를 실행하는 방법을 보여줍니다.


1import cucumber.api.junit.Cucumber;
2 import org.junit.runner.RunWith;
3 @RunWith(Cucumber.class)
4 @Cucumber.Options(format={"SimpleHtmlReport:report/smokeTest.html"},tags={"@smokeTest",”@LoginTest”})
5 Public class JUnitRunner {
6}



#7) Cucumber Report:


Cucumber generates its own html format. However better reporting can be done using Jenkins or bamboo tool. Details of reporting are covered in next topic of cucumber.


Cucumber는 자체적으로 HTML 형식을 생성합니다. Jenkins 또는 bamboo 도구를 사용하여 더 나은 보고를 수행 할 수 있습니다. 보고의 세부 사항은 Cucumber의 다음 주제에서 다룹니다.


Cucumber Project Setup:


Detail explanation of cucumber project set up is available separately in next tutorial. Please refer to Cucumber Tutorial Part2 from more information about project setup. Remember there is no extra software installations required for cucumber.


Cucumber 프로젝트 설정에 대한 자세한 설명은 다음 자습서에서 별도로 설명됩니다. 프로젝트 설정에 대한 자세한 내용은 Cucumber Tutorial Part2를 참조하십시오. Cucumber에 필요한 추가 소프트웨어 설치가 없음을 기억하십시오.


Implementation of Feature file:

We have to implement these steps in Java in order to test the feature files. Need to create a class which contains those given, when and then statements. Cucumber uses its annotations and all the steps are embedded in those annotations (given, when, then).Each phrase starts with “^” so that cucumber understands the start of the step. Similarly each step ends with “$”. User can use regular expressions to pass different test data. Regular expressions take data from feature steps and passes to step definitions. The order of parameters depends how they are passed from feature file. Please refer next tutorial for project setup and mapping between feature files and java classes.


Feature file을 테스트하려면 Java에서 이러한 steps를 구현해야합니다. 주어진, when 및 then 문을 포함하는 클래스를 작성해야합니다. Cucumber는 annotations을 사용하고 모든 step들은 annotations에 포함되어 있습니다 (given, when, then). 각 phrase는 "^"로 시작하여 Cucumber가 단계의 시작을 이해할 수 있도록합니다. 마찬가지로 각 단계는 "$"로 끝납니다. 사용자는 regular expressions을 사용하여 다른 테스트 데이터를 전달할 수 있습니다. 정규식 regular expressions은 feature steps에서 데이터를 가져 와서 step definitions로 전달합니다. 매개 변수 parameters 순서는 feature file에서 전달되는 방법에 따라 다릅니다. 피쳐 파일과 자바 클래스 간의 프로젝트 설정과 매핑에 대해서는 다음 튜토리얼을 참조하십시오.


Example:


Below example is to illustrate how feature files can be implemented.


아래 예제는 Feature file을 구현하는 방법을 보여줍니다.


In this example we have not used any selenium API. This is to just show how cucumber works as standalone framework. Please follow next tutorial for selenium integration with cucumber.


이 예제에서는 selenium API를 사용하지 않았습니다. Cucumber가 독립 프레임 워크로 어떻게 작동하는지 보여주기위한 것입니다. selenium과 Cucumber의 통합에 대한 내용은 next tutorial을 참조하세요.


1public class LoginTest {
2@Given("^user navigates to SOFTWARETETINGHELP.COM$")
3public void navigatePage() {
4system.out.println(“Cucumber executed Given statement”);
5}
6@When("^user logs in using Username as \"(.*)\" and Password \"(.*)\"$")
7public void login(String usename,String password) {
8system.out.println(“Username is:”+ usename);
9system.out.println(“Password is:”+ password);
10}
11@When("^click the Submit button$")
12public void clickTheSubmitButton() {
13system.out.println(“Executing When statement”)
14}
15@Then("^Home page should be displayed$")
16public void validatePage() {
17system.out.println(“Executing Then statement”)
18}
19@Then("^login should be successful$")
20public void validateLoginSuccess() {
21system.out.println(“Executing 2<sup>nd</sup> Then statement”)
22}
23}


When you execute cucumber runner class, cucumber will start reading feature file steps. For example, when you execute @smokeTest, cucumber will read Feature step and Given statement of scenario. As soon as cucumber finds Given statement, same Given statement will be searched in your java files. If same step is found in java file then cucumber executes the function specified for the same step otherwise cucumber will skip the step.


Cucumber runner class를 실행하면 Cucumber가 feature file steps를 읽습니다. 예를 들어 @smokeTest를 실행하면 cucumber는 Feature step과 Given of scenario 문을 읽습니다. Cucumber가 Given 문을 찾자마자 java 파일에서 동일한 Given 문이 검색됩니다. java 파일에서 동일한 단계가 발견되면 cucumber는 동일한 단계에 대해 지정된 함수를 실행하고 그렇지 않은 경우 그 step을 건너 뜁니다.


Conclusion:


In this tutorial, we have covered features of cucumber tool and its usage in real time scenario.
Cucumber is a most favorite tool for many projects as it is easy to understand, readable and contains business functionality.


이 튜토리얼에서는 Cucumber 도구의 기능과 그 사용법을 real time scenario 로 다루었습니다.


Cucumber는 이해하기 쉽고 읽기 쉽고 비즈니스 기능을 포함하고있어 많은 프로젝트에서 가장 많이 사용되는 도구입니다.


In the next chapter we will cover how to setup a cucumber – java project and how to integrate Selenium WebDriver with Cucumber.


다음 장에서는 Cucumber 자바 프로젝트를 설정하는 방법과 Selenium WebDriver를 Cucumber와 통합하는 방법에 대해 설명합니다.


저작자 표시 비영리 동일 조건 변경 허락
신고


Javascript sort()



var arr = ["Banana", "Orange", "Apple", "Mango", "apple", "1apple"];

arr.sort();

["1apple", "Apple", "Banana", "Mango", "Orange", "apple"]


It is case sensitive.


To make it case insensitive


var arr = ["Banana", "Orange", "Apple", "Mango", "apple", "1apple"];

arr.sort(function(a,b) {

    a = a.toLowerCase();

    b = b.toLowerCase();

    if( a == b) return 0;

    return a < b ? -1 : 1;

});

["1apple", "Apple", "apple", "Banana", "Mango", "Orange"]


or


var arr = ["Banana", "Orange", "Apple", "Mango", "apple", "1apple"];

arr.sort(

    function(a, b){

        if (a.toLowerCase() < b.toLowerCase()) return -1;

        if (a.toLowerCase() > b.toLowerCase()) return 1;

        return 0;

    }

); 

["1apple", "Apple", "apple", "Banana", "Mango", "Orange"]



Protractor


Check not exist


expect(element(by.css('.switch')).isPresent()).to.become(false).and.notify(next);

expect(items.length).toBe(0);




element.all(locator).map(mapFunction)


<ul class="items">
  <li class="one">First</li>
  <li class="two">Second</li>
  <li class="three">Third</li>
</ul>
let items = element.all(by.css('.items li')).map(function(elm, index) {
  return {
    index: index,
    text: elm.getText(),
    class: elm.getAttribute('class')
  };
});
expect(items).toEqual([
  {index: 0, text: 'First', class: 'one'},
  {index: 1, text: 'Second', class: 'two'},
  {index: 2, text: 'Third', class: 'three'}
]);

// Or using the shortcut $$() notation instead of element.all(by.css()):

let items = $$('.items li').map(function(elm, index) {
  return {
    index: index,
    text: elm.getText(),
    class: elm.getAttribute('class')
  };
});
expect(items).toEqual([
  {index: 0, text: 'First', class: 'one'},
  {index: 1, text: 'Second', class: 'two'},
  {index: 2, text: 'Third', class: 'three'}
]);


Example


step.Then(/^Verify Search Result search by "([^"]*)"$/, 
(searchName:string, done:Callback)=>{
    let cName = customerViewPage.customerNameList();

cName.map(function(eachName){
return eachName.getText().then(function(cNameList){
return cNameList;
});
}).then(function(cNameList){
for(let i = 0; i < cNameList.length; i++){
console.log(cNameList[i] + ' contains ' + searchName);
expect(cNameList[i]).is.contains(searchName);
}
done();
});
});


element.all(locator).each(eachFunction)

<ul class="items">
  <li>First</li>
  <li>Second</li>
  <li>Third</li>
</ul>
element.all(by.css('.items li')).each(function(element, index) {
  // Will print 0 First, 1 Second, 2 Third.
  element.getText().then(function (text) {
    console.log(index, text);
  });
});

// Or using the shortcut $$() notation instead of element.all(by.css()):

$$('.items li').each(function(element, index) {
  // Will print 0 First, 1 Second, 2 Third.
  element.getText().then(function (text) {
    console.log(index, text);
  });
});


Example


step.Then(/^Check sorting$/, (done: Callback)=> {
let sorted = [] , unSorted = [];
let cName = customerViewPage.customerNameList();
let i = 0;
cName.each(function(eachName){
eachName.getText().then(function(name){
// unSorted[i] = name.toLowerCase();
unSorted[i] = name;
i++;
});
}).then(function(){
sorted = unSorted.slice();
// sorted.sort();
sorted.sort(function(a, b) {
a = a.toLowerCase();
b = b.toLowerCase();
if ( a === b) {return 0;}
return a < b ? -1 : 1;
});

for(let i = 0; i < sorted.length; i++){
console.log(' Array1 : ' + sorted[i] +

' is equals to Array2 : ' + unSorted[i]);
expect(sorted[i]).is.equal(unSorted[i]);
}
done();
});
});


element.all(locator).then(thenFunction)


ElementArrayFinder.prototype.then


Retrieve the elements represented by the ElementArrayFinder. The input function is passed to the resulting promise, which resolves to an array of ElementFinders.


<ul class="items">
  <li>First</li>
  <li>Second</li>
  <li>Third</li>
</ul>


element.all(by.css('.items li')).then(function(arr) {
  expect(arr.length).toEqual(3);
});

// Or using the shortcut $$() notation instead of element.all(by.css()):

$$('.items li').then(function(arr) {
  expect(arr.length).toEqual(3);
});


저작자 표시 비영리 동일 조건 변경 허락
신고



Leaving a memo

customerNameList() {return element.all(by.css("#items")).

all(by.css(".list-item-title"));}

This customerNameList() fetches customer name list data.

step.Then(/^Check sorting$/, (done: Callback)=> {
let sorted = [] , unSorted = [];
let cName = customerViewPage.customerNameList();

cName.map(function(eachName){
return eachName.getText().then(function(unSorted){
return unSorted;
});
}).then(function(unSorted){
let sorted = unSorted.slice();
sorted = sorted.sort(); //sort the array
for(let i = 0; i < sorted.length; i++){
console.log(' Array1 : ' + sorted[i] +

' is equals to Array2 : ' + unSorted[i]);
expect(sorted[i]).is.equal(unSorted[i]);
}
done();
});
});

Check sorting results.

unSorted[] array will have current customer name list.

sorted[] array is sorting the current customer name list.


compare sorted[] and unSorted[]

if pass then the customer list is sorted properly.


step.Then(/^Check sorting$/, (done: Callback)=> {
let sorted = [] , unSorted = [];
let cName = customerViewPage.customerNameList();
let i = 0;
cName.each(function(eachName){
eachName.getText().then(function(name){
// unSorted[i] = name.toLowerCase();
unSorted[i] = name;
i++;
});
}).then(function(){
sorted = unSorted.slice();
sorted.sort();
for(let i = 0; i < sorted.length; i++){
console.log(' Array1 : ' + sorted[i] +

' is equals to Array2 : ' + unSorted[i]);
expect(sorted[i]).is.equal(unSorted[i]);
}
done();
});
});


This step has the same functionality as above.




let statelist:any;
 let sortedStatelist:any;
 addCustomerPage.state().click().then(()=>{
   addCustomerPage.stateDropDownOptions().then(function (actualListOfStates) {
     statelist=actualListOfStates.slice();
     sortedStatelist=statelist.sort();
     // expect(statelist).to.contains(sortedStatelist);
     for(let i=0;i<sortedStatelist.length;i++){
       expect(statelist[i]).is.equal(sortedStatelist[i]);
     }
     done();
   })
 })


Fetch items from dropdown menu and check sorting status.



JavaScript Array slice() Method


var fruits = ["Banana", "Orange", "Lemon", "Apple", "Mango"];
var citrus = fruits.slice(1, 3);


Orange,Lemon



Definition and Usage

The slice() method returns the selected elements in an array, as a new array object.

The slice() method selects the elements starting at the given start argument, and ends at, but does not include, the given end argument.

Note: The original array will not be changed.



저작자 표시 비영리 동일 조건 변경 허락
신고


Protractor For Beginners Part 1

When I started writing automated tests in Protractor, I had never programmed anything before (unless you count learning enough html/css on codecademy to create an incredibly basic, 90’s style webpage). Some of the problems I encountered whilst learning Protractor were very hard to find on Google, which did make my learning a lot slower than I would have liked. Luckily I work with amazing people who are more than happy to share their knowledge which has saved me countless times, but unfortunately there are many people out there who do not have access to such resources. So, I have decided to create a tutorial which documents as many issues as possible that I encountered whilst learning.


Protractor로 automated tests를 쓰기 시작했을 때, 나는 전혀 프로그래밍 경험이 없었다. (codecademy에서 html / css를 충분히 배우지 않아서 90년대 스타일의 아주 기초적인 html 지식만 있는 상태였다). Protractor를 배우는 동안 내가 접했던 여러 어려운 점들은 Google에서 해결책을 찾기가 어려웠다. 그래서 나의 배움은 내가 바라는 것보다 훨씬 더뎠다. 다행히도 나는 자신들의 지식을 공유하는 것을 행복하게 생각하는 많은 사람들의 도움으로 많은 정보를 얻을 수 있었다. 하지만 불행히도 그런 자료들에 접근하지 못하는 사람들도 많이 있다. 그래서, 나는 학습하면서 가능한 많은 것들을 문서화 한 tutorial을 작성하기로 결심했다.


This tutorial will be broken down into bite sized chunks, with each new blog post as a new task, and it is aimed at people with little to no experience of programming. You will be writing the tests for the AngularJs site itself, since this is a good site for practising writing Protractor tests for as it is written in AngularJs; the JavaScript framework that Protractor runs tests against.


이 튜토리얼은 각 단위별로 구분될 것이다. 그래서 각각의 새로운 블로그는 새로운 task가 될 것이다. 그럼으로서 프로그래밍에 거의 경험이 없는 사람들을 대상으로 살 것이다.  여러분들은 AngularJs 를 사용해 대한 테스트를 할 것이다. 왜냐하면 이것은 AngularJs로 작성되었기 때문에 테스트 작성을 연습하기에 아주 안성맞춤이기 때문이다. 


Note: if you get stuck at any point, the entire code can be found in https://github.com/hannimator/angularjs.org_protractor for use as reference. Snippets of the code will be shown as examples throughout.


참고 : 문제가 발생하면 https://github.com/hannimator/angularjs.org_protractor에서 전체 코드를 참조 할 수 있다. 코드의 Snippets에는 예제들이 있다.





Introduction:


To begin with, follow this tutorial https://github.com/angular/protractor/blob/master/docs/tutorial.md. It will run through how to setup Protractor and Jasmine, and the basics of running some simple tests. Another good read, but not necessary for this tutorial is https://github.com/angular/protractor/blob/master/docs/toc.md, which has some more in depth information about Protractor and Jasmine. Once you have completed the above tutorials, follow the steps below.


처음 시작할 때는 https://github.com/angular/protractor/blob/master/docs/tutorial.md)를 참조하세요. Protractor와 재스민을 설치하는 방법과 몇 가지 간단한 테스트를 실행하는 기본 사항을 설명합니다. 다른 유용한 정보들은 https://github.com/angular/protractor/blob/master/docs/toc.md 를 참조하세요.  프로트랙터와 자스민에 대해 좀 더 깊은 내용을 접할 수 있습니다. 이 튜토리얼들을 살펴보시고 난 후 아래 스텝들을 따라해 보세요.


Page Objects, Developer Tools and the DOM


Page objects model the UI objects that your test interacts with inside your tests code. Using page objects keeps the tests easier to maintain (since if anything changes, you only have to change the page objects rather than change every single test). To find these UI objects, open up the browser developer tools by pressing f12 and select the 'elements' tab, or find the element (e.g. a button), right click and select 'Inspect element' from the dropdown list. For this example, use the AngularJs site. Right click on the 'View on Github' button and select 'Inspect element'. Observe the line

   &lt;a class="btn btn-large" href="https://github.com/angular/angular.js"&gt;
      &lt;i class="icon-github-sign"&gt;&lt;/i&gt;
         "View on GitHub"
   &lt;/a&gt;
Is highlighted.

Page objects model의 UI objects는 여러분이 작성한 테스트 코드 내부와 상호작용하게 됩니다. 페이지 객체를 사용하면 테스트들을 더 쉽게 관리 할 수 있습니다 (변경 사항이 있으면 모든 단일 테스트를 변경하는 대신 페이지 객체 만 변경하면됩니다). 이러한 UI 개체를 찾으려면 f12 키를 눌러 browser developer tools을 열고  'elements' tab을 선택합니다. 혹은 element (예 : 버튼)를 찾아 마우스 오른쪽 버튼으로 클릭 한 다음 드롭 다운 목록에서 'Inspect element'를 선택합니다제. 이 예에서는 AngularJs 사이트를 사용합니다. 'View on Github' button을 마우스 오른쪽 버튼으로 클릭하고 'Inspect element'를 선택하십시오. 선이 강조 표시되어 있는지 확인하십시오.

For this element (or page object) you can see the classname is “btn btn-large”, so when you write the page object, write it like this:

이 element (또는 page object체)의 경우 클래스 이름이 "btn btn-large"라는 것을 알 수 있으므로 page object를 작성할 때 다음과 같이 작성하십시오.

       
    var pageObjectName = element(by.css(“.btn.btn-large”));
       

The reason it is written as ".btn.btn-large" rather than "btn btn-large" is down to locators, which are what tell Protractor where to find certain elements. A CSS selector would look like this: ".someCSS", whereas an ID selector would look like this: "#someID". Some more information on this can be found in the Protractor documentation

"btn btn-large"가 아닌 ".btn.btn-large"라고 쓰여진 이유는 Locator에 있습입니다. 이것은 Protractor에게 특정 elements를 어디에서 찾을지 알려주는 것입니다. CSS selector는 다음과 같이 보일 것입니다 : ".someCSS" 반면 IDselector는 "#someID"와 같이 보일 겁니다. 이것에 관한 더 많은 정보는 Protractor documentation 에서 찾을 수 있습니다.

If you want to learn a little bit more about the DOM which is mentioned throughout this tutorial, I have found https://css-tricks.com/dom/ to be a very useful and concise explanation.


이 튜토리얼에서 언급 된 DOM에 대해 조금 더 배우고 싶다면 https://css-tricks.com/dom/ 를 참조하세요. 매우 유용하고 간결한 설명이 있습니다.


Disabling Suites and Specs


To disable and enable suites and specs, simply place an x in front of the describe or the it (depending which level you want to disable the tests at, placing an x in front of the describe will disable all tests within that describe) so that it looks like this: xdescribe or xit.


suites와 specs을 disable 하게 하려면 단순히 설명 앞에 x를 표시하세요. (테스트를 사용 disable하게 할 레벨에 따라 설명 앞에 x를 붙이면 해당 설명 내의 모든 테스트가 사용 불가능하게됩니다). 다음과 같이 하시면 됩니다. : xdescribe 또는 xit.



Getting Started: Home Page


Open up https://angularjs.org/. Create a new folder where you want to keep your project. Open up your preferred text editor (I personally use Brackets), and open up the folder that you have just created. Create a new .js file called 'HomePageSpec.js' and create a config file called 'protractorConf.js'. Paste in this code in to the 'protractorConf.js' file:


https://angularjs.org/를 엽니다. 프로젝트를 keep 할 새 폴더를 만듭니다. 원하는 텍스트 편집기를 열고 방금 생성 한 폴더를 엽니다. 'HomePageSpec.js'라는 새 .js 파일을 만들고 'protractorConf.js'라는 config 파일을 만듭니다. 이 코드를 'protractorConf.js'파일에 붙여 넣습니다.


       
   exports.config = {
      seleniumAddress: 'http://localhost:4444/wd/hub',
      specs: ['HomePageObjectSpec.js'],
      onPrepare: function () {	
         browser.driver.manage().window().setSize(1680, 1050);
      },
   }
       


Task 1.1: Describe “angularjs.org should have three Center Stage buttons”


What will you learn from this task?

  • How to set up a describe suite and it spec.
  • How to create page objects.
  • How to check that something is displayed on the screen or present in the DOM using isDisplayed

여기에서 무엇을 배울 것입니까?

     describe suite와 spec을 설정하는 방법.
     페이지 객체를 만드는 방법.
     isDisplayed를 사용하여 화면에 표시되거나 DOM에 표시되는지 확인하는 방법 


In this task you will test that elements are present and visible on the page using the three center stage buttons on the home page of AngularJs.org and the Jasmine matcher .isDisplayed (read more about Jasmine matchers here. isDisplayed checks to see if the element is actually present on the page: if the element is not in the DOM whilst using isDisplayed, it will throw an exception error. See how to use isDisplayed below.


이 task에서는 AngularJs.org와 Jasmine matcher .isDisplayed의 홈 페이지에있는 3 개의 중앙 스테이지 버튼을 이용해서 해당 엘리먼트들이 페이지에 존재하고 볼수 있는지에 대해 테스트 할 것입니다.  (여기에서 Jasmine matchers에 대해 자세히 알아보십시오.) .isDisplayed는 엘리먼트가 실제로 페이지에 존재하고 보이는지를 체크합니다. : isDisplayed를 사용하는 동안 요소가 DOM에 없으면 exception error가 발생합니다. 아래의 isDisplayed 사용 방법을 참조하십시오.


  1. Open up angularjs.org
  2. Right click on the “View on GitHub” button, and select ‘Inspect element’ to bring up the html in the developer console.
  3. Find the code that relates to the “View on GitHub” button (if you hover over
       
                &lt;a class="btn btn-large" href="https://github.com/angular/angular.js"&gt;
            
    you will be able to see the button highlight).

         1. angularjs.org를 엽니 다.
         2. "View on GitHub"버튼을 마우스 오른쪽 버튼으로 클릭하고 'Inspect element'를 선택하여 개발자 콘솔에서 html을 가져옵니다.
         3. "View on GitHub"버튼과 관련된 코드를 찾습니다 (마우스를 올려 놓으면 버튼 강조 표시를 볼 수 있습니다).

  4. If you navigate up through the divs, you will be able to find the html code that contains all three elements. The class for this is center stage-buttons.
  5. In your text editor, open up your “HomePageSpec.js” file, and create a variable called HomePage like this:

        4. div를 통해 위로 이동하면 세 요소를 모두 포함하는 html 코드를 찾을 수 있습니다. 이를 위한 클래스는 중앙 스테이지 버튼입니다.
        5. 텍스트 편집기에서 "HomePageSpec.js"파일을 열고 다음과 같이 HomePage라는 변수를 만듭니다.

           
       var HomePage = function() {
     
       };
           
    This HomePage variable contains page objects, which are the elements on the page. Different page objects will be used for different sections that are tested on.

        이 HomePage 변수는 페이지의 elements인 page objects를 포함합니다. 테스트를 거친 다른 섹션에 대해 서로 다른 페이지 객체가 사용됩니다.

  6. Create page objects for the center stage buttons with the HomePage variable, like so:

        6. 다음과 같이 HomePage 변수를 사용하여 가운데 스테이지 버튼에 대한 페이지 객체를 만듭니다.

           
       var HomePage = function() { 
          this.centerStageButtons = element(by.css(".center.stage-buttons"));
    
          this.viewOnGitHubButton = this.centerStageButtons.all(by.css(".btn.btn-large")).get(0);
          this.downloadButton = this.centerStageButtons.element(by.css(".btn-primary"));
          this.designDocsButton = this.centerStageButtons.element(by.css(".btn-warning"));
       };
           

    You can see that there has been a page object created for centerStageButtons. It is good practice to write the elements as they match the code in DOM as quite often there will be multiple elements with the same name. Chaining the page objects (as above) creates more readable code as it (most of the time) eliminates the need for using .get(index). I say most of the time, since sometimes having to use .get(index) is inevitable: so if you enter in to the browser console $(".btn.btn-large") you will be able to see multiple results are returned, which is why we use .get(0) for the viewOnGitHubButton example above.

        centerStageButton에 대해 생성 된 페이지 객체가 있다는 것을 알 수 있습니다. DOM 에서 매치되면 같은 이름으로 elements들이 여러번 사용되기 쉽기 때문에 이 엘리먼트들을 사용하는 것은 좋은 방법입니다. 위와 같이 page objects를 묶는 것은 (대부분의 경우) .get (index)를 사용할 필요가 없으므로 더 읽기 쉬운 코드를 생성합니다. 대부분의 경우, 때로는 .get (색인)을 사용해야하는 것이 불가피합니다. 브라우저 콘솔 $ ( ".btn.btn-large")에 입력하면 여러 결과가 반환되는 것을 볼 수 있습니다. , 위의 viewOnGitHubButton 예제에서 .get (0)을 사용하는 이유입니다.



  7. Underneath the HomePage variable, create the test suite and spec like this:

    7. HomePage 변수 아래에 다음과 같이 테스트 suite와 spec을 작성하십시오.

    
       describe('angularjs.org', function() {
    
          beforeEach(function() {
             browser.get('https://angularjs.org/');
          });
      
          it('should have a three buttons', function() {
      
          });
       });
           
  8. In the describe, create a new HomePage object and in the it spec write the expected result of the test as below:

    8. describe에 새 HomePage 객체를 만들고 이 객체의 spec에 다음과 같이 예상되는 테스트 결과를 작성합니다.
    
       describe('angularjs.org', function() {
          var homePage = new HomePage();
    
          beforeEach(function() {
             browser.get('https://angularjs.org/');
          });
      
          it('should have a three buttons', function() {
             expect(homePage.viewOnGitHubButton.isDisplayed()).toBe(true);
          });
       });
           
  9. Run the test by opening up the command line, navigating to the folder where the config file is located. Type in protractor protractorConf.js and press Enter for the code to start running (make sure you have started the selenium webdriver by typing in webdriver-manager start and pressing enter in the command line).

    9. command line을 열고 config 파일이있는 폴더로 이동하여 테스트를 실행하십시오. 코드를 실행하려면 protractor protractorConf.js를 입력하고 Enter 키를 누릅니다 (webdriver-manager start를 입력하고 명령 행에서 Enter 키를 눌러 selenium webdriver를 시작했는지 확인하십시오).

  10. Did it pass? Yes? Great! No? Double check you have the code written correctly by looking at the code inside the Spec folder here: https://github.com/hannimator/angularjs.org_protractor .

    10. 통과 했습니까? 예? 좋습니다! 아니요? Spec 폴더의 코드 (https://github.com/hannimator/angularjs.org_protractor)를보고 코드가 올바르게 작성되었는지 다시 확인하십시오.

  11. Now that this test has passed, it is always best to check that it fails if set to false, so underneath the first expect, create another one set to false like this:

    11. 이제 이 테스트가 통과되었으므로 false로 설정하면 실패하는지 확인하는 것이 가장 좋습니다. 따라서 첫 번째 기대치 아래에서 다음과 같이 false로 설정된 또 다른 하나를 만듭니다.
           
       expect(homePage.viewOnGitHubButton.isDisplayed()).toBe(false);
           
  12. Run the test. Observe the expect set to false fails. This ensures that it isn’t a false positive, and is always a good practice to ensure that you haven't missed anything in your code.

    12. 테스트를 실행하십시오. expect가 false로 설정된 것을 확인하십시오. 이렇게하면 false positive가 아니라는 것을 알 수 있습니다. 그리고 코드에서 아무 것도 놓치지 않았는지 확인할 수 있는 좋은 방법입니다.

In the next tutorial we will use what we learnt in this tutorial and start to learn how to interact with elements on the webpage, as well as the difference between using the matchers isPresent and isDisplayed.

다음 튜토리얼에서는이 튜토리얼에서 배운 것을 사용하고 웹 페이지에서 요소와 상호 작용하는 방법을 배우기 시작할 것이고, isPresent와 isDisplayed라는 matcher를 사용하는 것의 차이점도 알게 될 것이다.


저작자 표시 비영리 동일 조건 변경 허락
신고

[Rally] Create and Customize Fields

2016.02.03 06:20 | Posted by 솔웅


Create and Customize Fields



CA Agile Central (Rally) 에 Field 를 추가하거나 수정하려면 subscription 이나 workspace administrator permission을 가지고 있어야 한다.

field들은 Visible 혹은 hidden 으로 세팅할 수 있다.



Manage Field

Field Summary page에는 해당 work item 과 연관 된 모든 필드들에 대한 정보를 제공한다. workspace나 project perspective에서 이 Fields summary를 볼 수 있다.
이 페이지에 가면 특정 프로젝트, 프로젝트 그룹 혹은 전체 workspace의 필드들의 상태를 볼 수 있다.



이 Field Summary page는
- single work item type의 모든 필드들을 보여준다.
- name, type, custom 대 standard, required 그리고 visibility 등으로 정렬해 볼 수 있다.
- Custom field들을 생성할 수 있다.
- standard와 custom field들을 수정할 수 있다.

 이 Field summary page로 가려면 Workspaces & Projects summary page에서 workspace hyperlink 나 프로젝트 이름을 클릭한다. 그리고나서 페이지 왼쪽에 있는 sidebar에서 Fields 링크를 선택한다.

Workspace Field Page


Project Field page



View Fields

Field들은 defect, user story, task 등과 같은 work item type에 의해 나눠져 있다. 특정 work item type의 필드들을 보려면 Work Item 드롭다운 메뉴를 사용한다. 그러면 해당 work item 에 속해 있는 모든 필드들이 표시된다.

링크

Fields summary page는 아래 필드들을 보여줄 것이다.

Column Meaning
Name The name of the field, as it appears in summary pages, editors, and other locations. Fields have both a system name and display name.
Attribute Type The type of field. For example, text, string, or boolean.
Custom A check mark will display if the field is not a CA Agile Central standard field, and has been created by an administrator.
Required If checked, the field must have a value entered to create or save changes to the work item. Required fields cannot be hidden from specific projects, and are seen by the entire workspace. Note that work items created before a requirement is saved may have other fields edited inline from grid summary pages and apps without entering a value for the required field.
Visible Displays a check mark if the field is visible in the project that the Fields summary page is being accessed from.
Visible on Child Projects Present if viewing the Fields summary page of a project that has open child projects. Displays a check mark if the field is visible in all child projects, and displays Mixed if some children can use the field but others cannot.
Shared Across Work Items Some standard fields, such as Schedule State, are shared across multiple work item types. Changing the settings of a shared field will affect any work item types that use the field.



CA Agile Central 시스템 (Rally)에 의해 내부적으로 사용되는 필드들은 여기에 표시되지 않는다.

필드 변경 이력은 revision history. 특정 프로젝트의 필드의 visibility 변경 이력은 project의 revision history. global changes 는 workspace revision history 등을 보면 알 수 있다.



Delete Fields

필드를 삭제할 수는 없다. 대신에 Visible 드롭다운에서 No를 선택하면 해당 필드가 안 보이도록 하면 된다.

링크

동시에 같은 타입의 또 다른 커스텀 필드가 필요하면 필드를 수정한 후 이름을 바꾸면 새로운 것을 만들 수 있다.

Types of Fields


CA Agile Central 은 여러 용도의 다양한 필드 타입을 제공한다.

Type Description
Boolean A checkbox representing a True or False option.
Date A calendar icon displays in work item editors. When a date is chosen, it displays in text format next to the calendar.
Decimal A number with a maximum of six digits before and three digits after the decimal point.
Drop Down List A list of options that contains a series of strings or textual information.
Drop Down (Multi-Value) Open Beta A list that contains one or more pre-defined fields from which a user can choose multiple items. The valid selections for the list are customizable.
Integer A number field with a maximum of nine digits.
String A field that accepts alphanumeric and special characters. Limited to 256 characters.
Text Provides a field with rich-text formatting options. Text fields may hold up to 32Kb of data.
Web Link Use this field to embed a web link or reference to an object in an external system.



특정 HTML 태그를 표시하기 위해 String 필드를 사용할 수 있다. 더 자세한 용도는 HTML Whitelist Policy를 보라.

일단 필드가 생성되었다면 해당 필드의 type을 바꿀 수는 없다.




Supported Items

아래 work item들과 objects들에서 custom fields 를 지원한다.


    Defects
    Defect Suites
    Iterations
    Milestones
    Portfolio Items
    Projects
    Releases
    Tasks
    Test Cases
    Test Case Results
    User Stories
    Workspaces


Create Custom Fields

필요한 필드가 있으면 생성할 수 있다. 이 Custom Fields는 subscription이나 workspace administrator에 의해 추가될 수 있고 전체 workspace나 특정 project 혹은 project hierarchy의 section에서 보여지게 할 수도 있다. Custom fields는 editor pages, custom views, Web Services API queries 등에서 사용 가능하고 detail and summary page에서 볼 수 있다.

Note
- 새로운 portfolio item type을 추가할 때 여러분이 추가하는 type이 같은 workspace에 globally scoped 된다는 것을 유념하라. 그렇지 않으면 validation error가 표시 될 것이다.
- project나 workspace administrative page들에서 custom field를 생성하게 될 텐데. 그 custom field는 workspace level의 데이터베이스에 존재하게 될 것이다. 그리고 visibility는 workspace나 project level에서 control 된다.
- custom field를 생성한 곳에서 visibility도 constol 할 수 있다. 만약 새 필드를 몇개의 프로젝트에서만 적용시키려면 특정 프로젝트에서 생성하거나 사용하고자 하는 project hierarchy 의 top 에서 생성한다. 특정 프로젝트들에서만 custom field를 숨기고 싶다면 workspace level에서 생성해서 그 프로젝트들에서 hidden 으로 해당 필드를 세팅하면 된다.
- 같은 field 가 같은 workspace에 복수개 존재할 수 없다. 여러 project들은 한개의 field를 공유할 수 있다. 이 경우 같은 values 와 settings를 사용해야 한다. 다른 프로젝트와 독립적인 field를 생성하려면 반드시 다르게 이름을 지어야 한다.
- custom field의 required value는 workspace level에서 세팅한다. 만약 새로운 custom field를 생성한다면 그것은 required이다. 이것은 모든 open project들에 visible 할 것이고 required 하게 될 것이다.
- CA Agile Central standard field들은 visible/hidden 될 수 있다. 이것은 workspace 레벨에서만 적용된다.
- Custom fields는 defect suites 에는 적용되지 않는다.

새로운 Custom field를 생성하려면

1. Workspace나 Project의 Fields summary page로 간다. (링크)
2. Work Item dropdown을 클릭하고 필드를 생성하고 싶은 work item의 type을 선택한다.
3. New Field 버튼을 클릭한다.
4. name, Display Name, Type 필드에 값을 입력한다. Name과 Display Name에는 unique한 값을 넣어야 한다.
5. 이 필드를 Mandatory로 하려면 Required option을 체크한다.
6. 프로젝트나 workspace 의 필요성에 따라서 필드의 visibility를 세팅한다.
7. Save & Close를 클릭한다.


링크

Edit Fields

1. Workspace나 Project의 Fields summary page로 간다.
2. Work Item dromdown 을 클릭하고 type을 선택한다.
3. field 왼쪽의 gear icon을 클릭하고 Edit을 선택한다.
4. Field value를 업데이트 한다.
5. Save & Close 를 클릭해 수정을 마친다.




Note
- 여러 work items 에 걸쳐 사용되는 Shared field 가 있다. 이 필드를 수정하게 되면 다른 work item들도 영향을 받게 된다. 또한 해당 필드에 notification 룰이나 custom views를 생성한 사용자들도 영향을 받게 된다.
- Type 같은 어떤 standard CA Agile Central fields들은 수정이 불가능 한 것도 있다.
- CA Agile Central system에 의해 사용되는 어떤 필드들은 required 이다. 만약 그렇다면 해당 필드는 수정 할 수 없다.


Editor window fields

Field Description
Name This name is used by the CA Agile Central application. For CA Agile Central fields, this name is already populated. This name is not displayed in the Fields summary page, but does display in Create and Edit screens for administering work item fields.
Display Name This is a textual field allowing you to enter the name that will be displayed to users of the workspace.
Type The type of field. Cannot be changed after a field is created.
Occurrences A calculated number that indicates how often a field is being used by work items in the workspace.
Required Require that the field be populated upon creation or edit. Note: Marking a field Required has implications for inline editing, multi-editing, and importing data. The Add button on some board and grid apps will force a full editor window to display, so the required field may be filled in when creating a new work item. Work items created before the requirement is enforced may have other fields edited inline from grid summary pages and apps without entering a required value. In addition, existing integrations may fail if a field is marked Required after the integration is in place.
Visible When accessed from the workspace, displays a single drop-down that controls the fields visibility for all projects. If only some projects are set to view the field, it will be set as Mixed. Choosing the Yes or No options will show or hide the field in all open projects after saving. When accessed from a project with child projects, two drop-downs display. The top drop-down controls visibility for the project the editor was accessed from, while the lower drop-down controls visibility to all child projects.



Manage Project Visibility

전체 workspace에 visible 하게 custom field를 세팅할 수 있다. 그리고 특정 프로젝트나 특정 프로젝트 그룹에만 보이도록 할 수도 있다. 프로젝트에 대한 Fields visible을 설정하는 것은 아래에서 가능하다.


    Work item detail pages
    Editor windows
    Summary pages
    Apps
    Custom views
    Notification rules
    Web Services API

Note
- page나 app 안에서 project scoping을 변경하면 visibility setting 에 따라 custom field들의 availability 가 영향을 받는다.
- When viewing the Backlog page scoped to a hierarchy of projects, fields that are visible in some child projects but not others will display.
- Queries from the Web Services API will respect project visibility. Unless specified, queries will use the default project and scoping set in your profile.
- When using a connector with a supported version of the WSAPI, any fields fetched for will be returned, regardless of visibility settings.

해당 필드를 사용할 프로젝트를 설정하려면 field editor 의 Visible 섹션을 사용한다.



특정 프로젝트에 visible 한가 여부를 보려면 Field summary page로 가면 도움이 될 것이다.


- From the workspace, fields available to all projects will display a check mark in the Visible column. Fields available to some projects but not others will display Mixed in the column.
- From a specific project, the Visible column will display a check mark if the field can be used in that project.
- If viewing a project that has children, the Visible on Child Projects column will display. A check mark will be present if the field can be used in all open child projects. Mixed will display if the field can only be used in some of the child projects.

어떻게 필드를 생성하고 visibility 를 조정할 것인가에 댛 아래 추천 방법을 참고하세요.

Set a field to be used by the entire workspace

    Access the Fields summary page from the workspace level.
    Create or edit the field.
    In the field editor window, set the Visible drop-down to Yes.
    All open projects will have access to the field.

Set a field to be used by a single project

    Access the Fields summary page from the project you want to use the field in.
    Create or edit the field.
    In the field editor window, set the Visible In This Project drop-down to Yes.
    Repeat for each unrelated project you want to use the field in.

Set a field to be used by a group of projects in a hierarchy

    Access the Fields summary page from the top-most level of the project hierarchy that you want to use the field in.
    Create or edit the field.
    In the field editor window, set both Visible drop-down menus to Yes.
    The project you accessed the Fields summary page from, and all open child projects will have access to the field.




Drop Down List (Multi-Value) Open Beta

Subscription and workspace administrators 는 이제 multi-value custom fields를 생성할 수 있게 됐다.
Custom fields allows CA Agile Central users to tailor our product to meet their unique needs. Multi-value custom fields extends the value of single-value custom fields and are available across all of the artifact types that support custom fields. These fields are configured in the Field editor pop-up window after you select Drop Down List (Multi Value) as the type of field.

일단 admin에 의해 설정 되면 그 multi-value drop-down 리스트는 이 custom field가 적용되는 모든 곳에 동일하게 고쳐진다.

- New editable detail pages



- Legacy detail pages