실제 테스트 접근 방식이 코딩 프로세스의 속도를 높이는 방법

실제 테스트 접근 방식이 코딩 프로세스의 속도를 높이는 방법

테스트 케이스로 코드를 커버하고 테스트 없이 동일한 기능을 실제로 더 빠르게 제공하는가? 그것이 어떻게 가능한가요? 그렇습니다. 소프트웨어 엔지니어로서 제 경력에서 가장 좋은 경험이었습니다.

저희 팀과 저는 최근에 비교적 짧은 시간에 PoC를 몇 개 만들었고, 그것은 라이브 이벤트에 사용되었습니다. 좋아, 하지만 그건 별로 특별한 게 아니야. 이제 흥미로운 부분이 있습니다. 라이브 이벤트 동안 고객이 시스템을 사용하는 동시에 QA 없이 새로운 변경 사항을 포함한 백엔드 프로덕션 릴리즈를 수십 건 실시했습니다. 그리고 매번 문제가 발생하지 않을 것이라고 확신했습니다.

어떻게 이런 일이 가능할까요? 모든 기능이 적절한 테스트 케이스로 적용되었습니다. 그럼 전에 적절한 테스트를 준비했던 훌륭한 QA를 가지고 계신가요? 우리는 실제로 훌륭한 QA를 가지고 있지만, 이번에는 테스트 사례 준비에 참여하지 않았습니다. 아, 그럼 행사 전에 충분한 시간과 시험 범위 작업을 할 수 있었군요? 아니요, 서둘러서 솔루션에서 많은 부분을 잘라내야 했고, 사실, 이제 우리는 품질 기준에 맞지 않는 코드를 수정하기 위해 행사 후 며칠을 더 보내야 합니다.

언급했듯이, 쓰기 시험은 우리에게 어떤 여분의 시간도 요구하지 않습니다. 핵심은 올바른 테스트를 작성하고 코드를 수동으로 테스트하지 않는 것입니다.

테스트에 대한 일반적인 오해

자, 그럼 어떻게 해야 할까요?

그것은 소프트웨어 개발과 관련하여 내가 가장 좋아하는 인용구 중 하나이다.

내가 왜 시험을 쳐야 하지? 그건 기본이고, 여러분이 이미 알고 있기를 바랍니다.

왜 그렇게 많지 않은가? 더 많은 테스트를 작성할수록 나중에 더 많은 시간을 유지해야 하기 때문입니다. 애초에 구현은 말할 것도 없습니다. 게으름은 미덕이다!

왜 대부분 통합인가? 그것은 덜 명백하고, 모든 사람이 동의하는 것은 아니다. 그것은 유명한 테스트 피라미드의 대안인 테스트 다이아몬드 아이디어에서 비롯되었습니다. 테스트에는 세 가지 기본 레벨이 있습니다.

통합 테스트는 기본적으로 안정성과 실행 속도를 절충한 것입니다. 또한 일반적으로 일부 단위가 지정된 코드 구조를 설계할 필요가 없기 때문에 통합 테스트를 설계하는 것이 단위 1 테스트보다 훨씬 쉽습니다.

만약 당신이 그것에 대해 더 배우고 싶다면, 당신은 위대한 켄트 C를 볼 수 있다. Dodds post - 프런트엔드 컨텍스트에서 자세히 설명합니다.

비용은 얼마입니까?

내 프로세스: 예

여기에 있는 모든 샘플 코드는 노드에 작성됩니다.JS - 하지만 당신의 기술이 아니더라도 낙담하지 마세요. 이 접근 방식은 프런트엔드 및 백엔드를 포함한 모든 기술에 보편적이며, 저와 다른 툴을 사용해야 합니다.

1. 고객 인터페이스 설계 및 확인

일반적으로 API 형식을 사용하는 백엔드 응용 프로그램의 경우. 모든 문서는 클라이언트 측과 서버 측 모두에서 사용할 수 있습니다.

2. 시험사례 설명

API가 확인된 후, 나는 모든 (또는 대부분의) 사용 사례를 파악하고 그에 대한 테스트 설명을 작성하려고 한다.

3. 첫 번째 테스트 케이스를 작성하세요.

이것은 통합 테스트입니다. 이런 경우, 저는 모든 것을 조롱하려 하지 않고, 많은 것들을 더 쉽게 만듭니다. 예를 들어, 데이터베이스를 사용할 수 있습니다. NodeJS 통합/API 수준 테스트의 경우 슈퍼테스트를 권장합니다.

또한 몇 가지 준비가 필요하지만 걱정하지 마십시오. 일반적으로 많은 테스트 사례에서 공통적이기 때문에 코드를 작성하는 데는 한 번만 시간이 걸립니다.

4. 첫 번째 테스트 사례를 통과하기 위한 코드를 작성합니다.

구현 세부사항은 여기에 관련이 없으므로 샘플 코드를 생략하겠습니다.

경우에 따라 비즈니스 논리에서 보다 복잡한 특정 통합 테스트를 통과해야 하는 경우 이 시점에서 일부 단위 테스트를 작성하는 것도 좋습니다. 제 접근 방식도 마찬가지입니다. 먼저, 유닛의 공용 API를 설계하고, 사용 사례를 설명하고, 첫 번째 테스트 사례를 구현한 다음, 코드를 작성하십시오. 순수 TDD.

논리가 매우 표준적이고 몇 가지 코드를 구현하여 문제 없이 통합 테스트를 통과할 수 있다면 단위 테스트를 건너뛰십시오. 여러분은 언제 그것들이 정말 필요할지 알게 될 거예요.

5. 코드를 커밋하고 푸시합니다.

그것은 조금 더 일찍/나중에 일어날 수 있지만, 일반적으로 원자 커밋을 하는 것은 정말 좋은 관행이다. Push는 일부 자동 배포를 스테이징 환경에 트리거하고 내 피어는 이미 완료된 부품을 사용할 수 있습니다.

코드가 스테이징 환경에서도 작동하지 않는 경우 기능 플래그 뒤에 숨깁니다.

6. 다 될 때까지 반복하세요.

기능이 준비되면 대개 이미 배포된 애플리케이션에서 실행되는 몇 가지 연기 및 성능 테스트를 준비합니다. 조직에서 QA의 책임일 수 있습니다. 그렇지 않고 연기나 성능 테스트를 작성하지 않으신다면 그렇게 해 보시길 권해드립니다.

요즘에는 k6.io 같은 개발자에게 친숙한 도구들이 있습니다. 이것은 성능 평가 도구입니다. 테스트 케이스는 JS로 작성되어 있습니다. 실제로 배포 후 API를 스모크 테스트하거나 프런트엔드 애플리케이션을 포함한 E2E 테스트를 위한 Cypress에도 사용합니다.

7. 피드백을 기다립니다.

피드백은 동료(API, QA, PM을 사용하는 다른 개발자), 클라이언트 또는 일부 자동화된 보고 툴을 통해 얻을 수 있습니다. 어디서 왔든 간에, 동일한 프로세스를 진행하며 테스트 케이스와 코드 모두 이전에 누락된 케이스를 포함하도록 합니다.

기술적인 관점에서 모든 것이 괜찮다면, 여러분은 생방송으로 갈 수 있습니다!

요약

단순히 "일부" 테스트나 테스트 범위의 x%가 아닌, 앱이 실제로 작동하는지 확인하는 테스트에 집중하면 워크플로우의 성능이 얼마나 강력하고 강력한지 믿을 수 없습니다. 나에게 가장 큰 발견은 그것이 정말 간단해질 수 있다는 것이다. 필요한 것은 올바른 도구와 올바른 마음가짐 뿐입니다.

읽어주셔서 감사합니다. 만약 여러분이 이런 식으로 일하려고 시도하지 않았다면, 저는 여러분이 용기를 얻기를 바랍니다. 자유롭게 의견이나 질문을 남겨주세요!

from http://top-poster.tistory.com/35 by ccl(A) rewrite - 2021-09-28 05:26:41