私はクライアント側のコードとサーバー側(ノード/エクスプレス)コードで構成されるJavascriptアプリケーションを持っています。クライアントとサーバーの両方をカバーするテストソリューションがありますか、またはそれぞれに個別のテストフレームワークを実行する必要がありますか?同形のjavascriptアプリケーションのテスト
理由クライアントとサーバーの間でコードを共有しようとしているためです。一意のIDを生成するヘルパー関数。これは良い考えですか、それとも懸念を分ける方が良いですか?
私はクライアント側のコードとサーバー側(ノード/エクスプレス)コードで構成されるJavascriptアプリケーションを持っています。クライアントとサーバーの両方をカバーするテストソリューションがありますか、またはそれぞれに個別のテストフレームワークを実行する必要がありますか?同形のjavascriptアプリケーションのテスト
理由クライアントとサーバーの間でコードを共有しようとしているためです。一意のIDを生成するヘルパー関数。これは良い考えですか、それとも懸念を分ける方が良いですか?
これは複数回答の複雑な質問です。 tl; drあなたは多くのサーバー側のテストを行うことができますが、通常はある時点でクライアント側のテストが必要になります。
多くの点で、javascriptアプリケーションは同形であっても、クライアント側とサーバー側の実際の実行環境は、グローバルおよび言語機能に関して非常に異なります。テストの補完者であるためには、クライアント側とサーバー側の両方のテストを行う必要があります。ノード でDOM APIを置き換えるために使用jsdom
- :1は、以下の方法で、クライアント側のテストを最小限に抑えるか、完全に除去するために選択することができますjavascriptのアプリケーションの実装とモジュール性に応じて、より実践的なstandpoint--から
- しかし、あなたはほとんど常にブラウザをスピンアップしたいいくつかの時点で分離
に、必要に応じてブラウザのグローバル変数をスタブとテストモジュール - 同型のためのアプリケーションが コンポーネントのインスタンスにテストハーネスとしてjest
+ react-addons-test-utils
および/またはenzyme
を使用して反応させ、 「実世界」テストのためのこれはkarma
のような全体的な解決策の形で行われるか、ユニットテストの場合mocha
+ browserify
/webpack
、統合テストの場合はnightwatch
となります。
サーバーサイドテストとクライアントサイドテストの他の重要な違いは、サーバーサイドテストでは決してに動的な動作があることです。それは完全にクライアントの中に住んでいます。アプリケーションがブラウザーの機能に依存する量は、同形ライブラリ機能(純粋なReactなど)ではなく、クライアント側のテストがますます必要になります。
理由クライアントとサーバーの間でコードを共有しようとしているためです。一意のIDを生成するヘルパー関数。これは良い考えですか、それとも懸念を分ける方が良いですか? – JoeTidee
テストしているコードがブラウザのグローバル(DOM、場所、ストレージなど)に依存しない場合は、サーバー上でテストするだけです – CaptEmulation