テスト対象のプラットフォーム（Web、モバイル、デスクトップ）に関係なく、機能テスト（エンドツーエンド、API、統合）のすべてのタイプの自動化に適用できます。
重要 ：ドメインオブジェクトとデータ転送オブジェクト（DTO）を混同しないでください。 これらは、異なる分野に適用されるまったく異なるアプローチです。その本質は何ですか？
アプローチの別の名前「ビジネスオブジェクト」から、これは一種の抽象化であることが明らかになります 。これは、アプリケーションのビジネスロジックの理解と機能に重要なオブジェクトのモデルと説明です 。 フィールドとその値を1つの特定のビジネスユニットに「転送」する以外の機能を実行することはできません。
それはどのように見えますか
例として、ユーザーアカウントの作成を提供するアプリケーションを取り上げます。 ドメインオブジェクトになるのはユーザーです。 ほとんどすべての場合、ユーザーにはユーザー名とパスワードが必要です。
// User public class User { // , User Login private String login; // , User Password private String password; }
特に注意が必要なのは、すべての内部フィールドがプライベートであることです。 オブジェクトのフィールドから直接値を設定および読み取ることは、悪い習慣と見なされます。 代わりに、よく知られているゲッターとセッターを使用するのが習慣です。
public class User { private String login; private String password; // login public void setLogin(String login) { this.login = login; } // login public String getLogin() { return this.login; } // public void setPassword(String password) { this.password = password; } public String getPassword() { return this.password; } }
これで、フィールドにアクセスでき、値を設定して読み取ることができます。 しかし、この例では、2つのフィールドのみを使用しています。 そして、これらのフィールドが15個あるとどうなりますか？ 確かに、Userクラスは、ゲッターとセッターの無限のコピーペーストのおかげで、前例のないサイズに拡張されます。 これにどう対処しますか？
マジックロンボク
これがProject Lombokの助けとなります-コードを数回削減し、コピー/貼り付けの問題を回避し、データオブジェクトクラスの作成にかかる時間を大幅に削減できる人気のあるライブラリです。 便利なリンク：
彼は何をしていますか？ 対応する注釈を割り当てることにより、クラスのすべてのフィールドのゲッターとセッターを自動的に作成します。
import lombok.Getter; import lombok.Setter; // User @Getter // User @Setter public class User { private String login; private String password; }
シンプル、高速、便利。 したがって、コードははるかに読みやすくなり、クラスはより簡潔になり、開発は高速になります。
テストで適用
適切なテストとは、テストデータ、テストロジック、およびその実装が明確に分離されているテストです。
ユーザーにログインしてみましょう。 テストデータでクラスを作成し、新しいユーザーで「入力」します。
// Test Data public class TestDataUser { // private- private final static String DEFAULT_LOGIN = "vasiliy_pupkin"; private final static String DEFAULT_PASSWORD = "q1w2e3"; // public static User getDefaultUser() { // "" User user = new User(); // Login user.setLogin(DEFAULT_LOGIN); // Password user.setPassword(DEFAULT_PASSWORD); // User, return user; } }
ログインページのモデルについて説明します。
public class LoginPage { // public- , User public void loginUser(User user) { // enterLogin() enterLogin(user.getLogin()); // enterPassword(user.getPassword()); } private void enterLogin(String login) { this.loginInput.sendKeys(login); } private void enterPassword(String password) { this.passwordInput.sendKeys(password); } }
テストクラスを実装するだけです。
public class LoginTest { @Test public void loginAsDefaultUser() { // credentials User user = TestDataUser.getDefaultUser(); // Login- LoginPage loginPage = new LoginPage(); // , loginPage.loginUser(user); } }
できた！ あなたは素晴らしいです！
まとめると
最後に、ロジック、データ、実装を明確に分離した、 きちんとしたプロジェクトアーキテクチャを取得します。 Lombokを使用すると、コードの重複を取り除くことができ、ドメインオブジェクトはページオブジェクトの哲学に完全に適合し、コードサポートは非常に楽しいものになります。
マイナスがあるべきですか？
- 免疫。 むしろ、その不在。 この点で、Lombokを使用したこのアプローチは、主要な競争相手であるBuilderに負けています（ Habréの記事 ）。 しかし、私の意見では、上記のコードは、ビルダーの無限のチェーンやObjectクラスのメソッドのヒープと比較して、より「クリーン」で、理解しやすく、見た目も楽しいです。
- 不要な場合は複雑さを増してください。 小さなリマインダーほどマイナスではありません。 どのアプローチやパターンにも問題があり、問題を解決する必要があります。 2 + 2 = 4であることを確認する単体テストでデータオブジェクトを使用しないでください。
ご清聴ありがとうございました。 私はレビューと批判に喜んでいるでしょう。
PSあなたの仕事で使用するアプローチをコメントで教えてください。 読むのはとても面白いでしょう。