How Guru’s Engineers Use Cypress for Better Burn Testing

번 테스트를 처리할 더 나은 방법이 필요하신가요? 우리의 두 프론트 엔드 엔지니어가 Cypress를 사용하여 QA 처리 방식을 개선할 수 있는 방법을 찾았습니다.
Table of Contents

우리는 Guru에서 지식 공유에 전념하고 있으며, 새로운 유용한 정보를 발견했을 때 세상과 공유하고 싶습니다! 우리의 엔지니어링 팀은 테스트 및 QA 프로세스에서 Cypress를 사용합니다. 그들은 더 나은 번 테스트를 실행할 수 있는 새로운 방법을 발견했으며, 다른 엔지니어와 테스터들과 개선된 프로세스를 공유하고 싶어합니다.

지난 1년 동안 우리는 테스트 범위를 확대하는 데 집중해 왔습니다. 특별히, 코드 업데이트를 진행할 때 제품의 다양한 흐름이 올바르게 작동하는지 확인하는 종단 간 테스트에 집중하고 있습니다. 이러한 종류의 테스트를 위해 우리는 사용자 행동을 모방하는 Cypress라는 도구를 활용합니다. 이 테스트 스위트는 새로운 코드가 UI에서 문제를 일으키지 않도록 모든 풀 리퀘스트에서 실행됩니다. 또한, Cypress 스위트가 프로덕션 브랜치에서 실패할 경우 릴리스를 막고 싶습니다.

Ryan%20and%20Jack%20Talk%20About%20Cypress.png

전통적인 테스트에서 우리가 찾는 것

우리가 다룬 한 가지 문제는 일부 테스트가 실패하는 것을 보는 것이지만, 이는 UI나 코드와 관련된 이유가 아닙니다. 그렇다면 Cypress는 이러한 경우에 어떻게 도움을 줄까요? 우리는 Cypress를 정의할 수 있는 사용자 행동으로 작동하게 합니다. Cypress가 실패를 알려줄 수 있는 여러 변수가 있지만, 사용자의 관점에서는 아무 문제가 없어 보입니다.

예를 들어, "이 웹앱의 이 부분으로 이동하여 새로운 Guru 카드를 추가하고, 생성 후 상태를 기대합니다"라는 테스트가 있을 수 있습니다. 카드를 생성하는 로딩 상태가 너무 길어지고 Cypress가 생성 후 상태를 찾기 시작하면 이 테스트는 실패할 수 있습니다(대부분의 경우, 이 테스트는 통과하지만). 한 번의 풀 리퀘스트에서 통과하면, 우리는 때때로 불안정할 수 있는 코드를 병합할 수 있습니다. 하지만 그것이 일어나지 않는지 알 수 없습니다. 통과한 테스트는 코드가 올바르다는 보장이 아닙니다.

이러한 상황은 우리의 테스트 범위의 신뢰성을 낮춥니다. 그 결과, 배포 파이프라인에서 테스트 실패가 발생하면 UI 문제인지 테스트 문제인지 확인해야 합니다. 이를 해결하기 위해 우리는 프로덕션 코드 브랜치에 가기 전에 테스트가 불안정할 수 있는지 감지할 방법을 생각하기 시작했습니다.

번 테스트가 어떻게 도움이 되는지

Guru_Collage_Image-Library-23.png

번 테스트가 시작되었습니다. 번 테스트는 더 엄격하거나 극단적인 조건에서 무언가를 테스트하기 위해 사용되는 프로세스입니다. 방법이나 특정 테스트 영역에 따라 스트레스 테스트 또는 부하 테스트라고도 합니다.

Guru에서는 Cypress 스위트의 일환으로 모든 새로운 테스트나 수정된 테스트에 대한 번 테스트를 사용합니다. 이 테스트들이 병합되기 전에, 우리는 연속해서 여러 번 실행하고 모두 통과해야 다음 단계로 나아갈 수 있습니다.

이 단계는 전체 Cypress 테스트 스위트를 실행하기 바로 직전에 발생합니다. 이 순서의 장점은 번 테스트 단계에서 실패가 발생하면, 전체 검사를 조기에 실패로 표시할 수 있다는 것입니다. 나머지 스위트를 건너뛰면 시간을 절약하고 새로운 테스트가 신뢰할 수 있고 오류가 없는 만큼 간편하게 만드는 데 필요한 사이클 수를 줄일 수 있습니다.

우리가 찾고 있는 파일을 찾기 위해, 우리는 현재 브랜치에서 git diff를 사용하고 출력을 cypress-repeat라는 도구의 매개변수로 제공하여 지정된 횟수만큼 테스트를 실행할 수 있도록 하며, 이는 효과적으로 우리의 종단 간 테스트 스위트의 단계로 번 테스트를 추가합니다.

결과

테스트 계획에 이 조정을 추가한 것은 꽤 긍정적인 결과를 가져왔습니다. 우리에게는 번 테스트를 추가하면 불안정한 테스트를 찾는 데 걸리는 시간을 최대 30분까지 줄일 수 있습니다.  이것은 또한 새로운 기능을 추가하는 회전 시간을 개선합니다. 새로 추가된 테스트가 먼저 실행되므로, 우리는 나머지 빌드 프로세스를 계속 진행하기 전에 안정성을 확인할 수 있습니다.

전반적으로 우리의 테스트 프로세스를 더욱 효율적이고 견고하게 만드는 데 계속 집중함으로써 전체 엔지니어링 팀의 새로운 기능을 신속하게 배포할 수 있는 자신감을 높입니다. 우리는 버그를 더 빨리 수정하고 모든 코드베이스에서 작업하는 것을 더 쉽게 만들고 있습니다. 이 게시물이 다른 Cypress 사용자가 더 나은 테스트를 만들고 전체 팀이 더 효율적으로 구축하는 데 도움이 되기를 바랍니다.

우리는 Guru에서 지식 공유에 전념하고 있으며, 새로운 유용한 정보를 발견했을 때 세상과 공유하고 싶습니다! 우리의 엔지니어링 팀은 테스트 및 QA 프로세스에서 Cypress를 사용합니다. 그들은 더 나은 번 테스트를 실행할 수 있는 새로운 방법을 발견했으며, 다른 엔지니어와 테스터들과 개선된 프로세스를 공유하고 싶어합니다.

지난 1년 동안 우리는 테스트 범위를 확대하는 데 집중해 왔습니다. 특별히, 코드 업데이트를 진행할 때 제품의 다양한 흐름이 올바르게 작동하는지 확인하는 종단 간 테스트에 집중하고 있습니다. 이러한 종류의 테스트를 위해 우리는 사용자 행동을 모방하는 Cypress라는 도구를 활용합니다. 이 테스트 스위트는 새로운 코드가 UI에서 문제를 일으키지 않도록 모든 풀 리퀘스트에서 실행됩니다. 또한, Cypress 스위트가 프로덕션 브랜치에서 실패할 경우 릴리스를 막고 싶습니다.

Ryan%20and%20Jack%20Talk%20About%20Cypress.png

전통적인 테스트에서 우리가 찾는 것

우리가 다룬 한 가지 문제는 일부 테스트가 실패하는 것을 보는 것이지만, 이는 UI나 코드와 관련된 이유가 아닙니다. 그렇다면 Cypress는 이러한 경우에 어떻게 도움을 줄까요? 우리는 Cypress를 정의할 수 있는 사용자 행동으로 작동하게 합니다. Cypress가 실패를 알려줄 수 있는 여러 변수가 있지만, 사용자의 관점에서는 아무 문제가 없어 보입니다.

예를 들어, "이 웹앱의 이 부분으로 이동하여 새로운 Guru 카드를 추가하고, 생성 후 상태를 기대합니다"라는 테스트가 있을 수 있습니다. 카드를 생성하는 로딩 상태가 너무 길어지고 Cypress가 생성 후 상태를 찾기 시작하면 이 테스트는 실패할 수 있습니다(대부분의 경우, 이 테스트는 통과하지만). 한 번의 풀 리퀘스트에서 통과하면, 우리는 때때로 불안정할 수 있는 코드를 병합할 수 있습니다. 하지만 그것이 일어나지 않는지 알 수 없습니다. 통과한 테스트는 코드가 올바르다는 보장이 아닙니다.

이러한 상황은 우리의 테스트 범위의 신뢰성을 낮춥니다. 그 결과, 배포 파이프라인에서 테스트 실패가 발생하면 UI 문제인지 테스트 문제인지 확인해야 합니다. 이를 해결하기 위해 우리는 프로덕션 코드 브랜치에 가기 전에 테스트가 불안정할 수 있는지 감지할 방법을 생각하기 시작했습니다.

번 테스트가 어떻게 도움이 되는지

Guru_Collage_Image-Library-23.png

번 테스트가 시작되었습니다. 번 테스트는 더 엄격하거나 극단적인 조건에서 무언가를 테스트하기 위해 사용되는 프로세스입니다. 방법이나 특정 테스트 영역에 따라 스트레스 테스트 또는 부하 테스트라고도 합니다.

Guru에서는 Cypress 스위트의 일환으로 모든 새로운 테스트나 수정된 테스트에 대한 번 테스트를 사용합니다. 이 테스트들이 병합되기 전에, 우리는 연속해서 여러 번 실행하고 모두 통과해야 다음 단계로 나아갈 수 있습니다.

이 단계는 전체 Cypress 테스트 스위트를 실행하기 바로 직전에 발생합니다. 이 순서의 장점은 번 테스트 단계에서 실패가 발생하면, 전체 검사를 조기에 실패로 표시할 수 있다는 것입니다. 나머지 스위트를 건너뛰면 시간을 절약하고 새로운 테스트가 신뢰할 수 있고 오류가 없는 만큼 간편하게 만드는 데 필요한 사이클 수를 줄일 수 있습니다.

우리가 찾고 있는 파일을 찾기 위해, 우리는 현재 브랜치에서 git diff를 사용하고 출력을 cypress-repeat라는 도구의 매개변수로 제공하여 지정된 횟수만큼 테스트를 실행할 수 있도록 하며, 이는 효과적으로 우리의 종단 간 테스트 스위트의 단계로 번 테스트를 추가합니다.

결과

테스트 계획에 이 조정을 추가한 것은 꽤 긍정적인 결과를 가져왔습니다. 우리에게는 번 테스트를 추가하면 불안정한 테스트를 찾는 데 걸리는 시간을 최대 30분까지 줄일 수 있습니다.  이것은 또한 새로운 기능을 추가하는 회전 시간을 개선합니다. 새로 추가된 테스트가 먼저 실행되므로, 우리는 나머지 빌드 프로세스를 계속 진행하기 전에 안정성을 확인할 수 있습니다.

전반적으로 우리의 테스트 프로세스를 더욱 효율적이고 견고하게 만드는 데 계속 집중함으로써 전체 엔지니어링 팀의 새로운 기능을 신속하게 배포할 수 있는 자신감을 높입니다. 우리는 버그를 더 빨리 수정하고 모든 코드베이스에서 작업하는 것을 더 쉽게 만들고 있습니다. 이 게시물이 다른 Cypress 사용자가 더 나은 테스트를 만들고 전체 팀이 더 효율적으로 구축하는 데 도움이 되기를 바랍니다.

Experience the power of the Guru platform firsthand – take our interactive product tour
투어 신청