Tetap OO dan Dapat Diuji saat bekerja dengan database

Apa sajakah strategi OOP untuk bekerja dengan database tetapi menjaga unit-unit dapat diuji? Katakanlah saya memiliki kelas Pengguna dan lingkungan produksi saya berfungsi terhadap MySQL. Saya melihat beberapa kemungkinan pendekatan, ditunjukkan di sini menggunakan PHP:

1. Masukkan $ data_source dengan antarmuka untuk load()dan save(), untuk abstrak sumber backend data. Saat menguji, lewati penyimpanan data yang berbeda.

   $ user = Pengguna baru ($ mysql_data_source);
   $ user-> load ('bob');
   $ user-> setNickname ('Robby');
   $ user-> save ();
   

2. Gunakan pabrik yang mengakses database dan melewati baris hasil ke konstruktor Pengguna. Saat menguji, secara manual menghasilkan parameter $ baris, atau mengejek objek di UserFactory :: $ data_source. (Bagaimana saya bisa menyimpan perubahan ke catatan?)

   class UserFactory {
       static $data_source;
   
       public static function fetch( $username ) {
           $row = self::$data_source->get( [params] );
   
           $user = new User( $row );
           return $user;
       }
   }
   

Saya memiliki Pola Desain dan Kode Bersih di sini di sebelah saya, tetapi saya berjuang untuk menemukan konsep yang berlaku.

Jadi yang ingin Anda ambil adalah Pola Arsitektur Aplikasi Enterprise Martin Fowlers (Ia juga menyediakan katalog di situs webnya di sini ).

Di dalamnya ia menggambarkan beberapa pola untuk abstrak akses data. Pendekatan pertama yang Anda jelaskan adalah Rekaman Aktif . Pendekatan kedua Anda mirip dengan Table Data Gateway .

Pendekatan yang lebih baik lagi adalah dengan menggunakan O / RM untuk menghapus kebutuhan untuk menulis kode akses data secara manual. Saya belum menggunakan PHP karena kami khawatir tentang Y2K, tetapi wikipedia memiliki daftar opsi untuk Anda . Saya tidak tahu apakah mereka bagus. Saya dapat memberi tahu Anda beberapa hal yang harus dicari dalam O / RM:

• Ketidaktahuan Ketekunan : O / RM seharusnya tidak memaksa objek bisnis Anda untuk diturunkan dari antarmuka / kelas tertentu untuk berpartisipasi dalam strategi akses data.
• Pemetaan Relasi : Anda harus dapat memetakan hubungan antara objek Anda (pelanggan memiliki pesanan, pesanan memiliki item baris, item baris memiliki produk, dll.)
• Pemetaan Hirarki : Anda harus dapat memetakan hirarki kelas ke database.
• Dukungan Sintaks / Kriteria Query : Anda harus dapat membuat kueri saat run-time dalam hal Objek Anda tidak dalam hal database, dan O / RM harus menerjemahkan dan menjalankan kueri pada database. Poin ekstra jika kueri adalah rantai yang diketik dengan kuat alih-alih string.

Ada faktor-faktor lain yang perlu dipertimbangkan, tetapi itu adalah beberapa yang paling penting. Semoga ini membantu.

IMHO itu tergantung pada apa yang ingin Anda uji, jika Anda ingin unit menguji logika bisnis Anda, Anda harus mematikan / mengejek ( Martin Fowler ) Anda mengakses data sehingga saran pertama Anda adalah awal yang baik. Pertanyaan stackoverflow ini memberikan contoh C # yang bagus (saya mencoba mencari beberapa contoh PHP tetapi tidak bisa menemukan).

Jika Anda ingin menguji akses data itu sendiri itu tidak disebut pengujian unit lagi tetapi pengujian integrasi. Baca di sini untuk panduan umum, pertanyaan stackoverflow ini juga memiliki beberapa tautan menarik.

Jika Anda ingin menguji logika prosedur tersimpan di basis data Anda, lihat xUnit TestPattern

Semoga ini membantu

Ini tidak selalu merupakan jawaban yang segera membantu, tetapi jika Anda benar-benar khawatir tentang kemampuan pengujian basis data, Anda harus melihat bagaimana hal itu dilakukan di Ruby on Rails. Sejauh yang saya tahu, tidak ada yang membahas topik lebih baik atau lebih intuitif.

Saya merekomendasikan Anda untuk memeriksa solusi Symfony Framework untuk masalah seperti ini. Symfony merupakan kerangka kerja OO php dengan tes fungsional.

Berikut ini tautan , mereka menggunakan sesuatu seperti apa yang Anda pikirkan.