Bagaimana cara menerapkan TDD untuk fungsi baca / tulis?

Sepertinya masalah ayam dan telur.

Anda dapat membuat fungsi tulis menulis ke beberapa penyimpanan data, tetapi tidak pernah tahu Anda menyimpannya dengan benar tanpa fungsi baca yang teruji.

Anda dapat membuat fungsi baca dibaca dari penyimpanan data, tetapi bagaimana Anda meletakkan barang-barang di penyimpanan data itu, untuk dibaca, tanpa fungsi tulis yang teruji?

EDIT:

Saya terhubung ke dan melakukan transaksi dengan database SQL untuk menyimpan dan memuat objek untuk digunakan. Tidak ada gunanya menguji fungsi akses yang disediakan DB, tapi saya membungkus fungsi DB tersebut untuk membuat serial / deserialize objek. Saya ingin memastikan saya menulis dan membaca hal yang benar ke dan dari DB dengan benar.

Ini tidak seperti menambah / menghapus, seperti @snowman menyebutkan. Saya ingin tahu bahwa konten yang saya tulis sudah benar, tetapi itu membutuhkan fungsi baca yang teruji. Ketika saya membaca, saya ingin memastikan bahwa bacaan saya telah dengan benar menciptakan objek yang setara dengan apa yang ditulis; tapi itu membutuhkan fungsi tulis yang sudah teruji.

Mulai dengan Fungsi Baca.

• Dalam pengaturan pengujian : buat database dan tambahkan data pengujian. baik melalui skrip migrasi atau dari cadangan. Karena ini bukan kode Anda, itu tidak memerlukan tes dalam TDD

• Dalam pengujian : instanciate repositori Anda, arahkan ke pada db tes Anda dan panggil metode Baca. Periksa apakah data uji dikembalikan.

Sekarang Anda memiliki fungsi baca yang teruji sepenuhnya, Anda dapat pindah ke fungsi Tulis, yang dapat menggunakan Baca yang ada untuk memverifikasi hasilnya sendiri

Saya sering hanya menulis dan diikuti dengan membaca. mis. (kodesemu)

Foo foo1 = setup some object to write
File tempfile = create a tempfile, possibly in memory 
writeFoo(foo1, tempfile) 
Foo foo2 = readFoo(tempfile) 
assertEquals(foo1, foo2); 
clean-up goes here

Ditambahkan nanti

Selain solusi ini menjadi "prgamatic" dan "cukup baik", orang dapat berpendapat bahwa solusi lain menguji hal yang salah . Menguji apakah string atau pernyataan SQL cocok bukan ide yang buruk, saya sudah melakukannya sendiri, tetapi sedang menguji efek samping, dan rapuh. Bagaimana jika Anda mengubah kapitalisasi, menambah bidang, atau memperbarui nomor versi dalam data Anda? Bagaimana jika driver SQL Anda mengubah urutan panggilan untuk efisiensi, atau serializer XML Anda yang diperbarui menambah ruang ekstra atau mengubah versi skema?

Sekarang, jika Anda harus sangat ketat mematuhi beberapa spesifikasi resmi, maka saya setuju bahwa memeriksa detail yang baik adalah tepat.

Jangan. Jangan uji unit I / O. Membuang buang waktu saja.

Logika uji unit. Jika ada banyak logika yang ingin Anda uji dalam kode I / O, Anda harus refactor kode Anda untuk memisahkan logika bagaimana Anda I / O dan apa yang saya / O Anda lakukan dari bisnis yang sebenarnya melakukan I / O (yang hampir mustahil untuk diuji).

Untuk sedikit menguraikan, jika Anda ingin menguji server HTTP, Anda harus melakukannya melalui dua jenis tes: tes integrasi dan tes unit. Tes unit tidak boleh berinteraksi dengan I / O sama sekali. Itu lambat dan memperkenalkan banyak kondisi kesalahan yang tidak ada hubungannya dengan kebenaran kode Anda. Tes unit seharusnya tidak tergantung pada kondisi jaringan Anda!

Kode Anda harus terpisah:

• Logika menentukan informasi apa yang akan dikirim
• Logika menentukan byte mana yang akan dikirim untuk mengirim sedikit informasi tertentu (bagaimana cara menyandikan respons, dll. Ke dalam byte mentah), dan
• Mekanisme penulisan byte-byte tersebut ke soket.

Dua yang pertama melibatkan logika dan keputusan dan membutuhkan tes unit. Yang terakhir tidak melibatkan pengambilan banyak jika ada keputusan dan dapat diuji dengan luar biasa menggunakan pengujian integrasi.

Sebenarnya ini hanya desain yang bagus, tetapi salah satu alasannya adalah membuatnya lebih mudah untuk diuji.

Berikut ini beberapa contohnya:

• Jika Anda menulis kode yang mendapatkan data dari basis data relasional, Anda dapat menguji bagaimana Anda memetakan data yang dikembalikan dari kueri relasional ke model aplikasi Anda.
• Jika Anda menulis kode yang menulis data ke database relasional, Anda dapat menguji unit mana dari data yang ingin Anda tulis ke database tanpa benar-benar menguji permintaan SQL tertentu yang Anda gunakan. Misalnya, Anda mungkin menyimpan dua salinan status aplikasi Anda dalam memori: salinan yang mewakili seperti apa database dan copy pekerjaan. Saat Anda ingin menyinkronkan ke basis data, Anda perlu membuatnya berbeda dan menulis perbedaannya ke basis data. Anda dapat dengan mudah menguji unit kode diff itu.
• Jika Anda menulis kode yang membaca sesuatu dari file konfigurasi, Anda ingin menguji parser format file konfigurasi Anda, tetapi dengan string dari file sumber tes Anda daripada string yang Anda dapatkan dari disk.

Saya tidak tahu apakah ini praktik standar atau tidak, tetapi itu berfungsi dengan baik untuk saya.

Dalam implementasi metode baca tulis non-database saya menggunakan tipe-spesifik saya sendiri toString() dan fromString()metode sebagai detail implementasi.

Ini dapat dengan mudah diuji secara terpisah:

 assertEquals("<xml><car type='porsche'>....", new Car("porsche").toString());

Untuk metode baca tulis yang sebenarnya saya punya satu tes integrasi yang secara fisik membaca dan menulis dalam satu tes

Ngomong-ngomong: Apakah ada yang salah dengan satu tes yang tes baca / tulis bersama?

Data yang diketahui harus diformat dengan cara yang diketahui. Cara termudah untuk mengimplementasikan ini adalah dengan menggunakan string konstan dan membandingkan hasilnya, seperti yang dijelaskan oleh @ k3b.

Anda tidak terbatas pada konstanta. Mungkin ada sejumlah properti dari data tertulis yang dapat Anda ekstrak menggunakan parser yang berbeda, seperti ekspresi reguler, atau bahkan probe ad hoc yang mencari fitur data.

Sedangkan untuk membaca atau menulis data, mungkin berguna untuk memiliki sistem file dalam memori yang memungkinkan Anda untuk menjalankan tes Anda tanpa kemungkinan gangguan dari bagian lain dari sistem. Jika Anda tidak memiliki akses ke sistem file dalam memori yang baik, gunakan pohon direktori sementara.

Gunakan injeksi ketergantungan dan ejekan.

Anda tidak ingin menguji driver SQL Anda dan Anda tidak ingin menguji apakah database SQL Anda online dan diatur dengan benar. Itu akan menjadi bagian dari uji integrasi atau sistem. Anda ingin menguji apakah kode Anda mengirimkan pernyataan SQL yang seharusnya dikirim dan jika ia menginterpretasikan respons seperti yang seharusnya.

Jadi ketika Anda memiliki metode / kelas yang seharusnya melakukan sesuatu dengan basis data, jangan memilikinya dapatkan koneksi basis data itu sendiri. Ubahlah sehingga objek yang mewakili koneksi database diteruskan ke sana.

Dalam kode produksi Anda, lulus objek database yang sebenarnya.

Dalam pengujian unit Anda, lulus objek tiruan yang hanya berperilaku seperti database aktual tidak benar-benar menghubungi server database. Periksalah apakah ia menerima pernyataan SQL yang seharusnya diterimanya dan kemudian merespons dengan tanggapan yang dikodekan dengan keras.

Dengan cara ini Anda dapat menguji lapisan abstraksi basis data Anda tanpa memerlukan basis data yang sebenarnya.

Jika Anda menggunakan pemetaan relasional objek, biasanya ada pustaka terkait yang dapat digunakan untuk menguji apakah pemetaan Anda bekerja dengan benar dengan membuat agregat, bertahan, dan memuatnya kembali dari sesi baru, diikuti dengan verifikasi status terhadap objek aslinya.

NHibernate menawarkan Pengujian Spesifikasi Persistensi . Ini dapat dikonfigurasikan untuk bekerja melawan penyimpanan dalam memori untuk pengujian unit cepat.

Jika Anda mengikuti versi paling sederhana dari pola Repositori dan Unit Kerja, dan menguji semua pemetaan Anda, Anda dapat mengandalkan hal-hal yang berfungsi dengan baik.