Objek Domain dengan Lombok: Battle Classic

Domain Object ( Bahasa Rusia. "Domain object" ) - salah satu pendekatan paling populer untuk menggunakan data uji langsung dalam logika skrip. Saat ini, ini adalah salah satu pendekatan yang paling populer dan tersebar luas karena kesederhanaan, kelengkapan dan logikanya.

Ini berlaku di semua jenis otomatisasi pengujian fungsional (End-to-End, API, Integration), terlepas dari platform yang diuji, apakah itu Web, Mobile, atau Desktop.

PENTING : Jangan bingung Obyek Domain dengan Data Transfer Object (DTO) . Ini adalah pendekatan yang sangat berbeda yang diterapkan di berbagai bidang.

Apa esensinya?

Dari nama lain dari pendekatan - "Obyek Bisnis" - menjadi jelas bahwa ini adalah semacam abstraksi, yang merupakan model dan deskripsi objek yang penting untuk memahami dan memfungsikan logika bisnis aplikasi . Itu tidak mampu melakukan fungsi apa pun selain bidang "mentransfer" dan nilainya ke satu unit bisnis tertentu.

---

Seperti apa bentuknya

Sebagai contoh, ambil aplikasi apa pun yang menyediakan pembuatan akun pengguna. Itu adalah pengguna yang menjadi objek domain kami. Dalam hampir semua kasus, pengguna harus memiliki nama pengguna dan kata sandi:

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

Yang sangat hati-hati akan memperhatikan bahwa semua bidang internal bersifat pribadi. Menetapkan dan membaca nilai langsung dari bidang objek dianggap praktik buruk. Alih-alih, biasanya menggunakan getter dan setter terkenal:

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

Sekarang, kami memiliki akses ke bidang, dan kami dapat mengatur dan membaca nilainya. Namun dalam contoh ini, kami hanya menggunakan dua bidang. Dan apa yang terjadi jika ada lima belas bidang ini? Benar, kelas Pengguna memperluas ke ukuran yang belum pernah terjadi sebelumnya, berkat copy copy getter dan setter yang tak berujung. Bagaimana kita menangani ini?

---

Sihir lombok

Di sinilah Proyek Lombok datang ke penyelamatan - perpustakaan populer yang memungkinkan kita untuk mengurangi kode beberapa kali, menghindari menyalin / menempel penderitaan, dan secara signifikan mengurangi jumlah waktu yang diperlukan untuk menulis kelas Objek Data. Beberapa tautan bermanfaat:

• Situs resmi Project Lobmok
• Panduan Instalasi untuk IntelliJ IDEA Plugin
• Lombok di Maven Central

Apa yang dia lakukan Secara otomatis membuat getter dan setter untuk semua bidang kelas, dengan menetapkan anotasi yang sesuai:

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

Sederhana, cepat, nyaman. Dengan demikian, kode kita menjadi lebih mudah dibaca, kelas lebih ringkas, dan pengembangan lebih cepat.

---

Terapkan dalam ujian

Tes yang baik adalah tes di mana data uji, logika uji, dan implementasinya dipisahkan dengan jelas.

Ayo coba masuk pengguna kami. Kami membuat kelas dengan data uji, dan "mengisinya" dengan Pengguna baru:

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

Kami menggambarkan model halaman Login:

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

Tetap hanya menerapkan kelas tes:

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

Selesai! Kamu hebat!

---

Untuk meringkas

Di final, kami mendapatkan arsitektur proyek yang rapi , dengan pemisahan logika, data, dan implementasi yang jelas. Lombok membantu Anda menyingkirkan duplikasi kode, Objek Domain sangat cocok dengan filosofi Halaman Objek, dan dukungan kode menjadi kesenangan nyata.

Haruskah ada minus?

1. Kekebalan. Atau lebih tepatnya, ketidakhadirannya. Dalam hal ini, pendekatan ini menggunakan Lombok kalah dari pesaing utama - Builder ( artikel tentang Habré ). Namun, menurut pendapat saya, kode di atas lebih "bersih", dapat dimengerti, dan secara estetika menyenangkan, dibandingkan dengan rantai tak berujung pada pembangun dan tumpukan metode di kelas Object.
2. Tingkatkan kompleksitas di tempat yang tidak dibutuhkan. Tidak begitu minus sebagai pengingat kecil. Pendekatan atau pola apa pun bermasalah dan harus memecahkan masalah tertentu. Anda tidak boleh mencoba menggunakan Obyek Data dalam tes unit yang hanya memeriksa bahwa 2 + 2 = 4.

Terima kasih banyak atas perhatiannya. Saya akan senang menerima ulasan dan kritik.

PS Beri tahu dalam komentar apa pendekatan yang Anda gunakan dalam pekerjaan Anda. Akan sangat menarik untuk dibaca.