あいまいな過去
それはすべて簡単でした。タスクが来て、タスクが完了し、テスターがタスクを手動でテストし、ユーザーが見ることができるようにしました。 しかし、その後、すべてがより複雑になり、タスクがますます増え、開発者が追加され、テストが行われ、停止しました。
魅力的なプレゼント
私たちのチームは大きく変わりました-小さなウェブ開発部門は何倍も大きくなりました。 プロセス自体が変更されました-現在、インターフェイスは内部（コード）と外部の両方のテストで覆われています。 そして、はい、コードレビューがあり、ブランチでタスクを開発し、wikiとJS DOCジェネレーターでドキュメントを注意深く書きます。
コードテスト
明らかに、データ処理、さまざまな計算がある場合-単体テストがあるはずです。 はい、控えめにするために何があります-コードがある場合は、テストが必要です。
テストによる開発にはさまざまなアプローチがあります。TDD、BDDなどです。これらの違いを理解することはできませんが、テストプロセスについて説明します。
Gruntは、スタティックの構築とテストの実行を担当します。 Grunt + Karma + PhantomJS + Jasmin + Sinon + CoffeeScriptの束を使用します。 はい、CoffeeScriptについて聞いたことがあります。
私たちは、CSが美しく、ファッショナブルで、開発を大幅に加速するという事実について激しい議論をしてきましたが、それでも多くの理由で、CSですべてのコードを書くというこの悪い考えを捨てました。 しかし！ 主な理由の1つとして、CSのテストを作成します。コールバックシートの書き込みと読み取りは、JSよりもCSの方がはるかに優れています。 コードはよりコンパクトで楽しいです。
Jasmine-シンプルさ、Sinon-APIリクエストのエミュレート、Karma-クールなテストランナー、PhantomJS-Team Cityからの自動テストの実行に選ばれました。
すぐに予約します。ユニットテストはすべてのものではなく、共通のコンポーネントとデータが処理される場所のみをカバーします。 はい、これは悪いことであり、すべてのコードをテストでカバーする必要があるとみんなに言わせてください。特にDOMでの作業はテストでカバーできるため、そのような必要性はありませんでしたが、それは無意味で長いです。
Team Cityがあり、私たちの指示に従って、コードレビューに提出された各ブランチのアセンブリとテストを自動的に開始します。何か問題が発生した場合、開発者はこれを見つけ、壊れたコードはマスターになりません。
すべてのテストはモジュールに分割されます。 モジュールは、実行するテストケース+設定です。 このアプローチにより、必要なテストを個別に実行したり、共通の構成ファイルを使用してすべてを一度に実行したりできます。
DOMを単体テストでカバーしたい特定の瞬間があります。CSはこれを支援します。これは、複数行のコメントを作成するすばらしい機能です。 テストケースまたは別のファイルに必要なHTMLを記述するだけで、必要な場所に接続できます。
GUIテスト
前に書いたように、開発者はユニットテストをDOMでカバーしません。彼らはこれを無意味な仕事だと考えているからです。 このために、TCS Bankにはテスト部門があり、インターフェイスの視覚部分のテストに取り組んでいます。
テストには2つのタイプがあります。
- 手動で
- 自動テスト
最初のオプションでは、すべてが明確で、マウスが壊れるまでクリックし、キーボードからボタンが飛び出します。 第二に-もう少し複雑な...
インターフェイスをテストするために、ブラウザだけでなく、個々のブラウザのバージョンも指定しました。また、それらのために書かれたテストケースの束もあります。さらに、特定のブラウザでのテストに使用する必要があるテストデータがあります。バージョン。 当然、これをすべて手動で検証することは非常に困難です。 はい、そして、日常的な退屈で退屈な作業からマニュアルを保存したいという要望がありました。 一般に、はい、テストの自動化は今日ではほぼ不可欠であり、ますます急速に成長している商用およびオープンソースのツールとソリューションにより、テスト自動化を反対側から見て、疑わしい人はその方向をより頻繁に見るようになります。
自動テストではSelenium WebDriverを使用します。 人気のある実績のある多数のソリューションに基づいて独自の銃口テストフレームワークを開発しました。これにより、できる限りクリーンで透過的なテストを記述でき、コードの重複を排除して、フレームワークを設計および構築するためのタイトなフレームワークに導きます。これにより、最終テストの柔軟性とパフォーマンスをサポートするシンプルさを実現できます。 。
テスト自体は、特定のOSと一連のブラウザバージョンを搭載した実行中のマシンが（実際、もちろん、より高速に）栄光を待っているセレングリッド展開の分散ネットワークで行われます。 TeamCityからのテストは、各テストベンチの展開後に実行されるスモークテストなどのアセンブリトリガーを見て、部分的に自動で起動されます。一部は手動で、オンデマンドで実行できます。 、導入されたバグを特定します。 バグといえば。 自動テストは、ポータルGUIの表面テストだけでなく、ほとんどの自動テストが包括的であり、データベースおよびWebサービスレベルでのテストを対象としています。 そのため、自動テストが失敗した場合、テスターは「ここで壊れて、さらに詳しく見てください」という情報を含むスクリーンショットだけでなく、データベース内のデータなど、受信/送信データに関する情報を含む健全なレポートも受け取ります。
テスト環境に加えて、戦闘環境用のスモークテストが用意されており、数が少なく、予期しない障害が発生した場合の重要な機能のみを対象としています。
ケースに関するコメントとコメント、および以下の記事の作成に感謝します。ここでは、どのように、どのようにアレンジしたかについてより詳細に説明します。