ThoughtWorks Radar 4についての考え

ThoughtWorks 2024 Radar がリリースされました (ワンクリックで PDF をダウンロードでき、面倒なサインアップは必要ありません)。以下に 2 つのことを示します:

1. コンポーネントテストに関して混乱している点をカバーしています
2. 「評価」から「採用」に移行する理由を調査または解明するための素晴らしい新しいツール

注目すべきクールな新機能について知りたいだけなら、私のコンポーネント テストに関する暴言は飛ばしてください。

コンポーネントのテスト: 導入

この「Adopt」についてはたくさんの質問があります。私の現在の雇用主は、チームがコンポーネント テストを行うのを支援することに多くのトレーニングとツールを投資しており、私はそれが大好きです。私が気に入らないのは、誰がそれについて話しているかによって定義が異なる、さらに別のテスト手法です。

私が実際に目にしたいくつかの定義を、私がそれらについて学んだ時系列順に概説します。ThoughtWorks の定義が最後であると_思う_と思います:

• React コンポーネントを単独でテストするのに役立つストーリーブック。コンポーネント フレームワークの作成者に多用されています
• Cypress のコンポーネント テストを使用した、隔離されたブラウザ環境でのコンポーネントのテスト
• Cypress Whitebox Testing の私の最新の定義は、すべての外部 I/O 呼び出し (fetch/xhr、JSON の読み込み、localstorage の読み取りなど) が cy.intercepted またはスタブ化/モック化されることを意味します

どれも同じではありません。上記の文脈におけるコンポーネントとは、ある種の UI コンポーネント、または他の多くのコンポーネント、コード、CSS を構成する のようなものを意味します。 「一種の」と言ったのは、Storybook と Cypress では、JSDom のような偽のブラウザではなく、本物のブラウザを使用しているからです。この文脈において、実際のブラウザを使用すると、特に単体テストではなく受け入れテストに関する多くの問題が発生する可能性があると私は考えています。私は彼らが引用していることとは逆の経験をしています。Cypress/Playwright を非常に高速にすることができます (it.only のようなものを使用し、重いスタブを作成し、特定のユーザー フローをテストするために UI をより分離するように設計します)。ユーザーにとって、アプリケーションが動作することに対する私の信頼は非常に高いです。 Elm の型指定システムを考慮すると、これは Elm コードに競合状態がないことを検証できる主な方法であり、この技術を使用すると受け入れテストの作成により多くの時間を費やすことができるため、優れています。サイプレスのホワイトボックス テストは不安定ではありません。彼らは決定論的で、だからこそ私たちはみんな彼らを愛しているのです。

ただし、デバッグが難しい場合があることは承知しています。 「ブラウザーを使用している」からといって、ブレークポイント、デバッガーのキーワード、コンパイルされたソース コード、ネットワーク呼び出しに関する洞察、およびさまざまなログをすべて自由に利用できるにもかかわらず、なぜ何かが壊れたのかについての広範な洞察が常に得られるわけではありません (冗談ではありません)。 、これらすべてを行っても、「おい、なぜこれがうまくいかないんだ…」という気分になる可能性があります)

次に、ThoughtWorks と Cypress の両方が「エンドツーエンド」テストを挙げています。ここでの定義も曖昧です。私が見た定義をいくつか紹介します:

• Dave Farley 氏の e2e の見解。これは基本的に「すべてのもの」が連携して機能することを検証しています (初期の All Up テストの推進と混同しないでください)
• Cypress のブラックボックス テストでは、ajax 呼び出しやその他の I/O のスタブ/モックは行わず、単に「サイトとその統合」をテストします
• ThoughtWorks は、Playwright/Cypress/Selenium は主に e2e ツールであり、Storybook を少し反映する Cypress コンポーネント テスト機能を除いて、受け入れテスト ツールであると考えているようです
• ヒレル・ウェインも彼らをそう呼んでいます

最後に、私は React のコンポーネント テスト拡張機能を一度も楽しんだことがありません。これらはモック/副作用が大量に蔓延しており、「コンポーネントが正しくレンダリングされている」ことを検証するために JQuery スキルを習得することを強く推奨していますが、それは必ずしも「正しく動作している」ことと同じではなく、抽象化を破って React かどうかをテストしているように感じられます。働いています。代わりに、React、Angular、Elm のいずれであっても、コードが動作することをテストし、主に純粋なコンポーネントを作成し、受け入れテスト (Cypress または Playwright) で検証する「スマート コンポーネント」(例: 副作用のあるコンポーネント) をテストすることが大切だと常に感じてきました。 .

JavaScript Web 開発者にはさまざまな意見があり、言葉の定義もさまざまです。それは一般的には問題ありませんが、ThoughtWorks をヤングアダルトのヒーローとして持っていた人として、Martin Fowler やその他の ThoughtWorks の著作を学ぶべき素晴らしい推奨事項として常に推奨しており、イベントはいつか彼らと仕事をしたいと考えていました…なぜこの完全に逆の視点が重要であるかがわかります。私に信仰の危機を与えています。

それで:

1. さまざまな形でのコンポーネントのテストに同意します
2. JSDom に反対し、選択した単体テスト言語で「コンポーネントのリスト項目 2 に内部テキストが 'cow' の太字タグがあることを主張します。
」

ちなみに、上記の内容はさまざまな言語で微妙に異なります。たとえば、Angular および Lit/WebComponents は、パブリック コンポーネント変数への if および switch バインディングを超えるロジックを持つテンプレートを避けた場合、React や他のフレームワークが公開している現在のフレームワークと比較して、単体テストと副作用のアサートがはるかに簡単になります。ただし、Angular および一部の WebComponent フレームワークは、それ自体デバッグが非常に困難な詳細なセットアップ コードを必要としますが、React/Elm はその逆です。

また、これらの PDF を作成するのは大変な作業であることはわかっていますし、テクノロジーに関するあらゆる内容を要約しようとしているので、膨大な文脈が欠けているだけだと思います。

継続的展開: 導入

私の CEO が年次講演でこれについて話しているのを見るのは素晴らしいブーメランでした。 Minimum CD を試みるイベントが人々にとって大きな変化になる可能性があることはわかっていますが、これは私が仕事の中で見た中で最良の方法なので、Adopt で明らかに呼び掛けられるのは嬉しいことです。

ゴーレム：評価する

Zio の作成者が、Golem と呼ばれる、サービスとしてクラッシュできないこのステート マシンの作成に携わったとき、私はとても興奮しました。 OCAML スタイルの FP 健全型言語である Grain がサポートされていたので、さらに興奮しました。未だに「すべてが AWS である」という渦に囚われていると感じているため、プレイする時間やインスピレーションをまったく見つけることができませんでした。はい、実稼働環境で CloudFlare を試したり使用したりしましたが、AWS Step Functions ファンとして、これはクールなアイデアのように思えました。 Grain はもうオプションではないようなので、週末のうちに TypeScript をもう一度試してみます。

ブルーノ:養子にする

これらの REST クライアントの多くは、VSCode に組み込まれているものもありますが、内部 API の詳細をサーバー上でホストしたり、詳細を他の場所に投稿したりするため、さまざまな企業によってブロックされています。 Postman や Insomnia などは、必要ないと主張しているにもかかわらず、サブスクリプションを要求し始めており、事態はさらに悪化しています。そのため、データを共有しない同様のツールを見つけようという動きが非常に強くなっています。 Bruno は、ThunderClient の使用が許可されなくなったため、チェックアウトする必要があるものの 1 つです。

視覚的な回帰テスト ツール: 導入する

CSS がアプリケーション全体を破壊する可能性があるさまざまな方法があり、それを防ぐ単体テストや受け入れテストを簡単に行う方法はありません。私は初期の React スナップショット ツールに本当に苦労し、多数の誤検知を考慮すると小規模なサイトでは ROI が得られないと感じました。 Applit や BackstopJS などのツールは、サイトの外観や動作が正常であることを検証するためのサービスを含む多数のツールの一部です。多くの場合、パイプライン内の受け入れテストの後、またはそれと同時に実行されます。 Applit ツールの使用経験は 5 分程度ですが、Backstop をぜひチェックしてみたいと思っています。

GitButler: 評価する

私が最も興奮しているのは GitButler です。トランクベースの開発を経験し、「PR に対する抽象化」を中心としたさまざまなツールの状態と放棄に失望し、プル リクエストを嫌っていた人間として、GitButler は、PR の PR を作成するというコンテキストに切り替わって正気を取り戻してくれそうです。

三瀬：評価する

Mise はちょっと奇妙です。Node.js のバージョンを管理するための nvm や、Python プロジェクトを管理/実行するための Pipenv で問題が発生したことがないからです。興味があるので、これを試してみて、何が問題なのかを確認してください。

モクーン: 評価する

私はモックが嫌いです。私は副作用が許容される言語を使用し、Pure Core や Imperative Shell に従わない開発者と一緒に作業することが多いです。したがって、敵についてさらに学び、それに対処する方法を学ぶためにできることはすべて時間を有効に活用することです。Mockoon もそのような模擬クリエイターの 1 つです。

Rspack: 評価する

ありがたいことに、Webpack と統合する必要があったことはありません。残念なことに、私は Webpack と「他の人々」の統合によって何度も影響を受けてきました。ヴィテは新鮮な空気の息吹でした。超高速で、うまくいきました。したがって、スピードに関する別の候補者について聞くのは興味深いことです。 Vite が優勝したのは、その驚くべきスピードだけでなく、素晴らしい開発者エクスペリエンスが理由でした。Rspack で何が起こるか見てください。

ゼッド: 評価する

VSCode が私を支配していたにもかかわらず、Zed IDE を試すことに興奮しました。それは、組み込みのペア プログラミング、超高速のスピード、そして Roc lang の作成者がチームに参加したためです。

Pkl: トライアル

私が初めて Pkl に興味を持ったのは、ダルトラフの幻滅段階 (ダルはクールですが、人間は難しいです) のとき、James Ward によってでした。これは、YAML/JSON 設定ファイルをより安全にコンパイルするのに十分な型を備えた言語であるように見えました。 YAML/JSON の設定ミスで本番環境が中断されるのは何度も経験したので、それらの問題をコンパイルして解決する方法を検討し始めました。Dhall は大いに助けてくれましたが、学習曲線とコンパイラ エラーを乗り越えるのは過酷で、仲間内で興奮することはありませんでした。 。 Pkl がここで道路を進入できることを願っています。

結論

私は退屈だと思う大量の新規および既存のテクノロジー (LLM、インフラ、データ サイエンス) を無視しているため、必ず PDF をご自身でダウンロードしてください。

以上がThoughtWorks Radar 4についての考えの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。