test

사용

test: historic_revenue_is_accurate {
  explore_source:  orders {
    column:  total_revenue {
      field:  orders.total_revenue 
    }
    filters: [orders.created_date:  "2017"]
  }
  assert:  revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
}
계층 구조
test

- 또는 -

test

- 또는 -

test
기본값
없음

허용
데이터 테스트의 식별자 및 테스트 어설션과 쿼리를 정의하는 하위 파라미터입니다.

정의

Looker에는 LookML 검사기를 사용하여 LookML 코드가 문법적으로 유효한지 확인하고 콘텐츠 검사기를 사용하여 콘텐츠와 모델 간의 객체 참조를 확인합니다.

이러한 검사기 외에도 test 파라미터를 사용하면 모델의 로직을 검증할 수 있습니다. 각 데이터 테스트에 대해 쿼리와 yesno 어설션 문을 만듭니다. 데이터 테스트는 테스트 쿼리를 실행하고 테스트 쿼리의 각 행에 대해 어설션이 true인지 확인합니다. 어설션 문이 테스트 쿼리의 모든 행에 대해 yes를 반환하면 데이터 테스트가 통과합니다.

프로젝트 설정이 프로덕션에 배포하기 전에 데이터 테스트를 통과하도록 요구하도록 구성되어 있고 프로젝트에 하나 이상의 test 파라미터가 있는 경우, 프로젝트에 변경사항을 커밋하면 IDE에서 테스트 실행 버튼을 표시합니다. LookML 개발자는 변경사항을 프로덕션에 배포하기 전에 데이터 테스트를 실행해야 합니다.

프로젝트에서 프로덕션에 배포하기 전에 데이터 테스트를 요구하는지 여부와 관계없이 개발 모드의 LookML 개발자는 언제든지 데이터 테스트를 실행하여 모델의 로직을 확인할 수 있습니다.

모델 파일(model files), 뷰 파일(view files) 또는 별도의 전용 데이터 테스트 파일(data test files)에서 데이터 테스트를 만들 수 있습니다. 전용 파일을 사용하여 데이터 테스트를 호스팅하는 경우 데이터 테스트를 실행하려는 모델 파일 또는 뷰 파일에 데이터 테스트 파일을 include해야 합니다.

데이터 테스트는 동일한 프로젝트의 다른 데이터 테스트와 이름 및 explore_source가 동일할 수 없습니다. 프로젝트의 여러 데이터 테스트에 동일한 explore_source를 사용하는 경우 데이터 테스트의 이름이 모두 고유해야 합니다.

test 파라미터에는 다음과 같은 하위 파라미터가 있습니다.

  • explore_source: 데이터 테스트에 사용할 쿼리를 정의합니다.
  • assert: 데이터를 확인하기 위해 테스트 쿼리의 모든 행에서 실행되는 Looker 표현식을 정의합니다.

테스트의 LookML을 정의한 후 데이터 테스트를 실행하여 테스트가 제대로 작동하는지 확인하고 모델의 로직이 테스트를 통과하는지 확인할 수 있습니다. 데이터 테스트를 실행하려면 개발 모드에 있어야 합니다.

프로젝트의 데이터 테스트를 시작하는 방법에는 여러 가지가 있습니다.

  1. 프로덕션에 파일을 배포하기 전에 데이터 테스트를 통과하도록 프로젝트 설정이 구성되어 있으면, 변경 사항을 프로젝트에 커밋한 후 IDE에서 테스트 실행 버튼을 표시합니다. 변경사항을 프로덕션에 배포하려면 먼저 데이터 테스트를 통과해야 합니다. 변경사항을 프로덕션에 배포하려면 먼저 데이터 테스트를 통과해야 합니다.
  2. 프로젝트 상태 패널에서 데이터 테스트 실행 버튼을 선택합니다. 테스트를 정의하는 파일에 관계없이 프로젝트의 모든 데이터 테스트가 실행됩니다.
  3. 파일 메뉴에서 LookML 테스트 실행 옵션을 선택합니다. 이렇게 하면 현재 파일에 정의된 테스트만 실행됩니다.

데이터 테스트를 실행하면 프로젝트 상태 패널에 진행 상황과 결과가 표시됩니다.

각 테스트 결과에 대해 쿼리 탐색 링크를 선택하여 데이터 테스트에 정의된 쿼리로 Explore를 열 수 있습니다.

explore_source

데이터 테스트의 explore_source 파라미터는 파생 테이블의 explore_source 파라미터와 동일한 문법과 로직을 사용합니다. 한 가지 차이점은 데이터 테스트의 explore_sourcederived_column, bind_filters, bind_all_filters 하위 파라미터를 지원하지 않는다는 것입니다.

유용한 팁: explore_source LookML을 가져오는 쉬운 방법은 기존 Explore를 사용하여 쿼리를 만드는 것입니다. Explore에서 Explore의 톱니바퀴 메뉴에서 LookML 가져오기 를 선택한 다음 파생 테이블 탭을 선택하여 쿼리의 LookML을 가져옵니다. 자세한 내용은 기본 파생 테이블 만들기 문서를 참고하세요.

데이터 테스트의 explore_source에 관해 다음 사항에 유의하세요.

  • 데이터 테스트의 explore_source 쿼리는 표준 Looker 쿼리입니다. 즉, 테스트의 explore_source 쿼리는 5,000개의 행으로 제한됩니다. 테스트할 전체 결과 집합을 가져올 수 있도록 쿼리가 5,000개의 행을 초과하지 않도록 하세요. explore_source에 필터 또는 정렬을 통합하여 쿼리의 행 수를 줄이거나 관련 행을 쿼리의 상단으로 가져올 수 있습니다.

  • extension: required가 포함된 explore데이터 테스트explore_source로 사용할 수 없습니다. LookML 검사기explore_source를 찾을 수 없다는 오류를 생성합니다.

assert

assert 하위 파라미터는 explore_source 쿼리의 결과가 유효한 것으로 간주되는 기준을 정의합니다. expression 하위 파라미터는 Looker 표현식을 허용하며, 이 표현식은 yesno (불리언)를 생성합니다. explore_source 쿼리가 실행된 후 어설션의 표현식이 쿼리 결과 집합의 모든 행에 대해 평가됩니다. 쿼리의 행에 no 응답이 있으면 데이터 테스트가 실패합니다. 쿼리 자체에 오류가 있으면 테스트도 실패합니다.

테스트에는 여러 assert 선언이 있을 수 있습니다. 테스트를 통과하려면 각 어설션이 explore_source 쿼리의 모든 행에 대해 true여야 합니다.

유용한 팁: 테이블 계산 대화상자를 사용하여 테스트의 expression 파라미터에 사용할 Looker 표현식 문법을 테스트할 수 있습니다.

데이터 테스트에 사용하려면 Looker 표현식의 필드가 완전히 범위 지정되어야 합니다. 즉, view_name.field_name 형식을 사용하여 지정됩니다. 예를 들어 다음 표현식은 필드를 aircraft_engine_types.aircraft_engine_type_id로 선언합니다.

assert: engine_type_id_not_null {
  expression: NOT is_null(${aircraft_engine_types.aircraft_engine_type_id}) ;;
}

예시

기본 키가 고유한지 확인

다음 데이터 테스트는 orders Explore에서 쿼리를 만들고 결과 집합에서 주문 ID가 고유한지 테스트하는 expression을 정의합니다. explore_source 쿼리는 데이터베이스의 각 ID와 연결된 행 수를 만듭니다. ID가 고유한 경우 데이터베이스에는 ID에 대한 행이 하나만 있어야 합니다. 또한 개수를 기준으로 정렬하고 결과 집합을 한 행으로 제한하므로 쿼리 응답은 개수가 가장 많은 ID가 됩니다. ID의 개수가 1보다 크면 해당 ID에 여러 행이 있으므로 ID가 고유하지 않습니다. 이 경우 이 데이터 테스트는 실패합니다.

test: order_id_is_unique {
  explore_source: orders {
    column: id {}
    column: count {}
    sorts: [orders.count: desc]
    limit: 1
  }
  assert: order_id_is_unique {
    expression: ${orders.count} = 1 ;;
  }

알려진 값 확인

다음 데이터 테스트는 2017년 수익 값이 항상 626,000달러인지 확인합니다. 이 데이터 세트에서 이 값은 변경되어서는 안 되는 알려진 값입니다.

test: historic_revenue_is_accurate {
  explore_source: orders {
    column: total_revenue {
      field: orders.total_revenue
    }
    filters: [orders.created_date: "2017"]
  }
  assert: revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
}

null 값이 없는지 확인

다음 데이터 테스트는 데이터에 null 값이 없는지 확인합니다. 이 explore_sourcesort를 사용하여 null이 쿼리의 상단에 반환되도록 합니다. null 정렬은 언어에 따라 다를 수 있습니다. 다음 테스트에서는 desc: yes를 예시로 사용합니다.


test: status_is_not_null {
  explore_source: orders {
    column: status {}
    sorts: [orders.status: desc]
    limit: 1
  }
  assert: status_is_not_null {
    expression: NOT is_null(${orders.status}) ;;
  }
}