단위 테스트 소스 모델


10

내 사용자 지정 확장 프로그램에는 엔터티의 추가 / 편집 형식으로 일부 선택 및 / 또는 다중 선택을 채우는 용도로만 사용되는 여러 모델이 있습니다.
이것이 바로 마 젠토가 "소스 모델"이라고 부르는 것입니다.
관련된 값은 항상 동일하며 메소드는 동일한 것을 반환합니다.
그것들을 어떻게 단위 테스트해야합니까? 아니면 단위 테스트를 작성해야합니까?
다음은 예입니다.
다음 클래스는 호출 된 필드 type와 같은 필드의 격자 열에 대한 추가 / 편집 양식에 사용됩니다 .

<?php
namespace Sample\News\Model\Author\Source;

use Magento\Framework\Option\ArrayInterface;

class Type implements ArrayInterface
{
    const COLLABORATOR = 1;
    const EMPLOYEE = 2;

    /**
     * Get options
     *
     * @return array
     */
    public function toOptionArray()
    {
        $_options = [
            [
                'value' => '',
                'label' => ''
            ],
            [
                'value' => self::COLLABORATOR,
                'label' => __('Collaborator')
            ],
            [
                'value' => self::EMPLOYEE,
                'label' => __('Employee')
            ],
        ];
        return $_options;
    }

    /**
     * get options as key value pair
     *
     * @return array
     */
    public function getOptions()
    {
        $_tmpOptions = $this->toOptionArray();
        $_options = [];
        foreach ($_tmpOptions as $option) {
            $_options[$option['value']] = $option['label'];
        }
        return $_options;
    }
}

답변:


15

이것은 훌륭한 스레드이며 @KAndy와 @fschmengler의 답변을 정말 좋아합니다.
"X를 테스트해야합니까?"와 같은 질문을 할 때 귀중한 생각을 추가하고 싶습니다. 또는 "X를 어떻게 테스트해야합니까?"

무엇이 잘못 될 수 있습니까?

  • 나는 어리석은 오타를 만들 수있다
    .
  • 코어 또는 다른 모듈에서 필요한 코드를 복사 한 다음 필요에 맞게 조정할 수 있습니까?
    나는 이것이 실제로 미묘한 버그를 남기는 매우 위험한 일을 발견합니다. 이 경우 테스트가 너무 비싸지 않으면 테스트 작성을 선호합니다. 소스 모델을 기반으로 구성하면 실제로보다 위험한 IMO가됩니다.
  • 다른 모듈과 충돌이있을 수 있습니까?
    이것은 거의 구성 코드에만 적용됩니다. 그런 경우에는 언제 발생하는지 알려주는 통합 테스트를 원합니다.
  • Magento가 향후 릴리스에서 API를 변경할 수 있습니까?
    코드가 인터페이스에만 의존하기 때문에이 경우에는 매우 드 Very니다. 그러나 더 구체적인 클래스가 포함되거나 내 코드가 핵심 클래스를 확장하면 잠재적 인 위험이 더 커집니다.
  • 새로운 PHP 버전은 내 코드를 손상시킬 수 있습니다. 또는 앞으로 몇 년 동안 PHP 5.6을 지원하고 싶을 수도 있습니다.
    다시 말하지만, 여기에서는 매우 드물지만, 경우에 따라 호환되지 않는 구문을 사용하도록 코드를 변경해야 할 경우 테스트를 원합니다.

코드를 테스트하는 데 비용이 얼마나 드나요?

여기에는 두 가지 측면이 있습니다.

  • 시험을 작성하는 데 걸리는 노력과 시간
  • 수동으로 작성하려는 코드를 테스트하는 데 걸리는 시간과 노력.

일부 코드를 개발하는 동안 코드 작성이 완료 될 때까지 작성중인 코드를 자주 실행해야하는 경향이 있습니다. 물론 단위 테스트를 사용하면 훨씬 쉽습니다.

귀하의 경우 테스트 작성은 저렴합니다. 많은 시간이나 노력이 들지 않습니다. @KAndy는 모든 코드를 유지 관리해야하지만 모든 테스트를 유지해야하는 것은 아닙니다.
이것은 내가 멍청한 실수를하지 않는지 확인하고 수업이 끝나면 삭제하기 위해 단위 테스트를 작성하는 예제 일 수 있습니다. 테스트가 장기적인 가치를 제공하지 않으면 삭제하는 것이 합리적이라고 생각합니다.

이 질문은 또한 작성할 테스트 유형 (예 : 단위 또는 통합)을 선택할 때 중요합니다.

내가 작성하는 코드는 얼마나 가치가 있습니까?

내가 작성하는 코드가 모듈이 제공하는 서비스에 필수적이라면, 사소한 것이더라도 테스트합니다.
UI에 중점을두고 비즈니스 로직의 일부가 아닌 작은 유틸리티 방법이라면 그렇지 않을 수도 있습니다.

코드를 변경해야합니까?

시간이 지남에 따라 테스트 적용 범위에 익숙해 져서 발견되지 않은 코드를 변경하는 것은 매우 안전하지 않은 것으로 느껴집니다. 여기에는 소스 모델에 옵션을 추가하는 것과 같은 간단한 것들뿐만 아니라 클래스를 다른 폴더 / 네임 스페이스로 옮기거나 메소드의 이름을 바꾸는 것과 같은 것들도 포함됩니다.
그러한 변화에 대한 테스트를 실시하는 것은 매우 중요합니다.

문서가 필요합니까?

코드를 사용하는 것이 얼마나 어렵습니까? 예를 들어 사소한 것이지만 좀 더 복잡한 경우에는 다른 개발자 (또는 몇 달 내)의 문서 목적으로 테스트하는 것이 좋습니다.

탐구와 학습

일부 코드를 작업 중이고 테스트 방법 을 잘 모를 경우 테스트를 작성하는 것이 매우 중요합니다. 이 과정은 거의 항상 내가 다루고있는 것에 대한 깊은 이해를 제공합니다.
이는 여전히 학습 학습을 고려하는 개발자에게 해당됩니다.
이것은 또한 제공 한 주요 가치가 학습이기 때문에 나중에 테스트를 삭제하는 것이 합리적 일 수있는 예입니다.

훈련과 스트레스

빨강 녹색 리 팩터 루프를 고수하면 빠르게 진행할 수 있습니다. 이것은 압력 하에서 특히 그렇습니다. 따라서 일부 코드가 실제로 테스트에 적합하지 않더라도 TDD를 따를 수 있습니다. 특히 코드가 사소한 경우에는 특히 그렇습니다.
이것은 흐름과 경고에 나를 유지합니다.

무엇을 어떻게 테스트합니까?

또한 매우 다른 세분성으로 테스트를 작성할 수 있습니다.

  • 정확한 반환 값을 테스트합니다.
    이것은 모든 변경에 맞게 조정해야하는 매우 엄격한 테스트입니다. 예를 들어, 반환 배열의 항목 순서가 변경되는 경우 테스트를 중단 하시겠습니까?
  • 반환 값의 구조를 테스트합니다.
    소스 모델의 경우 각 하위 배열을 두 개의 레코드 (하나는 a label, value키 는 하나)로 점검 할 수 있습니다 .
  • 클래스 구현 확인 ArrayInterface.
  • 클래스 테스트는 getOptions()해당 메소드가 구현 된 인터페이스의 일부가 아니더라도 제공합니다 .

테스트 할 수있는 각 항목에 대해 가치, 유지 보수성 및 비용을 고려하십시오.

요약

요약하면 : 일부 코드 조각을 테스트 해야하는지 여부에 대한 질문에 대한 진정한 단일 답변은 없습니다. 상황에 따라 개발자마다 답변이 달라집니다.


2
좋은 대답입니다! "더 이상 가치를 제공하지 않으면 테스트 삭제"부분을 강조하고 싶습니다. 때로는 초기 개발 단계에서 도움이 된 오래된 테스트가 장기적으로 진행되고 있습니다.
Fabian Schmengler

1
당신은 내가 의심했던 다른 두 가지 질문에 대답했습니다. 감사합니다
Marius

6

제 생각에는 "소스 모델의 단위 테스트 작성, 예 또는 아니오"에 대한 일반적인 대답은 없습니다.

소스 모델에 대한 단위 테스트를 작성했지만 외부 데이터를 가져 오는 동적 소스 모델이었으며 그 결과가 합리적입니다.

영광스러운 배열에 불과한 소스 모델의 경우 (예와 같이) 단위 테스트를 작성하지 않아도됩니다. 그러나 어떤 식 으로든 실수하지 않았는지 확인해야합니다. 몇 가지 옵션이 있습니다.

  1. 단위 테스트
  2. 통합 테스트
  3. 수동으로 구성을보십시오

TDD 님을 팔로우하고 계신가요? 그런 다음 (1)과 (2) 중 하나 또는 둘 다를 선택하십시오. 그렇지 않으면 (2)와 (3) 중에서 선택하십시오.


시스템 구성 옵션에 소스 모델을 사용하는 경우 통합 테스트 (모든 구성 옵션에 대해 한 번의 테스트)로 구성 섹션을 렌더링하고 <select>요소가 있고 예상 값을 포함 하는지 확인할 수 있습니다. 이것은 특정 클래스를 테스트하는 것이 아니라 모든 것이 올바르게 묶여 있는지 테스트하는 것입니다.


@KAndy가 말했듯이 이상적으로는 많은 상용구가 필요하지 않으며 이미 단위 테스트 된 기본 클래스를 확장하고 속성을 재정의하거나 외부 구성에서 값을 정의하기 만하면됩니다.

이 시나리오에서 구체적인 구현에 대한 단위 테스트는 추가 가치를 제공하지 않습니다. 이러한 클래스가 많은 경우 ArraySourceMagento가 제공하지 않는 한 기본 클래스를 직접 작성하는 것이 좋습니다 .


이러한 기본 클래스를 사용하면 소스 모델이 다음과 같이 보일 수 있습니다.

class Type extends ArraySource
{
    const COLLABORATOR = 1;
    const EMPLOYEE = 2;
    protected $elements = [
        self::COLLABORATOR => 'Collaborator',
        self::EMPLOYEE     => 'Employee',
    ];
    protected $withEmpty = true;
    protected $translate = true;
}

확인 감사합니다. 영광스러운 배열을 구성 가능한 옵션 목록으로 바꾸려고하지만 정확히 N 개의 옵션이있는 모델에도 동일하게 적용됩니까? "상태"소스 모델과 같습니다.
Marius

"상태"소스 모델이 "작성자 유형"예와
어떻게 다른지 모르겠습니다.

프론트 엔드에서 값 0과 1 (클래스 상수로)을 사용하여 예를 들어 활성화 된 엔티티를 필터링 할 수 있기 때문입니다. 이 경우 옵션 값 뒤에 논리가 있습니다. 그들은 단지 key=>value쌍이 아닙니다 .
Marius

그러나이 논리는 소스 모델의 일부가 아닙니다. 그것은 여기서 중요하지 않다는 것을 의미합니다. 다른 곳에서 사용할 상수가 여전히 있습니다. 나는 그러한 유혹을 어떻게 사용하는지 예를 추가했습니다.
Fabian Schmengler 2016

5

그것들을 어떻게 단위 테스트해야합니까?

나는 당신이해서는 안된다고 생각합니다.

시스템에 지원 및 유지 관리 비용을 증가시키는 코드를 추가하지만 테스트 프로세스는 LEAN 이어야합니다 .

이 코드 이상은 존재하지 않아야합니다. 나는 마 젠토보다 다른 곳에서 사용할 옵션 세트를 정의하는 일반적인 선언적 방법이어야한다고 생각합니다. 이 수업에 대한 작문 시험에 대한 당신의 꺼리는 나쁜 코드 냄새를 보여줍니다.


1
감사. 따라서 이러한 옵션은 하드 코딩되어서는 안되며 구성 파일 (예 : di.xml)에서 가져와야합니다. 나는 그것을 할 수 있습니다. 그러나 상태 소스 모델도 마찬가지입니까? 위와 동일한 클래스를 가지고 있지만 상태가 활성화 및 비활성화 된 상태 (1,0) 만 동일한 구성 방식을 사용해야합니까? 그렇다면, 나는 그것이 과도하게 엔지니어링되는 것처럼 보입니다.
Marius
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.