unit-testing - Liferayによるテスト駆動開発

Question

私はLiferayを初めて使用します。誰かがliferayでテスト駆動開発をフォローする方法について私を導くのを手伝ってもらえますか？

誰かがテストを作成し、portlesを開発するためにeclispe IDEを使用してテストを実行する方法のガイドラインを提供できますか？

Answer 1

ポートレットは本質的にUI中心であり、テスト駆動型で開発するためのほとんどすべてのUIレイヤーコードと同じ問題が発生します。私は個人的に、ユーザーの受け入れを念頭に置いてUIを開発し、可能な限り浅くして、基礎となるビジネスロジックから地獄をテストし、UIの配線を自動テストではなくコードレビューに任せるのが好きです。

これによりテストカバレッジの点で穴が残ることは知っていますが、UIレイヤーテストのほとんどは、80％のセットアップ、5％の実際のアサーション（最大）、および15％のティアダウンコードであると感じています。私見これは貴重なテストケースを構成していません。

テスト駆動開発について具体的に質問している場合：TDDは主に設計手法であることに注意してください。結果として得られるテストは非常に歓迎されますが、主な目的はテスト対象のソフトウェアを設計することです。（TDDソフトウェアは、紙でデザインされたスタイルや他の非TDDスタイルとは本質的に異なって見えます）。アーキテクチャとデザインの大部分がUIフレームワークによって課せられる場合、これはTDDで「デザイン」するのに十分ではありません。したがって、ユーザーインタラクションをデザインし、魅力的なものにします（可能な限り薄く保ちます）。

これで、UIの上に統合テストを自由に追加できます-通常、そのためにJUnitを使用することはなく、実行時間は単体テストよりも長くなる可能性があります」が、そのタイプのテストを実行する価値は十分にあります。 UIの上部。テスト側からUIレイヤーを設計することで、UIレイヤーについてあまり多くの洞察を期待しないでください。これは、ビジネスレイヤー（およびUIレイヤーで使用するさまざまなユーティリティスタイルのコードビット）用に保持しますが、ビジネスレイヤーからユーザーの操作への純粋な配線用には保持しません。

Answer 2

オラフコックに完全に同意します。

TDDが好きな場合は、このアプローチでビジネスレイヤーを設計できますが、ポートレットなどのUI中心のコンポーネントでは、テスト対象のコードを記述した後にテストを記述する従来のアプローチを使用することをお勧めします。たとえば、Selenium WebDriverを使用して、UIをテストするためのブラウザーアクションを自動化できます。