Iterasi #5 – Membuat pengujian unit (C#)

Dalam iterasi kelima, kami membuat aplikasi kami lebih mudah dirawat dan dimodifikasi dengan menambahkan pengujian unit. Kami meniru kelas model data kami dan membangun pengujian unit untuk pengontrol dan logika validasi kami.

Membangun Manajemen Kontak ASP.NET Aplikasi MVC (C#)

Dalam rangkaian tutorial ini, kami membangun seluruh aplikasi Manajemen Kontak dari awal hingga akhir. Aplikasi Contact Manager memungkinkan Anda menyimpan informasi kontak - nama, nomor telepon, dan alamat email - untuk daftar orang.

Kami membangun aplikasi melalui beberapa iterasi. Dengan setiap iterasi, kami secara bertahap meningkatkan aplikasi. Tujuan dari pendekatan perulangan ganda ini adalah untuk memungkinkan Anda memahami alasan setiap perubahan.

Iterasi #1 - Buat aplikasi. Pada iterasi pertama, kami membuat Contact Manager dengan cara yang paling sederhana. Kami menambahkan dukungan untuk operasi database dasar: Buat, Baca, Perbarui, dan Hapus (CRUD).
Iterasi #2 - Buat aplikasi terlihat bagus. Dalam perulangan ini, kami meningkatkan tampilan aplikasi dengan memodifikasi halaman master tampilan ASP.NET MVC default dan lembar gaya bertingkat.
Iterasi #3 - Tambahkan validasi formulir. Dalam iterasi ketiga, kami menambahkan validasi formulir dasar. Kami mencegah orang mengirimkan formulir tanpa melengkapi bidang formulir yang diperlukan. Kami juga memvalidasi alamat email dan nomor telepon.
Iterasi #4 - Buat aplikasi digabungkan secara longgar. Dalam iterasi keempat ini, kami memanfaatkan beberapa pola desain perangkat lunak untuk mempermudah pemeliharaan dan modifikasi aplikasi Contact Manager. Misalnya, kami merefaktor aplikasi kami untuk menggunakan pola Repositori dan pola Injeksi Dependensi.
Iterasi #5 - Membuat pengujian unit. Dalam iterasi kelima, kami membuat aplikasi kami lebih mudah dirawat dan dimodifikasi dengan menambahkan pengujian unit. Kami meniru kelas model data kami dan membangun pengujian unit untuk pengontrol dan logika validasi kami.
Iterasi #6 - Gunakan pengembangan berbasis pengujian. Dalam iterasi keenam ini, kami menambahkan fungsionalitas baru ke aplikasi kami dengan menulis pengujian unit terlebih dahulu dan menulis kode terhadap pengujian unit. Dalam perulangan ini, kami menambahkan grup kontak.
Iterasi #7 - Tambahkan fungsionalitas Ajax. Dalam iterasi ketujuh, kami meningkatkan responsivitas dan performa aplikasi kami dengan menambahkan dukungan untuk Ajax.

Perulangan ini

Dalam iterasi sebelumnya dari aplikasi Contact Manager, kami merefaktor aplikasi agar lebih longgar digabungkan. Kami memisahkan aplikasi menjadi lapisan pengontrol, layanan, dan repositori yang berbeda. Setiap lapisan berinteraksi dengan lapisan di bawahnya melalui antarmuka.

Kami merefaktor aplikasi untuk membuat aplikasi lebih mudah dirawat dan dimodifikasi. Misalnya, jika kita perlu menggunakan teknologi akses data baru, kita cukup mengubah lapisan repositori tanpa menyentuh pengontrol atau lapisan layanan. Dengan membuat Contact Manager digabungkan secara longgar, kami telah membuat aplikasi lebih tahan terhadap perubahan.

Tapi, apa yang terjadi ketika kita perlu menambahkan fitur baru ke aplikasi Contact Manager? Atau, apa yang terjadi ketika kita memperbaiki bug? Yang menyedihkan, tetapi terbukti dengan baik, kebenaran menulis kode adalah bahwa setiap kali Anda menyentuh kode Anda menciptakan risiko memperkenalkan bug baru.

Misalnya, satu hari yang baik, manajer Anda mungkin meminta Anda untuk menambahkan fitur baru ke Contact Manager. Dia ingin Anda menambahkan dukungan untuk Grup Kontak. Dia ingin Anda memungkinkan pengguna untuk mengatur kontak mereka ke dalam grup seperti Teman, Bisnis, dan sebagainya.

Untuk menerapkan fitur baru ini, Anda harus memodifikasi ketiga lapisan aplikasi Contact Manager. Anda harus menambahkan fungsionalitas baru ke pengontrol, lapisan layanan, dan repositori. Segera setelah Anda mulai memodifikasi kode, Anda berisiko melanggar fungsionalitas yang bekerja sebelumnya.

Merefaktor aplikasi kami menjadi lapisan terpisah, seperti yang kami lakukan dalam iterasi sebelumnya, adalah hal yang baik. Itu adalah hal yang baik karena memungkinkan kita untuk membuat perubahan pada seluruh lapisan tanpa menyentuh sisa aplikasi. Namun, jika Anda ingin membuat kode dalam lapisan lebih mudah dipertahankan dan dimodifikasi, Anda perlu membuat pengujian unit untuk kode.

Anda menggunakan pengujian unit untuk menguji unit kode individual. Unit kode ini lebih kecil dari seluruh lapisan aplikasi. Biasanya, Anda menggunakan pengujian unit untuk memverifikasi apakah metode tertentu dalam kode Anda berakibat seperti yang Anda harapkan. Misalnya, Anda akan membuat pengujian unit untuk metode CreateContact() yang diekspos oleh kelas ContactManagerService.

Unit ini menguji pekerjaan aplikasi seperti jaring pengaman. Setiap kali Anda memodifikasi kode dalam aplikasi, Anda dapat menjalankan serangkaian pengujian unit untuk memeriksa apakah modifikasi merusak fungsionalitas yang ada. Pengujian unit membuat kode Anda aman untuk dimodifikasi. Pengujian unit membuat semua kode dalam aplikasi Anda lebih tahan terhadap perubahan.

Dalam iterasi ini, kami menambahkan pengujian unit ke aplikasi Contact Manager kami. Dengan begitu, dalam iterasi berikutnya, kita dapat menambahkan Grup Kontak ke aplikasi kita tanpa khawatir merusak fungsionalitas yang ada.

Catatan

Ada berbagai kerangka kerja pengujian unit termasuk NUnit, xUnit.net, dan MbUnit. Dalam tutorial ini, kami menggunakan kerangka kerja pengujian unit yang disertakan dengan Visual Studio. Namun, Anda bisa dengan mudah menggunakan salah satu kerangka kerja alternatif ini.

Apa yang Akan Diuji

Di dunia yang sempurna, semua kode Anda akan dicakup oleh pengujian unit. Di dunia yang sempurna, Anda akan memiliki jaring pengaman yang sempurna. Anda akan dapat memodifikasi baris kode apa pun dalam aplikasi Anda dan langsung mengetahuinya, dengan menjalankan pengujian unit Anda, apakah perubahan tersebut merusak fungsionalitas yang ada.

Namun, kita tidak hidup di dunia yang sempurna. Dalam praktiknya, saat menulis pengujian unit, Anda berkonsentrasi pada pengujian penulisan untuk logika bisnis Anda (misalnya, logika validasi). Secara khusus, Anda tidak menulis pengujian unit untuk logika akses data atau logika tampilan Anda.

Agar berguna, pengujian unit harus dijalankan dengan sangat cepat. Anda dapat dengan mudah mengakumulasi ratusan (atau bahkan ribuan) pengujian unit untuk aplikasi. Jika pengujian unit membutuhkan waktu lama untuk dijalankan, Anda akan menghindari menjalankannya. Dengan kata lain, pengujian unit yang berjalan lama tidak berguna untuk tujuan pengkodian sehari-hari.

Untuk alasan ini, Anda biasanya tidak menulis pengujian unit untuk kode yang berinteraksi dengan database. Menjalankan ratusan pengujian unit terhadap database langsung akan terlalu lambat. Sebagai gantinya, Anda meniru database Anda dan menulis kode yang berinteraksi dengan database tiruan (kami membahas meniru database di bawah).

Untuk alasan yang sama, Anda biasanya tidak menulis pengujian unit untuk dilihat. Untuk menguji tampilan, Anda harus memutar server web. Karena memutar server web adalah proses yang relatif lambat, membuat pengujian unit untuk tampilan Anda tidak disarankan.

Jika tampilan Anda berisi logika yang rumit, maka Anda harus mempertimbangkan untuk memindahkan logika ke metode Helper. Anda dapat menulis pengujian unit untuk metode Helper yang dijalankan tanpa memutar server web.

Catatan

Meskipun menulis pengujian untuk logika akses data atau melihat logika bukanlah ide yang baik saat menulis pengujian unit, pengujian ini bisa sangat berharga saat membangun pengujian fungsi atau integrasi.

Catatan

ASP.NET MVC adalah Web Forms View Engine. Meskipun Web Forms View Engine bergantung pada server web, mesin tampilan lain mungkin tidak.

Menggunakan Kerangka Kerja Objek Tiruan

Saat membangun pengujian unit, Anda hampir selalu perlu memanfaatkan kerangka kerja Objek Mock. Kerangka kerja Mock Object memungkinkan Anda membuat tiruan dan stub untuk kelas di aplikasi Anda.

Misalnya, Anda dapat menggunakan kerangka kerja Objek Mock untuk menghasilkan versi tiruan kelas repositori Anda. Dengan begitu, Anda dapat menggunakan kelas repositori tiruan alih-alih kelas repositori nyata dalam pengujian unit Anda. Menggunakan repositori tiruan memungkinkan Anda menghindari eksekusi kode database saat menjalankan pengujian unit.

Visual Studio tidak menyertakan kerangka kerja Objek Mock. Namun, ada beberapa kerangka kerja komersial dan sumber terbuka Mock Object yang tersedia untuk .NET framework:

Moq - Kerangka kerja ini tersedia di bawah lisensi BSD sumber terbuka. Anda dapat mengunduh Moq dari https://code.google.com/p/moq/.
Rhino Mocks - Kerangka kerja ini tersedia di bawah lisensi BSD sumber terbuka. Anda dapat mengunduh Rhino Mocks dari http://ayende.com/projects/rhino-mocks.aspx.
Typemock Isolator - Ini adalah kerangka kerja komersial. Anda dapat mengunduh versi uji coba dari http://www.typemock.com/.

Dalam tutorial ini, saya memutuskan untuk menggunakan Moq. Namun, Anda bisa dengan mudah menggunakan Rhino Mocks atau Typemock Isolator untuk membuat objek Mock untuk aplikasi Contact Manager.

Sebelum dapat menggunakan Moq, Anda harus menyelesaikan langkah-langkah berikut:

.
Sebelum Anda membuka zip unduhan, pastikan Anda mengklik kanan file dan klik tombol berlabel Buka Blokir (lihat Gambar 1).
Buka zip unduhan.
Tambahkan referensi ke rakitan Moq dengan mengklik kanan folder Referensi di proyek ContactManager.Tests dan memilih Tambahkan Referensi. Di bawah tab Telusuri, telusuri ke folder tempat Anda membuka zip Moq dan pilih rakitan Moq.dll. Klik tombol Ok.
Setelah Anda menyelesaikan langkah-langkah ini, folder Referensi Anda akan terlihat seperti Gambar 2.

Gambar 01: Membuka blokir Moq (Klik untuk melihat gambar ukuran penuh)

Gambar 02: Referensi setelah menambahkan Moq(Klik untuk melihat gambar ukuran penuh)

Membuat Pengujian Unit untuk Lapisan Layanan

Mari kita mulai dengan membuat serangkaian pengujian unit untuk lapisan layanan aplikasi Contact Manager kami. Kami akan menggunakan pengujian ini untuk memverifikasi logika validasi kami.

Buat folder baru bernama Model di proyek ContactManager.Tests. Selanjutnya, klik kanan folder Model dan pilih Tambahkan, Pengujian Baru. Dialog Tambahkan Pengujian Baru yang diperlihatkan di Gambar 3 muncul. Pilih templat Pengujian Unit dan beri nama pengujian baru Anda ContactManagerServiceTest.cs. Klik tombol OK untuk menambahkan pengujian baru Anda ke Proyek Pengujian Anda.

Catatan

Secara umum, Anda ingin struktur folder Proyek Pengujian Anda cocok dengan struktur folder proyek MVC ASP.NET Anda. Misalnya, Anda menempatkan pengujian pengontrol di folder Pengontrol, pengujian model di folder Model, dan sebagainya.

$Models\ContactManagerServiceTest.cs$

Gambar 03: Model\ContactManagerServiceTest.cs(Klik untuk melihat gambar ukuran penuh)

Awalnya, kami ingin menguji metode CreateContact() yang diekspos oleh kelas ContactManagerService. Kami akan membuat lima pengujian berikut:

CreateContact() - Pengujian bahwa CreateContact() mengembalikan nilai true saat Kontak yang valid diteruskan ke metode .
CreateContactRequiredFirstName() - Menguji bahwa pesan kesalahan ditambahkan ke status model saat Kontak dengan nama depan yang hilang diteruskan ke metode CreateContact().
CreateContactRequiredLastName() - Menguji bahwa pesan kesalahan ditambahkan ke status model saat Kontak dengan nama belakang yang hilang diteruskan ke metode CreateContact().
CreateContactInvalidPhone() - Menguji bahwa pesan kesalahan ditambahkan ke status model saat Kontak dengan nomor telepon yang tidak valid diteruskan ke metode CreateContact().
CreateContactInvalidEmail() - Menguji bahwa pesan kesalahan ditambahkan ke status model saat Kontak dengan alamat email yang tidak valid diteruskan ke metode CreateContact().

Pengujian pertama memverifikasi bahwa Kontak yang valid tidak menghasilkan kesalahan validasi. Pengujian yang tersisa memeriksa setiap aturan validasi.

Kode untuk pengujian ini terkandung dalam Daftar 1.

Daftar 1 - Models\ContactManagerServiceTest.cs

using System.Web.Mvc;
using ContactManager.Models;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Moq;

namespace ContactManager.Tests.Models
{
    [TestClass]
    public class ContactManagerServiceTest
    {
        private Mock<IContactManagerRepository> _mockRepository;
        private ModelStateDictionary _modelState;
        private IContactManagerService _service;

        [TestInitialize]
        public void Initialize()
        {
            _mockRepository = new Mock<IContactManagerRepository>();
            _modelState = new ModelStateDictionary();
            _service = new ContactManagerService(new ModelStateWrapper(_modelState), _mockRepository.Object);
        }

        [TestMethod]
        public void CreateContact()
        {
            // Arrange
            var contact = Contact.CreateContact(-1, "Stephen", "Walther", "555-5555", "steve@somewhere.com");

            // Act
            var result = _service.CreateContact(contact);
        
            // Assert
            Assert.IsTrue(result);
        }

        [TestMethod]
        public void CreateContactRequiredFirstName()
        {
            // Arrange
            var contact = Contact.CreateContact(-1, string.Empty, "Walther", "555-5555", "steve@somewhere.com");

            // Act
            var result = _service.CreateContact(contact);

            // Assert
            Assert.IsFalse(result);
            var error = _modelState["FirstName"].Errors[0];
            Assert.AreEqual("First name is required.", error.ErrorMessage);
        }

        [TestMethod]
        public void CreateContactRequiredLastName()
        {
            // Arrange
            var contact = Contact.CreateContact(-1, "Stephen", string.Empty, "555-5555", "steve@somewhere.com");

            // Act
            var result = _service.CreateContact(contact);

            // Assert
            Assert.IsFalse(result);
            var error = _modelState["LastName"].Errors[0];
            Assert.AreEqual("Last name is required.", error.ErrorMessage);
        }

        [TestMethod]
        public void CreateContactInvalidPhone()
        {
            // Arrange
            var contact = Contact.CreateContact(-1, "Stephen", "Walther", "apple", "steve@somewhere.com");

            // Act
            var result = _service.CreateContact(contact);

            // Assert
            Assert.IsFalse(result);
            var error = _modelState["Phone"].Errors[0];
            Assert.AreEqual("Invalid phone number.", error.ErrorMessage);
        }

        [TestMethod]
        public void CreateContactInvalidEmail()
        {
            // Arrange
            var contact = Contact.CreateContact(-1, "Stephen", "Walther", "555-5555", "apple");

            // Act
            var result = _service.CreateContact(contact);

            // Assert
            Assert.IsFalse(result);
            var error = _modelState["Email"].Errors[0];
            Assert.AreEqual("Invalid email address.", error.ErrorMessage);
        }
    }
}

Karena kami menggunakan kelas Kontak di Daftar 1, kami perlu menambahkan referensi ke Microsoft Entity Framework ke proyek Pengujian kami. Tambahkan referensi ke rakitan System.Data.Entity.

Daftar 1 berisi metode bernama Initialize() yang dihiasi dengan atribut [TestInitialize]. Metode ini dipanggil secara otomatis sebelum setiap pengujian unit dijalankan (disebut 5 kali tepat sebelum masing-masing pengujian unit). Metode Initialize() membuat repositori tiruan dengan baris kode berikut:

_mockRepository = new Mock<IContactManagerRepository>();

Baris kode ini menggunakan kerangka kerja Moq untuk menghasilkan repositori tiruan dari antarmuka IContactManagerRepository. Repositori tiruan digunakan alih-alih EntityContactManagerRepository yang sebenarnya untuk menghindari akses database saat setiap pengujian unit dijalankan. Repositori tiruan mengimplementasikan metode antarmuka IContactManagerRepository, tetapi metodenya tidak benar-benar melakukan apa pun.

Catatan

Saat menggunakan kerangka kerja Moq, ada perbedaan antara _mockRepository dan _mockRepository.Object. Yang pertama mengacu pada kelas Mock<IContactManagerRepository> yang berisi metode untuk menentukan bagaimana repositori tiruan akan bereaksi. Yang terakhir mengacu pada repositori tiruan aktual yang mengimplementasikan antarmuka IContactManagerRepository.

Repositori tiruan digunakan dalam metode Initialize() saat membuat instans kelas ContactManagerService. Semua pengujian unit individu menggunakan instans kelas ContactManagerService ini.

Daftar 1 berisi lima metode yang sesuai dengan masing-masing pengujian unit. Masing-masing metode ini dihiasi dengan atribut [TestMethod]. Saat Anda menjalankan pengujian unit, metode apa pun yang memiliki atribut ini dipanggil. Dengan kata lain, metode apa pun yang dihiasi dengan atribut [TestMethod] adalah pengujian unit.

Pengujian unit pertama, bernama CreateContact(), memverifikasi bahwa memanggil CreateContact() mengembalikan nilai true ketika instans yang valid dari kelas Kontak diteruskan ke metode . Pengujian membuat instans kelas Kontak, memanggil metode CreateContact(), dan memverifikasi bahwa CreateContact() mengembalikan nilai true.

Pengujian yang tersisa memverifikasi bahwa ketika metode CreateContact() dipanggil dengan Kontak yang tidak valid, maka metode mengembalikan false dan pesan kesalahan validasi yang diharapkan ditambahkan ke status model. Misalnya, pengujian CreateContactRequiredFirstName() membuat instans kelas Kontak dengan string kosong untuk properti FirstName-nya. Selanjutnya, metode CreateContact() dipanggil dengan Kontak yang tidak valid. Terakhir, pengujian memverifikasi bahwa CreateContact() mengembalikan false dan status model tersebut berisi pesan kesalahan validasi yang diharapkan "Nama depan diperlukan."

Anda dapat menjalankan pengujian unit di Daftar 1 dengan memilih opsi menu Uji, Jalankan, Semua Pengujian dalam Solusi (CTRL+R, A). Hasil pengujian ditampilkan di jendela Hasil Pengujian (lihat Gambar 4).

Gambar 04: Hasil Pengujian (Klik untuk melihat gambar ukuran penuh)

Membuat Pengujian Unit untuk Pengontrol

ASP. Aplikasi NETMVC mengontrol alur interaksi pengguna. Saat menguji pengontrol, Anda ingin menguji apakah pengontrol mengembalikan hasil tindakan yang tepat dan melihat data. Anda juga mungkin ingin menguji apakah pengontrol berinteraksi dengan kelas model dengan cara yang diharapkan.

Misalnya, Listing 2 berisi dua pengujian unit untuk metode Contact controller Create(). Pengujian unit pertama memverifikasi bahwa ketika Kontak yang valid diteruskan ke metode Create() lalu metode Create() mengalihkan ke tindakan Indeks. Dengan kata lain, ketika melewati Kontak yang valid, metode Create() harus mengembalikan RedirectToRouteResult yang mewakili tindakan Indeks.

Kami tidak ingin menguji lapisan layanan ContactManager saat menguji lapisan pengontrol. Oleh karena itu, kami mengejek lapisan layanan dengan kode berikut dalam metode Inisialisasi:

_service = new Mock();

Dalam pengujian unit CreateValidContact(), kami meniru perilaku memanggil metode createContact() lapisan layanan dengan baris kode berikut:

_service.Expect(s => s.CreateContact(contact)).Returns(true);

Baris kode ini menyebabkan layanan ContactManager tiruan mengembalikan nilai true ketika metode CreateContact() dipanggil. Dengan mengejek lapisan layanan, kita dapat menguji perilaku pengontrol tanpa perlu menjalankan kode apa pun di lapisan layanan.

Pengujian unit kedua memverifikasi bahwa tindakan Create() mengembalikan tampilan Buat saat kontak yang tidak valid diteruskan ke metode . Kami menyebabkan metode createContact() lapisan layanan mengembalikan nilai false dengan baris kode berikut:

_service.Expect(s => s.CreateContact(contact)).Returns(false);

Jika metode Create() berkinerja seperti yang kita harapkan maka metode tersebut harus mengembalikan tampilan Buat saat lapisan layanan mengembalikan nilai false. Dengan begitu, pengontrol dapat menampilkan pesan kesalahan validasi dalam tampilan Buat dan pengguna memiliki kesempatan untuk memperbaiki properti Kontak yang tidak valid tersebut.

Jika Anda berencana untuk membangun pengujian unit untuk pengontrol, Maka Anda perlu mengembalikan nama tampilan eksplisit dari tindakan pengontrol Anda. Misalnya, jangan kembalikan tampilan seperti ini:

return View();

Sebagai gantinya, kembalikan tampilan seperti ini:

kembalikan Tampilan("Buat");

Jika Anda tidak eksplisit saat mengembalikan tampilan, maka properti ViewResult.ViewName mengembalikan string kosong.

Daftar 2 - Controllers\ContactControllerTest.cs

using System.Web.Mvc;
using ContactManager.Controllers;
using ContactManager.Models;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Moq;

namespace ContactManager.Tests.Controllers
{
    [TestClass]
    public class ContactControllerTest
    {
        private Mock<IContactManagerService> _service;

        [TestInitialize]
        public void Initialize()
        {
            _service = new Mock<IContactManagerService>();
        }

        [TestMethod]
        public void CreateValidContact()
        {
            // Arrange
            var contact = new Contact();
            _service.Expect(s => s.CreateContact(contact)).Returns(true);
            var controller = new ContactController(_service.Object);
        
            // Act
            var result = (RedirectToRouteResult)controller.Create(contact);

            // Assert
            Assert.AreEqual("Index", result.RouteValues["action"]);
        }

        [TestMethod]
        public void CreateInvalidContact()
        {
            // Arrange
            var contact = new Contact();
            _service.Expect(s => s.CreateContact(contact)).Returns(false);
            var controller = new ContactController(_service.Object);

            // Act
            var result = (ViewResult)controller.Create(contact);

            // Assert
            Assert.AreEqual("Create", result.ViewName);
        }

    }
}

Ringkasan

Dalam perulangan ini, kami membuat pengujian unit untuk aplikasi Contact Manager kami. Kita dapat menjalankan pengujian unit ini kapan saja untuk memverifikasi bahwa aplikasi kita masih berperilaku dengan cara yang kita harapkan. Pengujian unit bertindak sebagai jaring pengaman untuk aplikasi kami yang memungkinkan kami memodifikasi aplikasi kami dengan aman di masa depan.

Kami membuat dua set pengujian unit. Pertama, kami menguji logika validasi kami dengan membuat pengujian unit untuk lapisan layanan kami. Selanjutnya, kami menguji logika kontrol alur kami dengan membuat pengujian unit untuk lapisan pengontrol kami. Saat menguji lapisan layanan kami, kami mengisolasi pengujian untuk lapisan layanan kami dari lapisan repositori kami dengan meniru lapisan repositori kami. Saat menguji lapisan pengontrol, kami mengisolasi pengujian kami untuk lapisan pengontrol kami dengan meniru lapisan layanan.

Dalam perulangan berikutnya, kami memodifikasi aplikasi Contact Manager sehingga mendukung Grup Kontak. Kami akan menambahkan fungsionalitas baru ini ke aplikasi kami menggunakan proses desain perangkat lunak yang disebut pengembangan berbasis pengujian.

Sebelumnya Berikutnya

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2023-07-13

Bagikan melalui

Iterasi #5 – Membuat pengujian unit (C#)

Membangun Manajemen Kontak ASP.NET Aplikasi MVC (C#)

Perulangan ini

Apa yang Akan Diuji

Menggunakan Kerangka Kerja Objek Tiruan

Membuat Pengujian Unit untuk Lapisan Layanan

Membuat Pengujian Unit untuk Pengontrol

Ringkasan

Saran dan Komentar

Sumber Daya Tambahan: