Domain-Objekt mit Lombok: Battle Classic

Domain Object ( russisch. "Domain Object" ) - einer der beliebtesten Ansätze zur Verwendung von Testdaten direkt in der Skriptlogik. Derzeit ist es aufgrund seiner Einfachheit, Verständlichkeit und Logik einer der beliebtesten und am weitesten verbreiteten Ansätze .

Es ist für alle Arten der Automatisierung von Funktionstests (End-to-End, API, Integration) anwendbar, unabhängig von der getesteten Plattform, ob Web, Mobile oder Desktop.

WICHTIG : Verwechseln Sie Domain Object nicht mit Data Transfer Object (DTO) . Dies sind völlig unterschiedliche Ansätze, die in verschiedenen Bereichen angewendet werden.

Was ist seine Essenz?

Aus einem anderen Namen des Ansatzes - „Geschäftsobjekt“ - wird deutlich, dass dies eine Art Abstraktion ist, bei der es sich um ein Modell und eine Beschreibung des Objekts handelt, die für das Verständnis und die Funktionsweise der Geschäftslogik der Anwendung wichtig sind. Es ist nicht in der Lage, andere Funktionen als das „Übertragen“ von Feldern und deren Werten an einen bestimmten Geschäftsbereich auszuführen.

---

Wie sieht es aus?

Nehmen Sie als Beispiel eine Anwendung, die die Erstellung eines Benutzerkontos vorsieht. Es ist der Benutzer, der unser Domain-Objekt wird. In fast allen Fällen muss der Benutzer einen Benutzernamen und ein Passwort haben:

//    User public class User { // ,  User    Login private String login; // ,  User    Password private String password; } 

Besonders vorsichtige werden feststellen, dass alle internen Felder privat sind. Das Einstellen und Lesen von Werten direkt aus den Feldern eines Objekts wird als schlechte Praxis angesehen. Stattdessen ist es üblich, bekannte Getter und Setter zu verwenden:

 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; } } 

Jetzt haben wir Zugriff auf die Felder und können deren Werte festlegen und lesen. In diesem Beispiel verwenden wir jedoch nur zwei Felder. Und was passiert, wenn es fünfzehn dieser Felder gibt? Die User-Klasse wird dank der endlosen Kopier- und Einfügefunktion von Gettern und Setzern auf beispiellose Größen erweitert. Wie werden wir damit umgehen?

---

Magischer Lombok

Hier kommt Project Lombok zum Einsatz - eine beliebte Bibliothek, mit der wir Code mehrmals reduzieren, Probleme beim Kopieren / Einfügen vermeiden und den Zeitaufwand für das Schreiben von Datenobjektklassen erheblich reduzieren können. Einige nützliche Links:

• Offizielle Seite Projekt Lobmok
• Installationsanleitung für das IntelliJ IDEA Plugin
• Lombok bei Maven Central

Was macht er Erstellt automatisch Getter und Setter für alle Felder der Klasse, indem ihr die entsprechende Anmerkung zugewiesen wird:

 import lombok.Getter; import lombok.Setter; //       User @Getter //       User @Setter public class User { private String login; private String password; } 

Einfach, schnell und bequem. Dadurch wird unser Code viel lesbarer, die Klassen sind prägnanter und die Entwicklung ist schneller.

---

Im Test anwenden

Ein guter Test ist ein Test, bei dem Testdaten, Testlogik und deren Implementierung klar voneinander getrennt sind.

Versuchen wir, unseren Benutzer anzumelden. Wir erstellen eine Klasse mit Testdaten und "füllen" sie mit einem neuen Benutzer:

 //  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; } } 

Wir beschreiben das Modell der Anmeldeseite:

 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); } } 

Es bleibt nur die Testklasse zu implementieren:

 public class LoginTest { @Test public void loginAsDefaultUser() { //    credentials   User user = TestDataUser.getDefaultUser(); //  Login- LoginPage loginPage = new LoginPage(); // ,     loginPage.loginUser(user); } } 

Fertig! Du bist großartig!

---

Zusammenfassend

Im Finale erhalten wir eine übersichtliche Projektarchitektur mit einer klaren Trennung von Logik, Daten und Implementierung. Lombok hilft Ihnen dabei, Code-Duplikationen zu beseitigen, Domain Object passt perfekt zur Page Object-Philosophie und die Code-Unterstützung wird zu einem echten Vergnügen.

Sollte es Minuspunkte geben?

1. Immunität. Oder besser gesagt, seine Abwesenheit. Dabei verliert dieser Ansatz mit Lombok gegen den Hauptkonkurrenten - Builder ( Artikel über Habré ). Meiner Meinung nach ist der obige Code jedoch „sauberer“, verständlicher und ästhetischer als die endlose Kette im Builder und der Vielzahl von Methoden in der Object-Klasse.
2. Erhöhen Sie die Komplexität dort, wo sie nicht benötigt wird. Nicht so sehr Minus als eine kleine Erinnerung. Jeder Ansatz oder jedes Muster ist problematisch und sollte ein bestimmtes Problem lösen. Sie sollten nicht versuchen, das Datenobjekt in einem Komponententest zu verwenden, bei dem nur 2 + 2 = 4 überprüft wird.

Vielen Dank für Ihre Aufmerksamkeit. Ich freue mich über Bewertungen und Kritik.

PS Sagen Sie in den Kommentaren, welche Ansätze Sie in Ihrer Arbeit verwenden. Es wird sehr interessant sein zu lesen.