ThoughtWorks Radar 4에 대한 생각

ThoughtWorks 2024 Radar가 출시되었습니다(번거로운 가입 절차 없이 클릭 한 번으로 PDF를 다운로드할 수 있습니다). 아래에는 2가지가 있습니다:

1. 구성 요소 테스트에 대해 헷갈리는 부분을 다룹니다
2. '평가'에서 '채택'으로 전환하는 이유를 조사하거나 파악하기 위한 멋진 새 도구

볼 만한 멋진 새 기능에 대해 알아보고 싶다면 구성요소 테스트에 대한 저의 장황한 말을 건너뛰세요.

구성 요소 테스트: 채택

'입양'에 관해 궁금한 점이 많습니다. 현재 고용주는 팀이 구성요소 테스트를 수행하는 데 도움을 주기 위해 많은 교육과 도구를 투자했는데, 이는 제가 좋아하는 일입니다. 제가 좋아하지 않는 것은 말하는 사람에 따라 정의가 달라지는 또 다른 테스트 기술입니다.

제가 현장에서 본 몇 가지 정의를 배운 시간순으로 설명하겠습니다. 제가 _생각하는_ ThoughtWorks의 정의는 마지막입니다.

• React 구성 요소를 별도로 테스트하는 데 도움이 되는 스토리북으로 구성 요소 프레임워크 작성자에게 많이 활용됩니다
• Cypress의 구성 요소 테스트를 사용하여 격리된 브라우저 환경에서 구성 요소 테스트
• Cypress Whitebox 테스트에 대한 최신 정의는 모든 외부 I/O 호출(가져오기/xhr, JSON 로드, 로컬 저장소 읽기 등)이 cy.intercepted 또는 스텁/모의된다는 의미입니다.

그 어느 것도 똑같지 않습니다. 위 컨텍스트의 구성 요소는 다른 많은 구성 요소, 코드 및 CSS를 구성하는 a 또는 a와 같은 UI 구성 요소를 의미합니다. "일종의"라고 말한 이유는 Storybook과 Cypress에서는 JSDom과 같은 가짜 브라우저가 아닌 실제 브라우저를 사용하기 때문입니다. 이러한 맥락에서 실제 브라우저를 사용하면 특히 단위 테스트가 아닌 승인 테스트와 관련된 많은 문제를 해결할 수 있다고 생각합니다. 나는 그들이 인용하는 것과 정반대의 경험을 가지고 있습니다. Cypress/Playwright를 매우 빠르게 만들 수 있습니다(그것과 같은 것을 사용, 무거운 스텁, 특정 사용자 흐름을 테스트하기 위해 UI를 더 분리되도록 설계). 사용자를 위한 애플리케이션 작동에 대한 자신감은 매우 높습니다. Elm의 타이핑 시스템을 고려하면 이는 Elm 코드에 경합 조건이 없는지 확인할 수 있는 주요 방법이며 해당 기술을 사용하여 승인 테스트를 작성하는 데 더 많은 시간을 할애할 수 있다는 점에서 좋습니다. Cypress 화이트박스 테스트는 불안정하지 않습니다. 결정론적이므로 우리 모두가 좋아합니다.

하지만 디버깅이 어려울 수 있다는 점은 인정합니다. "브라우저"에 있다고 해서 중단점, 디버거 키워드, 컴파일된 소스 코드, 네트워크 호출에 대한 통찰력 및 다양한 로그에도 불구하고 문제가 발생한 이유에 대한 광범위한 통찰력을 항상 제공하는 것은 아닙니다. , 그 모든 것에도 불구하고 여전히 "야, 이거 왜 안 돼..."라고 말할 수 있나요?)

다음으로 ThoughtWorks와 Cypress는 모두 "엔드 투 엔드(end to end)" 테스트를 인용합니다. 여기의 정의도 흐릿합니다. 제가 본 몇 가지 정의는 다음과 같습니다.

• 기본적으로 "모든 것"이 함께 작동하는지 검증하는 Dave Farley의 e2e 테이크(초기 All Up 테스트 추진과 혼동하지 마십시오)
• Ajax 호출 및 기타 I/O를 스텁/모의하지 않고 "사이트 및 해당 통합"만 테스트하는 Cypress의 블랙박스 테스트
• ThoughtWorks에서는 Playwright/Cypress/Selenium이 주로 e2e 도구라고 말하는 것 같습니다. 여기서는 Storybook을 약간 반영하는 Cypress 구성 요소 테스트 기능을 제외하고 승인 테스트 도구로 봅니다.
• Hillel Wayne도 그들을 그렇게 부릅니다.

마지막으로 저는 React의 구성요소 테스트 확장 기능을 즐겨본 적이 없습니다. 그들은 모의/부작용이 심하게 감염되어 있으며 "내 구성 요소가 올바르게 렌더링되고 있습니다"를 검증하기 위해 JQuery 기술을 개발하도록 강력히 권장합니다. 이는 항상 "올바르게 작동"하는 것과 같지 않고 추상화를 깨뜨리고 React가 있는지 테스트하는 것처럼 느껴집니다. 일하고 있습니다. 대신 React, Angular, Elm 등 코드 작동 여부를 테스트하고, 주로 순수한 구성 요소를 만들고, 승인 테스트(Cypress 또는 Playwright)에서 검증한 "스마트 구성 요소"(예: 부작용이 있는 구성 요소)를 테스트하는 것을 항상 느꼈습니다. .

JavaScript 웹 개발자는 다양한 의견을 갖고 있으며 단어에 대한 정의도 다양합니다. 일반적으로 괜찮지만, ThoughtWorks를 청년 후드 영웅으로 삼은 사람으로서 Martin Fowler와 다른 ThoughtWorks의 저작물을 배울 수 있는 훌륭한 권장 사항으로 끊임없이 추천하고 이벤트는 언젠가 그들과 함께 작업하고 싶었습니다… 완전히 반대되는 관점이 왜 나에게 믿음의 위기를 주고 있습니다.

그래서:

1. 다양한 형태의 구성 요소 테스트에 동의합니다
2. JSDom에 동의하지 선택한 단위 테스트 언어에서 "내 구성 요소의 목록 항목 2에 내부 텍스트가 'cow'인 굵은 태그가 있음을 확인"합니다.

위 내용은 다양한 언어로 미묘한 차이가 있습니다. 예를 들어 Angular 및 Lit/WebComponents는 if 이외의 논리가 있는 템플릿을 피하고 공개 구성 요소 변수로 바인딩을 전환하는 경우 현재 프레임워크인 React 및 기타 노출에 비해 단위 테스트 및 부작용 확인이 훨씬 더 쉽습니다. 그러나 Angular 및 일부 WebComponent 프레임워크에는 디버깅하기 매우 어려운 장황한 설정 코드가 필요한 반면, React/Elm은 그 반대입니다.

또한 이러한 PDF를 작성하는 것이 엄청난 노력이라는 것을 알고 있으며 기술 분야의 모든 내용을 요약하려고 하기 때문에 많은 맥락이 누락된 것이라고 확신합니다.

지속적인 배포: 채택

부메랑을 사용하고 CEO가 연례 강연에서 이에 대해 이야기하는 것을 보는 것은 정말 놀라운 일이었습니다. Minimal CD를 시도하는 이벤트가 사람들에게 큰 변화가 될 수 있다는 것을 알고 있지만, 제가 작업하면서 본 것 중 가장 좋은 방법이므로 Adopt에서 분명히 언급되는 것을 보니 정말 좋습니다.

골렘: 평가

Zio 제작자가 Golem이라는 서비스형 충돌 방지 상태 머신을 만드는 데 참여했을 때 정말 기뻤습니다. OCAML 스타일 FP 사운드 형식 언어인 Grain을 지원했기 때문에 더욱 기뻤습니다. 나는 여전히 "모든 것이 AWS이다"라는 소용돌이에 갇혀 있다고 느끼기 때문에 플레이할 시간이나 영감을 결코 찾을 수 없었습니다. 예, 저는 프로덕션에서 CloudFlare를 사용해 본 적이 있지만… AWS Step Functions 팬으로서 이것은 멋진 아이디어처럼 보였습니다. Grain은 더 이상 옵션이 아닌 것 같으므로 이번 주말에 TypeScript를 다시 사용해 보겠습니다.

브루노: 채택하다

VSCode에 내장된 많은 REST 클라이언트는 내부 API 세부 정보를 서버에 호스팅하거나 세부 정보를 다른 위치에 게시하기 때문에 다양한 회사에서 차단되고 있습니다. Postman, Insomnia 등은 구독이 필요하지 않다고 주장함에도 불구하고 구독을 요구하기 시작했는데 이는 상황을 더욱 악화시킬 뿐입니다. 따라서 데이터를 공유하지 않는 유사한 도구를 찾으려는 엄청난 압력이 있습니다. Bruno는 더 이상 ThunderClient를 사용할 수 없기 때문에 확인해야 할 사람입니다.

시각적 회귀 테스트 도구: 채택

CSS가 전체 애플리케이션을 손상시킬 수 있는 방법은 다양하며, 이를 방지하기 위한 단위 테스트나 승인 테스트를 쉽게 수행할 수 있는 방법은 없습니다. 저는 초기 React 스냅샷 도구를 사용하는 데 정말 어려움을 겪었고 수많은 오탐으로 인해 소규모 사이트에는 ROI가 없다고 느꼈습니다. Applit 및 BackstopJS와 같은 도구는 서비스를 포함하여 사이트의 모양과 작동 여부를 확인하는 많은 도구 중 일부입니다. 파이프라인의 승인 테스트 이후 또는 동시에 실행되는 경우가 많습니다. Applit 도구를 5분 정도 사용해 본 경험이 있지만 Backstop을 꼭 확인해 보고 싶습니다.

GitButler: 평가

제가 가장 기대하는 것은 GitButler입니다. 트렁크 기반 개발을 경험한 후 끌어오기 요청을 싫어하고 "PR에 대한 추상화"에 대한 다양한 도구의 상태와 포기에 실망한 사람으로서 GitButler는 PR을 PR로 전환하는 맥락에서 내 정신을 회복할 수 있을 것처럼 보입니다.

미세: 평가하다

Mise는 좀 이상합니다. Node.js 버전 관리를 위한 nvm과 Python 프로젝트 관리/실행을 위한 Pipenv에 문제가 있었던 적이 없기 때문입니다. 궁금해서 한번 시도해 보고 왜 난리인지 살펴보세요.

모쿤: 평가

저는 모의를 싫어합니다. 저는 Side Effect를 허용하는 언어와 Pure Core, Imperative Shell을 따르지 않는 개발자들과 함께 작업하는 경향이 있습니다. 따라서 적에 대해 더 많이 배우고 이를 관리하는 방법을 배우기 위해 할 수 있는 모든 일은 시간을 잘 활용하는 것이며 Mockoon은 이러한 모의 제작자 중 하나입니다.

Rspack: 평가

다행히 Webpack과 통합할 필요가 없었습니다. 불행하게도 저는 _다른 사람들_의 Webpack 통합으로 인해 여러 번 영향을 받았습니다. Vite는 신선한 공기를 마시는 곳이었습니다. 매우 빠르고 효과가 있었습니다. 따라서 속도에 대한 또 다른 경쟁자의 이야기를 듣는 것은 흥미 롭습니다. Vite는 놀라운 속도뿐만 아니라 훌륭한 개발자 경험 때문에 승리했습니다. Rspack을 통해 어떤 일이 일어나는지 확인해 보세요.

제드: 평가

VSCode가 나를 사로잡고 있음에도 불구하고 Zed IDE를 사용하게 되어 기쁩니다. 즉, 내장된 쌍 프로그래밍, 초고속 속도 및 Roc lang 제작자가 팀에 합류했기 때문입니다.

Pkl: ​​평가판

저는 Dhall Trough of Disillusionment 단계(Dhall은 멋지지만 사람은 어렵습니다)에서 James Ward가 처음으로 Pkl을 사용하게 되었습니다. YAML/JSON 구성 파일을 훨씬 더 안전하게 컴파일할 수 있는 충분한 유형을 갖춘 언어인 것처럼 보였습니다. YAML/JSON의 잘못된 구성으로 인해 프로덕션이 중단되는 일이 너무 많아 이러한 문제를 컴파일하는 방법을 찾기 시작했고 Dhall이 많은 도움을 주었지만 학습 곡선과 컴파일러 오류는 해결하기가 너무 힘들고 동료들 사이에서는 결코 흥분하지 않았습니다. . Pkl이 여기에 진출하기를 바랍니다.

결론

저는 지루하다고 생각하는 수많은 신규 및 기존 기술(LLM, 인프라, 데이터 과학)을 무시했지만 다른 사람들은 매력적이라고 ​​생각할 수도 있으므로 PDF를 직접 다운로드하세요.

위 내용은 ThoughtWorks Radar 4에 대한 생각의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!