시각적 테스트를 통해 종단 간 품질 유지

테스트는 모든 개발자의 워크플로에서 중요한 부분입니다. 이는 우리 프로젝트가 높은 수준의 품질을 유지하고 성가신 버그가 야생으로 유출되는 것을 방지하는 데 도움이 됩니다.

그러나 종종 자동화된 테스트는 관리하기 어려울 수 있습니다. 완전한 적용 범위를 제공하는지 확인하기 위한 끝없는 양의 코드와 프론트 엔드 테스트의 취약한 특성(단순한 선택기 변경으로 엔드 투 엔드 워크플로가 완전히 중단될 수 있음)을 처리하는 것 사이에서 때로는 힘들게 느껴질 수 있습니다. 전투.

자동화된 시각적 테스트 를 추가하여 이러한 불안정한 테스트를 제거하고 웹 사이트 또는 앱의 스크린샷을 사용하여 스마트 이미지 비교를 활용하여 해당 범위(및 그 이상)를 제공하는 테스트 파이프라인을 평준화할 수 있습니다.

시각적 테스트에 대해 알아보기 전에 잠시 시간을 내어 다양한 유형의 자동화된 테스트와 이러한 테스트가 어떻게 결합되는지 살펴보겠습니다. 그런 다음 시각적 테스트가 정확히 무엇이며 프로젝트에 대한 또 다른 수준의 테스트 범위를 제공할 수 있는 방법에 대해 설명합니다.

자동화된 테스트 유형에 대한 간략한 살펴보기

자동화된 테스트는 개발 주기의 흥미로운 부분입니다. 일부 고객이나 이해 관계자는 자신이 제공하는 가치를 명확하게 볼 수 있지만 다른 고객은 순수한 기능 개발에 소요되는 개발 시간을 선호합니다.

이는 자동화된 테스트의 목표가 비즈니스를 보호하거나 팀이 처음부터 버그를 수정하는 데 시간을 소비하지 않도록 하는 것인 경우 때때로 직관적이지 않을 수 있습니다. 견고한 자동화 테스트 를 작성하면 큰 재정적 손실을 예방할 수 있습니다! 일부 사람들이 다른 사람들보다 더 기꺼이 감수하는 것은 궁극적으로 위험입니다.

운 좋게도 그 가치를 판매하기가 항상 어려운 것은 아니며 품질 자동화 테스트에 집중할 시간이 있을 때 단위 테스트, 통합 테스트, 종단 간 테스트와 같은 테스트를 처리하는 방법에 대한 다양한 옵션이 있습니다. 테스트 및 시각적 테스트(처음 세 개에 대한 확장된 적용 범위를 제공할 수도 있음).

각 테스트 유형의 장점을 적용하면 실제로 작업을 보호하고 고객의 불만을 줄이는 데 도움이 되는 테스트를 작성하는 데 더 많은 시간을 할애할 수 있습니다.

이러한 테스트 전략 중 일부가 실제로 어떻게 보이는지 살펴보겠습니다.

단위 테스트

단위 테스트는 애플리케이션의 더 작고 집중된 영역을 테스트하는 데 중점을 둡니다. 프로모션 후 주문 합계를 계산하는 기능이 제대로 작동하는지 테스트하고 싶으십니까? 단위 테스트를 작성하고 싶을 것입니다.

 function myBusinessLogic(pricePerItem, quantity, discount) { const subtotal = pricePerItem * quantity; return subtotal - ( discount * subtotal ); } expect(myBusinessLogic(2, 4, .1)).toEqual(7.2);

단위 테스트의 가장 큰 장점은 작성 비용이 저렴하고 실행하는 데 많은 시간이 걸리지 않는다는 것입니다. 그렇기 때문에 기업에서 애플리케이션의 세분화된 부분을 캡처하기 위해 단위 테스트 제품군을 구축하는 데 많은 시간을 할애하는 경우를 종종 볼 수 있습니다.

그러나 집중된 테스트 때문에 단위 테스트는 서로 다른 부분이 함께 작동하는 방식을 다루지 않을 수 있습니다. 여기에서 통합 테스트로 이동하기 시작합니다.

통합 테스트

통합 테스트의 목표는 애플리케이션의 더 작은 조각과 구성 요소를 가져와 함께 작동하는 방식을 테스트하는 것 입니다. 일반적인 예는 UI의 특정 부분이 서버 또는 데이터베이스에 대한 요청이 뒤따르는 상호 작용에 응답하는 방법일 수 있습니다.

 cy.get('.add-to-cart').click(); cy.url().should('contain', 'cart'); cy.get('.cart li').contains('My Item');

작은 UI 구성 요소가 자체적으로 예상대로 작동하는 것은 전적으로 가능합니다. 합성 이벤트는 onClick 인스턴스에서 올바르게 트리거될 수 있습니다. API 요청을 래핑하는 코드는 일부 모의 데이터에서 완벽하게 수행될 수 있습니다. 그러나 함께 작동하는 두 조각 사이에 단위 테스트가 포착하지 못할 수 있는 구멍이 있을 수 있습니다.

통합 테스트는 애플리케이션을 테스트하는 강력한 방법이지만 "모든 것"을 테스트할 때 한 단계 더 나아갈 수 있습니다.

엔드 투 엔드 테스트

엔드 투 엔드 테스트는 집중된 워크플로를 위해 전체 사용자 여정을 엔드 투 엔드로 캡처합니다 . 예를 들어 전자 상거래 상점을 구축하는 경우 "행복한 경로"(또는 저항이 가장 적은 예상 경로)는 제품을 찾고 장바구니에 추가하고 해당 항목에 대한 비용을 지불하는 것입니다. 종단 간 테스트를 작성하는 경우 전체 프로세스, 즉 제품 목록 페이지에서 제품을 찾는 것부터 해당 항목에 대한 지불에 이르기까지 전체 프로세스를 캡처합니다.

 cy.visit('/products'); cy.get('.product a[href="/product/1234"]').click() cy.url().should('contain', 'product/1234'); ... cy.get('.order-button').click(); cy.url().should('contain', 'receipt'); cy.get('.receipt li').contains('My Item');

종단 간 테스트의 가장 큰 장점은 본질적으로 대규모 통합 테스트라는 것입니다. UI 작동 방식, API가 올바르게 응답하는지, 이러한 부분이 함께 작동하는지를 포함하여 애플리케이션의 다양한 구성 요소를 캡처하고 있습니다.

문제는 종단 간 테스트, 심지어 통합 테스트도 작성하는 데 더 많은 시간이 걸리고 실행하는 데 훨씬 더 오래 걸린다는 것입니다. 그렇다면 어떻게 모든 테스트 옵션을 활용 하고 애플리케이션을 커버하는 효율적인 방법을 제공할 테스트 모음을 구성할 수 있을까요?

다양한 유형의 테스트 활용

일반적으로 각 유형의 테스트를 몇 번이나 작성해야 하는지 설명하는 다양한 사고 방식이 있습니다.

Mike Cohn은 그의 책 Succeeding with Agile 에서 "테스트 피라미드"의 개념을 제시했습니다.

그는 더 저렴하고 더 빠르게 실행할 수 있는 단위 테스트를 더 많이 작성해야 한다고 주장합니다. 그의 원래 다이어그램은 다양한 테스트의 레이블을 약간 다르게 지정하지만 통합 유형 테스트에 더 많이 기울일수록 실행 속도가 느려지고 작성 비용이 더 많이 듭니다. 이러한 테스트는 가치가 있지만 단위 테스트만큼 많은 통합 또는 종단 간 테스트를 원하지는 않습니다.

이러한 균형을 유지하면 단위 테스트가 있는 비즈니스 논리 및 통합 테스트와 함께 작동하는 방식과 같은 애플리케이션 의 중요한 부분을 캡처하는 데 집중하는 데 도움이 될 수 있지만 Kent C. Dodds는 테스트 기술이 테스트 기술이 없는 지점까지 따라갔다고 주장합니다. 통합 테스트를 작성하기 위한 더 긴 큰 비용 절충안이 그의 "테스트 트로피" 개념이 나오는 곳입니다.

현대 개발 환경에는 개발자와 QA 엔지니어가 Chrome 및 Firefox와 같은 브라우저와 쉽게 상호 작용하는 테스트를 작성할 수 있는 기능을 제공하는 Cypress, Selenium 및 Playwright와 같은 놀라운 도구가 많이 있습니다.

Cypress를 사용하면 버튼을 클릭하는 테스트를 작성하는 것이 다음과 같이 간단해 보일 수 있습니다.

 cy.get('#my-button').click()

버튼이 합성 이벤트와 함께 작동하는지 테스트하는 것만큼이나 간단합니다. 가장 좋은 점은 해당 버튼이 브라우저에서 실제로 어떻게 작동하는지 테스트하고 있다는 것입니다.

구독하는 다이어그램에 관계없이 궁극적으로 목표는 비용과 속도 사이의 다양한 옵션을 평가 하여 특정 애플리케이션에 적합한지 결정하는 것입니다. 커버리지 보고서에서 100%를 달성하는 것뿐만 아니라 방문자에게 제공하는 경험이 제대로 작동하는지 실제로 확인하는 것이 중요합니다.

그러나 실행하는 테스트의 조합에 상관없이 DOM(Document Object Model)과만 상호 작용하고 테스트하는 이러한 프로그래밍 방식 테스트에는 퍼즐의 한 부분, 즉 방문자가 해당 응용 프로그램을 시각적으로 보는 방법이 누락되었습니다.

전통적인 유형의 테스트가 포착하지 못하는 것

애플리케이션에서 단위, 통합 및 종단 간 테스트를 실행할 때 모두 한 가지 공통점이 있습니다. 그들은 모두 코드를 테스트하고 있습니다.

내 말은 애플리케이션 방문자가 실제로 보는 것을 테스트하지 않는다는 것입니다.

통합 테스트 모음을 실행 중이고 앞의 예와 같이 누군가가 장바구니에 제품을 추가하고 구매할 수 있는지 테스트하는 경우 각 단계에서 코드를 통해 DOM에서 요소를 찾고 다음을 확인합니다. 같은 방식으로 작동했습니다.

이것은 페이지의 텍스트를 읽을 수 있는지 여부와 같은 것을 테스트하지 않습니다. 누군가 실수로 모든 것을 왼쪽으로 띄우고 거꾸로 뒤집는 CSS 변경 사항을 추가했습니까?

이러한 유형의 버그를 "시각적 버그"라고 하며, 여기에서 모든 테스트를 화려한 색상으로 통과할 수 있지만 누군가 실제로 보면 옳지 않거나 더 나빠서 완전히 사용할 수 없습니다.

현실적으로, 우리는 전통적인 테스트로 사용자 인터페이스의 모든 세부 사항을 100% 완벽하게 커버할 수 있다고 기대할 수 없습니다. 끝없는 양의 애플리케이션 상태와 우리가 항상 새로운 기능을 추가한다는 사실 사이에서 단순히 확장되지 않습니다.

이것이 우리를 이 이야기의 헤드라인으로 이끄는 것입니다: Visual Testing .

비주얼 테스팅이란?

Visual Testing은 애플리케이션의 가시적 출력(예: 스크린샷)을 캡처하고 이를 다른 시점의 동일한 애플리케이션과 비교합니다.

이는 일반적으로 기준 스크린샷을 먼저 캡처하거나 예상 결과로 이전에 캡처한 애플리케이션 인스턴스를 캡처하고 각각의 새로운 테스트를 해당 기준과 비교함으로써 발생합니다.

그러나 프로젝트가 개발되면 상황이 바뀝니다. 시간이 지남에 따라 새로운 시각적 차이를 승인된 변경 사항으로 승인하면 해당 기준선이 애플리케이션과 함께 업데이트됩니다.

시각적 테스트의 유형

Visual Testing의 흥미로운 점은 이를 처리하는 다양한 방법이 있다는 것입니다.

시각적 테스트에 대한 한 가지 접근 방식은 테스트 프레임워크가 문자 그대로 두 이미지 간에 보이는 모든 차이에 플래그를 지정하는 픽셀별 비교 를 사용하는 것입니다. 이러한 비교는 시각적 테스트에 대한 입문 수준을 제공하지만 불안정한 경향이 있고 많은 오탐지로 이어질 수 있습니다.

상상할 수 있듯이 웹으로 작업할 때 페이지 로드와 브라우저 업데이트 간에 상황이 약간씩 다르게 렌더링되는 경향이 있습니다. 브라우저가 렌더링 변경, 텍스트 커서 표시 또는 "그냥" 때문에 페이지를 1픽셀 렌더링하는 경우 이러한 테스트 실패로 인해 배포가 차단될 수 있습니다.

테스트는 동적 콘텐츠를 다룰 때도 실패하기 쉽습니다. 예를 들어, 이 사이트인 Smashing Magazine 의 홈페이지에서 매일 픽셀 단위 시각적 테스트를 실행했다면 점점 더 많은 콘텐츠를 생산하기 때문에 많은 테스트에 실패하게 될 것입니다.

시각적 테스트를 처리하는 더 나은 방법은 테스트가 실행될 때마다 테스트 프레임워크가 기준과 비교하여 캡처된 스크린샷을 지능적으로 확인하는 AI와 같은 기술을 활용하는 것입니다.

두 캡처가 다른 것을 감지하거나 레이아웃 변경이 아닌 콘텐츠 변경인지 감지할 수도 있습니다. 실제로 변경되지 않은 경우 해당 테스트를 실패한 것으로 표시하지 않으며 해당 콘텐츠로 인해 변경될 수 있는 애플리케이션의 동적 영역을 무시하는 규칙을 추가할 수도 있습니다.

시각적 테스트가 도움이 되는 곳

시각적 테스트는 고객이 본 방식대로 애플리케이션의 현재 상태를 캡처할 수 있다는 점에서 번창합니다. 따라서 실제 사람이 상호 작용하는 모든 응용 프로그램에 적합합니다.

해당 스냅샷을 캡처할 때 테스트를 작성한 단일 세부 구성 요소뿐만 아니라 해당 응용 프로그램의 여러 부분에 대한 적용 범위를 제공합니다. 결국 해당 구성 요소 주변의 컨텍스트를 캡처하여 더 넓은 범위로 이어집니다.

이것은 낮은 오버헤드로 광범위한 적용 범위를 제공 하는 좋은 방법이 됩니다. 테스트 피라미드 또는 테스트 트로피로 돌아가서 실제로 다른 모든 테스트에 더하여 포괄적인 범위를 제공할 수 있습니다.

시각적 테스트는 어떻게 작동합니까?

요지는 간단합니다. 두 이미지를 서로 비교하고 차이점을 찾는 것입니다. 하지만 그보다 조금 더 복잡합니다.

이미지 비교

시각적 테스트를 구현할 때 목표는 실제 사람이 응용 프로그램을 사용하는 방법을 캡처할 수 있는 중요한 워크플로에 대한 적용 범위를 제공하는 것입니다. 여기에는 누군가가 볼 수 있는 맨 처음 화면이 포함되는 경우가 많지만 일반적으로 이 화면이 유일한 화면은 아닙니다.

기존 테스트를 실행하는 방법에 대한 전략을 만드는 것과 마찬가지로, 장바구니에 항목을 추가하거나 위시리스트에 즐겨찾는 항목을 추가하는 것과 같이 UI에서 실제 결과로 끝나는 실제 상호작용을 찾도록 하고 싶습니다.

이를 염두에 두고 각 단계에서 스크린샷을 캡처하고 싶을 것입니다. 예를 들어, 온라인 상점을 테스트하는 경우 다음 단계를 추가할 수 있습니다.

• 페이지에 로드된 제품 목록
• 단일 제품을 선택한 후의 제품 페이지;
• 해당 장바구니에 제품을 추가한 후의 온페이지 장바구니 UI
• 장바구니로 이동한 후 장바구니 페이지
• 결제 흐름에 들어가면 결제 및 배송 UI
• 구매 성공 시 영수증 페이지.

이렇게 하면 누군가가 온라인 상점을 통해 이동할 때 모든 상호작용의 결과를 캡처할 수 있습니다. 여기에서 코드 관점에서 기능적으로 작동하는지 확인할 수 있을 뿐만 아니라 그 사람이 시각적 버그 방해.

테크니컬 비트

스크린샷 계획을 진행하면서 이러한 작업을 자동화하는 메커니즘이 필요합니다. 일련의 작업을 기반으로 브라우저와 상호 작용할 수 있는 것.

여기에서 Selenium, Cypress 및 Playwright와 같은 인기 있는 브라우저 자동화 프레임워크 가 등장합니다. 여기에서 해당 테스트 프레임워크는 브라우저 API를 활용하여 명령을 실행하고 사람처럼 항목을 찾고 클릭한 다음 시각적 테스트 프레임워크에 알려줍니다. UI 상태를 시각적으로 캡처할 때.

Cypress 및 Applitools의 경우 Cypress는 각 페이지를 탐색한 다음 Applitools SDK가 DOM의 스냅샷을 추출하고 해당 스냅샷을 Applitools 클라우드로 전송하여 최종적으로 비교용 스크린샷을 생성합니다.

이 시점에서 시각적 테스트 플랫폼에 따라 차이점이 강조 표시된 형태로 결과 집합이 표시되거나 상황이 좋아 보이면 멋진 녹색 체크 표시가 나타납니다.

기존 테스트 프레임워크와의 통합

위의 Cypress 및 Applitools 통합과 마찬가지로 통합은 일반적으로 마찰이 적습니다. 사용 가능한 많은 시각적 테스트 플랫폼은 기존 테스트 프레임워크에 직접 통합할 수 있으며 대부분 사용 가능한 SDK에 따라 다릅니다.

 cy.visit('/product/1234'); cy.eyesOpen({ appName: 'Online Store', testName: 'Product Page' }); cy.eyesCheckWindow(); cy.eyesClose();

즉, 일반적으로 테스트를 강화하고 시각적 범위를 확보하기 위해 테스트 스위트를 완전히 다시 작성할 필요가 없습니다. 이미 가지고 있는 테스트에 해당 체크포인트를 추가할 수 있습니다.

테스트 자동화

다행스럽게도 개발 및 테스트 관련 작업의 자동화가 빠르게 발전하여 테스트를 자동화할 수 있는 방법에 대한 많은 훌륭한 옵션을 제공합니다.

Jenkins 또는 Travis CI와 같은 기존 CI/CD 솔루션을 사용하면 나머지 통합 및 배포 파이프라인과 함께 해당 환경에서 테스트를 실행할 수 있습니다 . 자동화 공간에 비교적 새로운 것은 GitHub Actions와 같은 도구로, 기존 CI/CD 환경과 유사한 메커니즘을 제공하지만 기존 GitHub 리포지토리 내부에 있습니다. 이렇게 하면 완전히 새로운 시스템이 필요하지 않고 대신 기존 도구를 사용하는 테스트 및 기타 코드 작업을 자동으로 실행하려고 할 때 쉽게 승리할 수 있습니다.

 name: Node.js CI on: [push, pull_request] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - run: npm ci - run: npm test

그러나 사용하는 환경에 관계없이 궁극적으로 테스트 프레임워크의 요구 사항이 적용됩니다. Cypress는 Electron 또는 Chrome과 같은 헤드리스 브라우저에 액세스할 수 있는 한 요즘 매우 일반적인 Node.js를 설치할 수 있는 곳이면 어디에서나 매우 원활하게 작동합니다. 다른 것들은 약간의 추가 환경이 필요할 수 있지만 그 시점에서 일반적으로 원하는 대로 해당 환경을 스캐폴딩하여 테스트를 실행하는 데 필요한 조건을 만들 수 있습니다.

시각적 테스트의 이점은 무엇입니까?

시각적 테스트는 우리가 이미 논의한 것과 같은 다양한 이점을 제공할 것이지만 경영진, 제품 관리자, 개발자, 디자이너 및 실제로 팀의 모든 사람을 포함한 모든 이해 관계자에게 실제로 도움이 됩니다.

예를 들어, CEO 또는 제품 관리자의 경우 테스트 적용 범위가 실제로 실제 사용을 캡처 하고 있다는 확신을 얻고 있습니다. 개발 팀의 경우 변경 사항을 적용할 때마다 즉각적인 피드백을 받을 수 있다는 동일한 확신을 얻게 되며 빠르게 이동하려고 할 때 관련된 두려움 요소를 제거할 수 있습니다. 그러나 실용적인 이점도 많습니다.

유지 관리할 코드 감소

시각적 테스트 플랫폼과 통합할 때 대부분의 코드는 상호 작용과 스크린샷이라는 두 가지를 중심으로 진행됩니다.

상호 작용은 기본적으로 응용 프로그램을 탐색하여 캡처하려는 페이지 또는 사용자 흐름을 찾는 것입니다. 테스트 방법에 관계없이 이것을 어떤 형태로든 유지해야 할 것입니다.

반면에 스크린샷은 일반적으로 테스트에서 작성하는 모든 주장을 다룰 것입니다. 각 스크린샷을 기준과 비교하여 프로젝트의 각 구성 요소가 의도한 대로 정확하게 작동하는지 자동으로 확인합니다.

테스트가 덜 취약함

그리고 이러한 스크린샷을 어설션 메커니즘으로 사용하면 테스트가 덜 취약하고 취약해질 것입니다.

ID 또는 자동 생성 선택기를 사용하는 것과 같이 DOM의 특정 부분에 대해 주장을 작성하는 경우 해당 구성 요소를 변경하면 테스트가 중단될 위험이 있습니다.

ID를 사용하면 누군가 실수로 ID를 제거하거나 변경할 수 있습니다. 아마도 기능적 목적만을 위한 것이라고 생각하고 작업을 재작업할 때 업데이트했는데, 결국 테스트를 깨뜨렸습니다(나에게 일어난 일입니다!).

또는 자동 생성 여부에 관계없이 일반 선택기를 사용 하는 경우 애플리케이션의 매우 특정한 부분을 테스트 할 때 선택기가 매우 구체적인 경향이 있습니다. 일부 HTML을 중첩하거나 코드에서 약간의 이동을 마치면 시각적으로 보이는 방식을 변경하지 않더라도 결국 해당 테스트를 깨뜨릴 수 있습니다.

사람들이 실제로 사용하고 있는 것을 테스트하기

시각적으로 어떻게 보이는지 테스트하는 것에 대해 말하면 시각적 테스트는 방문자 또는 고객이 실제로 보는 것을 테스트하는 것입니다.

적절하고 의미 있는 HTML을 사용한다고 해서 자동으로 프로젝트를 사용할 수 있게 만드는 것은 아닙니다. z-index와 같은 작은 CSS 변경으로 사용성과 모양이 완전히 바뀔 수 있습니다.

스크린샷을 캡처하고 사용자 흐름의 상호 작용을 통해 응용 프로그램의 실제 상태를 비교함으로써 응용 프로그램이 기능적으로 작동하는지 확인하고 자동화 로봇 이상에서 사용할 수 있는지 확인할 수 있습니다.

추천 자료 : 대규모 프로젝트에서 CSS Z-Index 관리하기

테스트할 생각을 하지 않은 것들 테스트하기

또한 테스트할 생각조차 하지 않은 애플리케이션의 다양한 부분을 다루고 있습니다.

스위트에 있는 테스트 목록을 고려하십시오. 이전에 버그에 부딪쳤기 때문에 작성하거나 작성했다고 생각한 테스트 목록입니다. 나머지 응용 프로그램은 어떻습니까?

이 스크린샷은 다른 테스트에 포함되지 않았을 수 있는 더 자세한 내용과 컨텍스트를 캡처합니다.

시각적 테스트에서 다루지 않는 것은 무엇입니까?

그러나 시각적 테스트는 전체 테스트 제품군을 대체하는 최종 솔루션이 아닙니다. 다른 유형의 테스트와 마찬가지로 공존해야 하며 다른 테스트의 공백을 채우고 궁극적으로 더 의미 있는 범위를 제공해야 합니다.

데이터 기반 비즈니스 로직 테스트

시각적 테스트를 진행하면서 누군가 장바구니에 항목을 추가할 때 수학이 확인하지만 온라인 상점이 더 다양할 수 있는지 확인하는 것과 같은 비즈니스 로직의 일부 측면을 캡처할 수 있습니다. 하나의 제품보다

다양한 할인이 해당 합계에 미치는 영향과 같은 다양한 사용 사례를 캡처하고 있는지 확인하면서 단위 테스트로 복잡한 비즈니스 로직을 캡처하는 것은 여전히 ​​중요합니다.

포괄적인 API 테스트

API를 다룰 때 시각적 테스트를 통합 테스트와 같이 생각할 수 있습니다. 브라우저와 상호 작용할 때 요청 논리가 예상대로 작동하는지 테스트할 수 있습니다. 그러나 해당 API가 작동하는 방식에 대한 포괄적인 보기를 제공하지 않습니다.

비즈니스 로직과 마찬가지로 API는 단위 테스트 또는 상태 확인과 같이 예상대로 작동하는지 확인하는 일련의 테스트를 통해 지원되어야 합니다.

시각적 테스트 시작하기

우리 벨트의 또 다른 도구인 시각적 테스트는 애플리케이션에 대한 높은 수준의 품질을 유지하는 데 도움이 되는 또 다른 수준의 적용 범위를 제공하는 데 실제로 도움이 될 수 있지만 어디서부터 시작해야 할까요?

개발 수명 주기에 맞추기

시각적 테스트는 모든 이해 관계자의 목표를 달성하는 데 도움이 되므로 개발 수명 주기의 모든 부분에 실제로 적합할 수 있습니다.

예를 들어, 전통적으로 테스트는 코드가 의도한 대로 작동하는지 검증하는 데만 사용되지만 디자인 전달 및 UX 협업을 위해 시각적 테스트를 사용할 수도 있습니다. 팀의 디자이너는 목업을 기준선으로 연결하고 실제 경험을 비교하는 데 쉽게 사용할 수 있습니다.

그러나 코드 관점에서 시각적 테스트는 풀 요청에 대한 검사 실행, 배포 전 스테이징 환경, 배포 후 프로덕션이 양호한지 확인하는 것과 같은 자동화된 환경에서 번창할 수 있습니다.

cron에서 시각적 테스트를 실행하여 일반적으로 불안정하고 애플리케이션의 상태를 제대로 알려주지 않는 상태 확인 합성 이벤트를 대체할 수도 있습니다.

운 좋게도 사용하는 서비스와 해당 서비스를 사용하기 위한 통합 지점에 대한 많은 옵션이 있습니다.

시각적 테스트에 사용 가능한 솔루션

앞으로 나아갈 솔루션을 결정하는 것은 테스트를 실행하는 데 사용할 라이브러리나 서비스를 선택하는 것에 달려 있습니다. 앞에서 다룬 것처럼 가장 큰 차별화 요소는 이러한 서비스가 제공하는 시각적 테스트 유형입니다.

많은 플랫폼에서 픽셀별 시각적 테스트를 사용하여 검사를 수행하고 있습니다. 여기에는 두 스크린샷 간의 변경 사항을 표시하는 Percy 및 Chromatic과 같은 도구가 포함됩니다.

그런 다음 Applitools가 현재 해당 기능을 제공하는 유일한 서비스인 AI 기반 시각적 테스트가 있습니다. 단순히 이미지를 픽셀 단위로 확인하는 대신 Applitools는 비정상적인 테스트나 오탐을 피하여 이미지를 지능적으로 비교하여 의미 있는 변경 감지를 제공합니다.

솔루션에 관계없이 처음부터 시작하든 기존 테스트 프레임워크에 추가하든 간에 궁극적으로 솔루션을 개발 환경에 통합해야 합니다.

시각적 테스트 통합

선택한 시각적 테스트 플랫폼을 통합할 때 처음부터 시작하거나 기존 테스트 프레임워크에 통합하는 더 쉬운 방법을 선택할 수 있습니다. Applitools와 같은 도구를 사용하면 이를 쉽게 수행할 수 있으며 지원되는 다양한 SDK를 통해 기존 워크플로로 쉽게 이동할 수 있습니다.

이것의 좋은 예는 이미 Cypress를 설정하여 실행하고 있는 경우입니다.

 it('should log into the application', () => { cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.get('h1').contains('Dashboard'); });

이미 프로그래밍 방식의 테스트를 수행하고 있다면 시각적 테스트를 레이어링하여 다른 레이어를 제공할 수 있습니다.

 it('should log into the application', () => { cy.eyesOpen({ appName: 'My App', testName: 'Login' }); cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.eyesCheckWindow(); cy.eyesClose(); });

또한 일부 SDK를 사용하면 훨씬 더 쉬워집니다. 이미 Storybook 라이브러리를 실행 중인 경우 npm으로 패키지를 설치하고 간단한 명령을 실행하기만 하면 모든 구성 요소를 완벽하게 다룰 수 있습니다.

 npm install @applitools/eyes-storybook --save-dev npx eyes-storybook

궁극적으로 가장 큰 질문은 사용하려는 테스트 프레임워크와 사용하려는 서비스가 해당 프레임워크를 지원하는지 여부입니다.

시각적 테스트의 창의적 사용

애플리케이션에 대한 다른 수준의 테스트 범위를 얻는 것 외에도 시각적 테스트를 활용할 수 있는 다양한 다른 방법이 있습니다.

• 가동 시간 모니터링
  취약한 합성 이벤트로 일반적인 가동 시간 모니터링 대신 의미 있는 시각적 테스트를 정기적으로 실행합니다.
• 디자인/UX 협업
  핸드오프에서 사용성 문제에 이르기까지 시각적 테스트를 사용하여 전체 팀이 협업할 수 있는 매체를 제공합니다.
• 접근성 테스트
  애플리케이션의 접근성을 제한할 수 있는 주요 문제를 캡처합니다.
• 과거 스냅샷
  주기적으로 시각적 테스트를 실행하면 스냅샷을 캡처하는 데 도움이 되며 프로젝트의 이전 상태를 쉽게 참조할 수 있습니다.
• 현지화 테스트
  AI 기반 시각적 테스트를 통해 콘텐츠 변경 사항을 감지할 수 있으므로 언어에 관계없이 모든 것이 예상대로 보이고 작동하는지 확인할 수 있습니다. 보너스: 주어진 언어의 다른 버전을 비교하려고 할 때 오버헤드를 줄일 수 있습니다.

테스트에 시각적 요소를 추가하면 앱의 높은 수준의 품질을 유지하기 위한 의미 있는 방법을 추가할 수 있는 더 많은 옵션을 얻을 수 있습니다.