Haruskah hasil tes unit diharapkan di-hardcode?

Haruskah hasil yang diharapkan dari unit test hardcode, atau dapatkah mereka bergantung pada variabel yang diinisialisasi? Apakah hasil hardcoded atau dihitung meningkatkan risiko memperkenalkan kesalahan dalam unit test? Apakah ada faktor lain yang belum saya pertimbangkan?

Misalnya, yang mana dari dua ini adalah format yang lebih dapat diandalkan?

[TestMethod]
public void GetPath_Hardcoded()
{
    MyClass target = new MyClass("fields", "that later", "determine", "a folder");
    string expected = "C:\\Output Folder\\fields\\that later\\determine\\a folder";
    string actual = target.GetPath();
    Assert.AreEqual(expected, actual,
        "GetPath should return a full directory path based on its fields.");
}

[TestMethod]
public void GetPath_Softcoded()
{
    MyClass target = new MyClass("fields", "that later", "determine", "a folder");
    string expected = "C:\\Output Folder\\" + string.Join("\\", target.Field1, target.Field2, target.Field3, target.Field4);
    string actual = target.GetPath();
    Assert.AreEqual(expected, actual,
        "GetPath should return a full directory path based on its fields.");
}

EDIT 1: Menanggapi jawaban DXM, apakah opsi 3 solusi yang disukai?

[TestMethod]
public void GetPath_Option3()
{
    string field1 = "fields";
    string field2 = "that later";
    string field3 = "determine";
    string field4 = "a folder";
    MyClass target = new MyClass(field1, field2, field3, field4);
    string expected = "C:\\Output Folder\\" + string.Join("\\", field1, field2, field3, field4);
    string actual = target.GetPath();
    Assert.AreEqual(expected, actual,
        "GetPath should return a full directory path based on its fields.");
}

Saya pikir hasil nilai yang dihitung menghasilkan kasus uji yang lebih kuat dan fleksibel. Juga dengan menggunakan nama variabel yang baik dalam ekspresi yang menghitung hasil yang diharapkan, jauh lebih jelas dari mana hasil yang diharapkan berasal dari tempat pertama.

Karena itu, dalam contoh spesifik Anda, saya TIDAK akan mempercayai metode "Softcoded" karena menggunakan SUT Anda (sistem yang diuji) sebagai input untuk perhitungan Anda. Jika ada bug di MyClass di mana bidang tidak disimpan dengan benar, pengujian Anda akan benar-benar lulus karena perhitungan nilai yang Anda harapkan akan menggunakan string yang salah seperti target.GetPath ().

Saran saya adalah untuk menghitung nilai yang diharapkan di tempat yang masuk akal, tetapi pastikan bahwa perhitungan tidak bergantung pada kode apa pun dari SUT itu sendiri.

Sebagai Tanggapan atas pembaruan OP terhadap respons saya:

Ya, berdasarkan pengetahuan saya tetapi pengalaman yang agak terbatas dalam melakukan TDD, saya akan memilih opsi # 3.

Bagaimana jika kodenya adalah sebagai berikut:

MyTarget() // constructor
{
   Field1 = Field2 = Field3 = Field4 = "";
}

Contoh kedua Anda tidak akan menangkap bug, tetapi contoh pertama akan melakukannya.

Secara umum, saya akan merekomendasikan terhadap soft-coding karena dapat menyembunyikan bug. Sebagai contoh:

string expected = "C:\\Output Folder" + string.Join("\\", target.Field1, target.Field2, target.Field3, target.Field4);

Bisakah Anda menemukan masalahnya? Anda tidak akan membuat kesalahan yang sama dalam versi kode-keras. Lebih sulit untuk mendapatkan perhitungan yang benar daripada nilai-nilai yang dikodekan. Itu sebabnya saya lebih suka bekerja dengan nilai-nilai kode-keras daripada yang kode-lunak.

Tapi ada beberapa pengecualian. Bagaimana jika kode Anda harus dijalankan di Windows dan Linux? Path tidak hanya harus berbeda, tetapi juga harus menggunakan separator path yang berbeda! Menghitung jalur menggunakan fungsi yang abstrak perbedaan antara mungkin masuk akal dalam konteks itu.

Menurut pendapat saya, kedua saran Anda kurang ideal. Cara ideal untuk melakukannya adalah yang ini:

[TestMethod]
public void GetPath_Hardcoded()
{
    const string f1 = "fields"; const string f2 = "that later"; 
    const string f3 = "determine"; const string f4 = "a folder";

    MyClass target = new MyClass( f1, f2, f3, f4 );
    string expected = "C:\\Output Folder\\" + string.Join("\\", f1, f2, f3, f4);
    string actual = target.GetPath();
    Assert.AreEqual(expected, actual,
        "GetPath should return a full directory path based on its fields.");
}

Dengan kata lain, tes harus bekerja secara eksklusif berdasarkan input dan output objek, dan tidak didasarkan pada keadaan internal objek. Objek harus diperlakukan sebagai kotak hitam. (Saya mengabaikan masalah lain, seperti ketidaksesuaian menggunakan string. Bergabunglah dengan bukan Path.Combine, karena ini hanya sebuah contoh.)

Ada dua aspek dalam diskusi:

1. Menggunakan target itu sendiri untuk test case
Pertanyaan pertama adalah harus / dapatkah Anda menggunakan kelas itu sendiri untuk mengandalkan dan menyelesaikan bagian dari pekerjaan dalam test stub? - Jawabannya adalah TIDAK karena, secara umum, Anda tidak boleh membuat asumsi tentang kode yang Anda uji. Jika ini tidak dilakukan dengan benar, seiring waktu bug menjadi kebal terhadap beberapa unit pengujian.

2. Hardcoding
haruskah Anda kode keras ? Sekali lagi jawabannya adalah Tidak . karena seperti perangkat lunak apa pun - pengkodean keras informasi menjadi sulit ketika berbagai hal berevolusi. Misalnya, ketika Anda ingin jalur di atas dimodifikasi lagi, Anda harus menulis unit tambahan atau terus memodifikasi. Metode yang lebih baik adalah menyimpan input dan tanggal evaluasi yang berasal dari konfigurasi terpisah yang dapat dengan mudah disesuaikan.

misalnya di sini adalah bagaimana saya akan memperbaiki rintisan tes.

[TestMethod]
public void GetPath_Tested(int CaseId)
{
    testParams = GetTestConfig(caseID,"testConfig.txt"); // some wrapper that does read line and chops the field. 
    MyClass target = new MyClass(testParams.field1, testParams.field2);
    string expected = testParams.field5;
    string actual = target.GetPath();
    Assert.AreEqual(expected, actual,
        "GetPath should return a full directory path based on its fields.");
}

Ada banyak konsep yang mungkin, buat beberapa contoh untuk melihat perbedaannya

[TestMethod]
public void GetPath_Softcoded()
{
    //Hardcoded since you want to see what you expect is most simple and clear
    string expected = "C:\\Output Folder\\fields\\that later\\determine\\a folder";

    //If this test should also use a mocked filesystem it might be that you want to use
    //some base directory, which you could set in the setUp of your test class
    //that is usefull if you you need to run the same test on different environments
    string expected = this.outputPath + "fields\\that later\\determine\\a folder";


    //another readable way could be interesting if you have difficult variables needed to test
    string fields = "fields";
    string thatLater = "that later";
    string determine = "determine";
    string aFolder = "a folder";
    string expected = this.outputPath + fields + "\\" + thatLater + "\\" + determine + "\\" + aFolder;
    MyClass target = new MyClass(fields, thatLater, determine, aFolder);

    //in general testing with real words is not needed, so code could be shorter on that
    //for testing difficult folder names you write a separate test anyway
    string f1 = "f1";
    string f2 = "f2";
    string f3 = "f3";
    string f4 = "f4";
    string expected = this.outputPath + f1 + "\\" + f2 + "\\" + f3 + "\\" + f4;
    MyClass target = new MyClass(f1, f2, f3, f4);

    //so here we start to see a structure, it looks more like an array of fields
    //so what would make testing more interesting with lots of variables is the use of a data provider
    //the data provider will re-use your test with many different kinds of inputs. That will reduce the amount of duplication of code for testing
    //http://msdn.microsoft.com/en-us/library/ms182527.aspx


    The part where you compare already seems correct
    MyClass target = new MyClass(fields, thatLater, determine, aFolder);

    string actual = target.GetPath();
    Assert.AreEqual(expected, actual,
        "GetPath should return a full directory path based on its fields.");
}

Untuk meringkas: Secara umum tes hardcoded pertama Anda paling masuk akal bagi saya karena sederhana, langsung ke titik dll. Jika Anda memulai hardcoding jalan terlalu banyak hanya memasukkannya dalam metode setup.

Untuk pengujian terstruktur lebih lanjut di masa depan saya akan pergi untuk memeriksa sumber data sehingga Anda bisa menambahkan lebih banyak baris data jika Anda membutuhkan lebih banyak situasi pengujian.

Kerangka kerja pengujian modern memungkinkan Anda memberikan parameter untuk metode Anda. Saya akan memanfaatkannya:

[TestCase("fields", "that later", "determine", "a folder", @"C:\Output Folder\fields\that later\determine\a folder")]
public void GetPathShouldReturnFullDirectoryPathBasedOnItsFields(
    string field1, string field2, string field3, string field,
    string expected)
{
    MyClass target = new MyClass(field1, field2, field3, field4);
    string actual = target.GetPath();
    Assert.AreEqual(expected, actual,
        "GetPath should return a full directory path based on its fields.");
}

Ada beberapa keuntungan untuk ini, dalam pandangan saya:

1. Pengembang sering tergoda untuk menyalin bagian kode yang tampaknya sederhana dari SUT mereka ke dalam unit test mereka. Seperti yang ditunjukkan Winston , mereka masih bisa memiliki bug rumit yang tersembunyi di dalamnya. "Hard-coding" hasil yang diharapkan membantu menghindari situasi di mana kode pengujian Anda salah karena alasan yang sama bahwa kode asli Anda salah. Tetapi jika perubahan dalam persyaratan memaksa Anda untuk melacak string kode keras yang tertanam di dalam lusinan metode pengujian, itu bisa mengganggu. Memiliki semua nilai yang dikodekan di satu tempat, di luar logika pengujian Anda, memberi Anda yang terbaik dari kedua dunia.
2. Anda dapat menambahkan tes untuk input berbeda dan output yang diharapkan dengan satu baris kode. Ini mendorong Anda untuk menulis lebih banyak tes, sambil menjaga kode tes Anda KERING dan mudah dirawat. Saya menemukan bahwa karena sangat murah untuk menambahkan tes, pikiran saya terbuka untuk kasus-kasus tes baru yang tidak akan saya pikirkan jika saya harus menulis metode yang sama sekali baru untuk mereka. Misalnya, perilaku apa yang akan saya harapkan jika salah satu input memiliki titik di dalamnya? Sebuah backslash? Bagaimana jika ada yang kosong? Atau ruang kosong? Atau mulai atau berakhir dengan spasi putih?
3. Kerangka pengujian akan memperlakukan setiap TestCase sebagai pengujiannya sendiri, bahkan memasukkan input dan output yang disediakan ke dalam nama tes. Jika semua TestCases lulus tetapi satu, sangat mudah untuk melihat yang rusak dan bagaimana itu berbeda dari yang lainnya.