Mengapa Anda menulis unit-test untuk pengontrol?


22

Bagi saya ini adalah unit-test yang sama sekali tidak relevan dan saya tidak mengerti mengapa seseorang akan menghabiskan waktu menulisnya, karena ada nilai yang sangat kecil untuk diperoleh darinya. Saya akan tahu betul jika controller ini mengembalikan tipe yang diinginkan dengan mengeksekusi metode di browser. Sungguh, apakah Anda percaya tes diperlukan untuk ini dan mengapa?

public class ConstituencyControllerTests
{
    private ConstituencyController _constituencyController;
    private Mock<IConstituencyService> _IConstituencyServiceMock;

    public ConstituencyControllerTests() {
        _IConstituencyServiceMock = new Mock<IConstituencyService>();
    }

    [Test]
    public async Task I_Check_For_Return_Type_And_Result() {
        _constituencyController = new ConstituencyController( _IConstituencyServiceMock.Object );

        var result = await _constituencyController.Get();
        var content = ( (dynamic)result ).Content;

        Assert.IsEmpty( content );
        Assert.IsInstanceOf( typeof( System.Web.Http.Results.OkNegotiatedContentResult<IEnumerable<ListOfConstituencies>> ), result );
        _IConstituencyServiceMock.Verify( x => x.ListOfConstituencies(), Times.Once() );
    }
}


7
Jangan setuju dengan @gnat itu. Ini bukan tentang konstruksi bahasa, tetapi tentang jenis hasil yang dikembalikan oleh pengontrol. Meskipun mungkin memecah menjadi hal yang sama ketika Anda tidak memiliki hierarki warisan, itu menjadi binatang yang sama sekali berbeda ketika controller mengharapkan Leluhur dikembalikan, controller mengembalikan Person dan sekarang Person diubah untuk turun bukan dari Ancestor, tetapi PeopleAncestor ... Juga menjawab mengapa pengujian metode semacam itu mungkin merupakan ide yang bagus ...;) Tes unit dimaksudkan untuk mengetahui situasi di mana perubahan dalam satu hal c / akan merusak sesuatu yang lain.
Marjan Venema


Cenderung setuju, saya biasanya tidak menghabiskan banyak waktu untuk menguji titik masuk aplikasi. Ini seperti unit yang menguji metode utama aplikasi konsol. sangat masuk akal bagi saya.
Mvision

Jawaban:


29

Poin kunci mereka ada di sini:

Saya akan tahu betul jika controller ini mengembalikan tipe yang diinginkan dengan mengeksekusi metode di browser

Unit-tesing adalah tentang otomatisasi pengujian non-regresi unit kode sederhana, bukan Anda melihat diri Anda sendiri. Anda tidak ingin melakukannya sendiri selalu menguji unit dalam aplikasi Anda.

EDIT: Menambahkan komentar @anotherdave:

Ini tentang kemudahan penskalaan. Menguji satu pengontrol di browser mungkin OK; bagaimana dengan 10, 20, 50 pengendali? Anda akan menulis tes satu kali; Anda mungkin perlu memperbaruinya saat Anda mengganti controller, yang merupakan overhead. Tetapi seberapa sering Anda menyebarkan? Tentunya pemeriksaan manual setiap kali ada lebih banyak overhead yang tes

Sebagai alternatif untuk jawaban @ Vladislav , unit testing benar-benar semuanya bisa menjadi berlebihan, dan benar-benar tidak diinginkan. Jika Anda membutuhkan sesuatu yang lebih ringan, Anda dapat melakukan pengujian non-regresi tingkat tinggi menggunakan Selenium. Tentunya Anda akan mendapatkan cakupan yang lebih sedikit daripada pengujian unit, tetapi Anda bisa mendapatkan cakupan yang dapat dinaikkan yang membutuhkan biaya lebih sedikit waktu untuk melakukan pengujian unit dan lebih fleksibel.

Yaitu, jika Anda menguji semua yang Anda miliki untuk memperbarui satu atau lebih tes setiap kali Anda memodifikasi elemen sederhana.


4
Juga untuk menambahkan kembali: I would know perfectly well if this controller returned the wanted type by executing the method in a browser.- ini tentang kemudahan penskalaan. Menguji satu pengontrol di browser mungkin OK; bagaimana dengan 10, 20, 50 pengendali? Anda akan menulis tes satu kali; Anda mungkin perlu memperbaruinya saat Anda mengganti controller, yang merupakan overhead. Tetapi seberapa sering Anda menyebarkan ? Tentunya pemeriksaan manual setiap kali ada lebih banyak overhead yang tes.
anotherdave

"Unit-tesing adalah tentang otomatisasi" - Benar, namun demikian juga pengujian integrasi (Selenium / Webdriver / dll.). Saya tidak berpikir itu perlu jadi potong dan keringkan bahwa unit test lebih cepat diimplementasikan daripada tes integrasi. Banyak hal tergantung pada pendekatan, namun jika mendapatkan unit test yang efektif membutuhkan banyak selusin layanan dan panggilan yang dibuat untuk masing-masingnya, sebuah tes integrasi mungkin lebih cepat untuk diimplementasikan dan lebih sederhana untuk dipertahankan (walaupun umumnya jauh lebih lambat untuk dijalankan, ya) . Intinya, banyak tergantung pada konteks, dan kompleksitas kode yang diuji.
Agustus

@anotherdave komentar ditambahkan
Walfrat

@aroth poin saya adalah kebalikannya, unit penuh menguji kode adalah sesuatu yang membutuhkan banyak waktu dan membuat kode sangat sulit untuk diubah tanpa harus melakukan beberapa unit test untuk diubah. Tes integrasi lebih ringan. Tentu saja Anda ingin unit test sesuatu yang sangat kompleks, tetapi itu bukan karena Anda unit menguji bagian itu, bahwa Anda harus menguji unit semuanya. Lagi-lagi kita melihat orang mencari peluru perak di tempat dia tidak ada.
Walfrat

24

Mengapa Anda menulis unit-test untuk pengontrol?

Karena tanpa mengetahui konteksnya Anda tidak dapat mengatakan dengan pasti apakah Anda perlu menguji ini atau itu. Berikut adalah beberapa alasan, mengapa Anda mungkin ingin menguji pengontrol:

  • controller mungkin berisi logika kabel layanan yang kompleks, yang rawan kesalahan. Layanan itu sendiri mungkin bekerja dengan baik itu adalah hasil yang ingin Anda uji dan untuk beberapa alasan Anda dianggap tidak memasukkan lapisan orkestrasi ke dalam aplikasi Anda
  • pengendali Anda mengandung logika bisnis yang SELURUH dari aplikasi dan pengendali sebenarnya adalah semua yang BISA Anda uji (tolong jangan berpura-pura sepanjang hidup Anda bekerja dengan basis kode yang ideal, ADA basis kode seperti itu, percayalah)
  • tim Anda terdiri dari 99% genius dan 1% dari rata-rata orang dan Anda ingin menjaga 1% dari bug dalam gaji mereka

2
Saya akan menambahkan: "Anda tidak dapat melihat siapa yang di masa depan akan menyingkirkan proyek, dan tes adalah bagian dari kode yang didokumentasikan sendiri"
Laiv

4
Ke titik tengah, proyek yang dibuat tanpa pengujian dalam pikiran mungkin tidak dapat diuji dengan cara lain selain tes pengontrol tanpa mengejek. Saya bekerja dengan tim C # yang memiliki proyek yang tepat dalam perawatan mereka, sehingga mereka menulis tes pengontrol sampai mereka dapat menambahkan struktur yang diperlukan (antarmuka, dll.) Untuk dapat melakukan pengujian yang lebih baik.
Wayne Conrad

1

Saya sepenuhnya setuju dengan OP.

Tes unit untuk pengontrol tidak ada gunanya. Anda menguji pengendali Anda secara implisit melalui tes regresi (menggunakan Selenium misalnya).

Anda harus TDD semua komponen / objek yang digunakan pengontrol dan menjaga pengontrol setipis mungkin. Kemudian semuanya diuji dengan benar. Yang ingin Anda yakini adalah semuanya bekerja dengan baik bersama saat melakukan permintaan web. Itu uji regresi.


Mungkin memang begitu, tapi itu bukan jawaban untuk pertanyaan itu. Sebenarnya, ini adalah argumen yang menentang penggunaan unit test di sini.
JᴀʏMᴇᴇ

Saya pikir saya menjawab pertanyaan, "Apakah Anda percaya tes diperlukan untuk ini dan mengapa?"
winkbrace

Ya, saya pikir @winkbrace dan saya berbagi pemikiran yang sama tentang ini. Tapi saya juga percaya ini adalah diskusi tentang apa yang harus Anda uji unit dan tidak. Saya pikir orang terlalu banyak menguji dan hal-hal yang "salah". dalam contoh saya, menguji controller memberikan nilai yang sangat kecil karena sangat tipis dan mudah-mudahan memiliki tes seputar layanan. Semua jawaban di sini bermakna dan memiliki poin bagus tetapi tidak mungkin untuk menandai sebagai jawaban yang benar.
hiasan

Logika pengontrol dapat diuji menggunakan tes integrasi otomatis, terpisah dan berbeda dari tes unit untuk masing-masing komponen.
KevBurnsJr

-1: Tes unit untuk pengontrol mungkin tidak ada gunanya. Pengendali adalah tentang transformasi, tetapi kadang-kadang transformasi itu sendiri kompleks dan pengembang mungkin ingin membahasnya. Saya juga berpikir bahwa unit-test 1) pada akhirnya tentang memvalidasi implementasi, belum tentu memvalidasi perilaku tingkat tinggi, dan 2) seharusnya sangat cepat . Kedua kualitas membuat unit-test jauh lebih berguna selama waktu implementasi; dengan kata lain, mereka pada akhirnya adalah alat pengembang, dan secara kebetulan merupakan cara untuk memvalidasi kualitas produk.
rsenna
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.