いらっしゃいませ！ Vuejs Amsterdam Conference 2022 要約シリーズの第 6 部でお会いできてうれしく思います。このシリーズでは、すべての講演の要約を共有します。

私の JSWorld Conference 2022 サマリー シリーズ (4 部構成) は、ここで読むことができます。ここでは、初日のすべての講演をまとめています。私のブログでは、Vue Amsterdam Conference 2022 の以前の講演もご覧いただけます。

(繰り返し) はじめに

2 年半ぶりに JSWorld と Vue Amsterdam Conference が 6 月 1 日から 3 日にかけて Theatre Amsterdam に戻ってきました。私は初めてこの会議に参加する機会がありました。多くのことを学び、多くの素晴らしい人々に出会い、素晴らしい開発者と話し、素晴らしい時間を過ごしました。初日は JSWorld Conference が開催され、2 日目と 3 日目は Vue Amsterdam が開催されました。

会議は素晴らしい講演者の情報でいっぱいで、それぞれが私に貴重なことを教えてくれました。彼らは皆、知識と情報を他の開発者と共有したいと考えていました。それで、それを共有し続け、他の人がそれを使用するのを助けることができれば素晴らしいと思いました.

最初は、いくつかのメモやスライドを共有しようとしましたが、スピーカーが私と共有したものほどではなく、十分ではないと感じました.そこで、私は各スピーチをもう一度見て、深く掘り下げ、検索し、メモを取り、それらをスライドやスピーチ内の正確な言葉と組み合わせて、あなたと共有することにしました。私が彼らから学んだことと同じレベル。

非常に重要なポイント

これらのいくつかの記事で読んだものはすべて、スピーカー自身の努力と時間の結果であり、私はそれらをこれらの記事に変えることができるように学ぼうとしました.これらの記事に書かれている文章の多くでさえ、彼らが言ったことやスライドに書いたこととまったく同じです。つまり、何か新しいことを学べば、それは彼らの努力のおかげです。 （だから、間違った情報を見たら、私ではなく、彼らを責めますよね？xD）

最後になりましたが、一部のスピーチでは、すべての技術的な詳細やライブ コーディングを掘り下げることはできません。しかし、興味があり、より多くの情報が必要な場合は、私に知らせてください。より詳細な記事を別に書くようにします.また、Twitter/Linkedin も忘れずにチェックしてください。

ここでは、会議のプログラムを見つけることができます。

(テスト) トラップです ！一般的なテストの落とし穴とその解決方法

Ramona Schwering - ショップウェアのソフトウェア開発者

「それは罠だ」 - スター・ウォーズに関してだけでなく、私たち全員がよく知っているかもしれない呼びかけや感情.差し迫った危険に突然気付く瞬間を示しています。

この状況は、テストにおける不快な認識の優れた寓話です。テストに関しては最善の意図を持っているのに、テストが何の価値ももたらさない結果になってしまうことを想像してみてください。

対処するのが面倒だと感じているテストはありますか?

フロントエンドのテストを書くとき、途中で多くの落とし穴があります。つまり、保守性が低下し、実行時間が遅くなり、最悪の場合、信頼できないテストが発生する可能性があります。

しかし、最悪の弱点は、新しい価値と結果が得られるテストです。成功することもあれば失敗することもあるビルドがあり、その間に何もしませんでした。

問題点

テストには多くの特典と利点があると確信しているかもしれませんが、これらの優れた機能はすべて、さまざまな理由によって引き起こされる問題点によって影が薄くなる可能性があります。あなたが最善の意図を持って行ったすべてのことは、長期的には、またはそれ以前に、苦痛または疲れ果てていることが判明しました.

たとえば、遅いテストは楽しみを台無しにする可能性があります。プル リクエストがあり、それをマージしたいが、パイプラインが最終的に完了するまで数時間または場合によっては数日待つ必要があると想像してください。

さらに悪いのは、維持するのが面倒なテストです。過去の自分について考え、次のように尋ねます。このテストで何をしましたか?目的は何だった!?それについてどう思いましたか？または、他のチーム メンバーが、あなたが過去に何をしたかについて質問してきますが、あなたには手がかりがありません。

しかし、最悪の弱点は、新しい価値と結果が得られるテストです。成功することもあれば失敗することもあるビルドがあり、その間に何もしませんでした。

簡単なテスト

このようにする必要はありません。 JavaScript テストのベスト プラクティスにおける最も重要な考え方と黄金律の 1 つは、シンプルです。

どのような場合でも、テストは単純明快に設計する必要があります。単体テスト、統合テスト、およびエンド ツー エンド テストでは、非常にシンプルに保ちます。

私たちの目標は、テストを理解し、考えなくてもすぐにその意図を理解できるようにすることです。

フラットなテスト設計を目指してください。つまり、必要なだけテストし、抽象化をほとんどまたはまったく使用しないことを意味します。

トラップ

最初のトラップを見てみましょう。

 describe('deprecated.plugin', () => { it('should throw error',() => { … }); });

非推奨のプラグインが使用されている場合は、エラーが発生するはずです。

タイトルを見ると (エラーがスローされるはずです)、何を達成したいのかわかりません。しかし、黄金律は、それが何をしているかを即座に知る必要があると言います。

「三部作法」で分かりやすくすることができます。テストのタイトルには、次の 3 つの内容を含める必要があります。

1. テスト対象
2. どのような状況でテストする必要があるか
3. 期待される結果は何ですか

このルールを念頭に置いて、テストは次のようになります。

 describe('deprecated.plugin', () => { it('Property: Should throw an errorif the deprecated prop is used', () => { … }); });

次のトラップはテスト構造にすることができます:

 describe('Context menu', () => { it('should open the context menu on click', async () => { const wrapper = createWrapper(); expect(wrapper.vm).toBeTruthy(); await wrapper.trigger('click'); const selector = '.sw-context-menu'; expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); });

この場合、宣言、アクション、およびアサーションは、明確な構造を持たずにあちこちに書かれています。特に大規模なテストでは、これは大きな苦痛になる可能性があります。 AAA パターンを使用して、より構造化することができます。テストを 3 つの部分に分割します。

1. アレンジ: テストがシミュレートするシナリオのセットアップに関するすべて。
2. アクション: テストでユニットを実行し、結果の状態に到達するための手順を実行します。
3. アサート: アサーションを実行し、テスト シナリオを確認できる場所。

AAA パターンを使用したテストは次のようになります。

 describe('Context menu', () => { it('should open the context menu on click', () => { // Arrange const wrapper = createWrapper(); const selector = '.sw-context-menu'; // Act await wrapper.trigger('click'); // Assert expect(wrapper.vm).toBeTruthy(); expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); });

これははるかに良く見えます！

しかし問題がある。テストケースを思い出してください。これはコンテキスト メニューであり、デフォルトでは非表示になっています。そのため、それを開いて操作する必要があります。しかし、それは、行為の前にそれが開いていることを確認するためにアサーションを行う必要があることを意味します。パターンを壊しませんか？

DOM をテストしている場合、前後の状態を確認する必要がある場合があります。では、このパターンを別の視点から見てみましょう。

• …自分のテストをアレンジする ==与えられたもの .
• …私のテストで行動する==何かが起こったとき。
• …assert the results == 何かが起こったら、これが結果として私が期待するものです。

これは行動駆動開発から得られたパターンです: 与えられた - いつ - その後

このパターンを使用した以前のテスト:

 describe('Context menu', () => { it('should open the context menu on click', () => { // Given const contextButtonSelector = 'sw-context-button'; const contextMenuSelector = '.sw-context-menu'; // When let contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(false); const contextButton = wrapper.find(contextButtonSelector); await contextButton.trigger('click'); // Then contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(true); }); });

E2E テスト

プレースホルダーの使用を避け、できるだけ現実的な名前を使用してください。

 it('should create and read product', () => { … cy.get('.sw-field—product-name').type('T-Shirt Ackbar'); cy.get('.sw-select-product__select_manufacturer') .type('Space Company'); … });

何千もの名前を思いつきたくない場合は、フェイカーやその他のツールを使用してダミーデータを生成するか、法律とプロジェクトで問題ない場合は、本番状態からインポートすることができます.テストが理解しやすく、読みやすく、何をするかを理解していることを確認してください。

次のトラップであるセレクターの同じテストを見てみましょう。

アプリケーションをリファクタリングし、いくつかのクラスを変更すると (これはよくあることです)、テストが失敗する可能性があります。この場合、アプリにバグが存在することなくテストが失敗します。これは偽陰性と呼ばれ、信頼できるレポートを提供しませんアプリは壊れていないため、実装が変更されただけです。

あなたがしなければならないセレクターを見てください！つまり、実装の詳細をテストするべきではありません。代わりに、ユーザーが注意を喚起し、アプリケーションをナビゲートするものを使用することを考えてください。たとえば、ページ内のテキスト。さらに良いことに、データ属性のように変更されにくいセレクターを使用してください。たとえば、cypress data-cy=”submit”ように呼び出すこともできるため、テスト用であることがすぐにわかります。

最後になりましたが、固定の待機時間は使用しないでください。

 Cypress.Commands.add('typeSingleSelect', { prevSubject: 'element', }, (subject, value, selector) => { … cy.wait(500); cy.get(`${selector} input`) .type(value); });

一方では、テスト ケースが何度も実行される場合、テストの速度が大幅に低下する可能性があります。アプリケーションが弱いハードウェアで使用されている場合は、さらに悪化する可能性があります。この場合、500 ミリ秒以上の修正が必要になる場合があります。

そのための解決策がいくつかあります。たとえば、ロード中のスピナーが消える、アニメーションが停止する、何かが表示されるなど、UI の変更を待つなどです。

または、さらに良いことに、API リクエストとレスポンスを待ちます。

テストは邪魔ではなく、アシスタントとして存在します。複雑な数式を解くのではなく、ルーチンのように感じる必要があります。

第六話の終わり

この部分を楽しんでいただければ幸いです。私にとってのように、あなたにとっても価値があります。今後数日かけて、残りのトークを共有します。乞うご期待…

ここにも掲載されています。