คุณทดสอบวิธีส่วนตัวกับ NUnit ได้อย่างไร?

ฉันสงสัยว่าจะใช้ NUnit อย่างไรให้ถูกต้อง ขั้นแรกฉันสร้างโครงการทดสอบแยกต่างหากที่ใช้โครงการหลักของฉันเป็นข้อมูลอ้างอิง แต่ในกรณีนั้นฉันไม่สามารถทดสอบวิธีส่วนตัวได้ ฉันเดาว่าฉันต้องใส่รหัสทดสอบลงในรหัสหลักของฉัน?! - นั่นดูเหมือนจะไม่ใช่วิธีที่ถูกต้อง (ฉันไม่ชอบแนวคิดในการจัดส่งรหัสที่มีการทดสอบ)

คุณทดสอบวิธีส่วนตัวกับ NUnit ได้อย่างไร?

โดยทั่วไปการทดสอบหน่วยจะกล่าวถึงอินเทอร์เฟซสาธารณะของคลาสโดยใช้ทฤษฎีที่ว่าการใช้งานนั้นไม่มีสาระสำคัญตราบใดที่ผลลัพธ์ถูกต้องจากมุมมองของลูกค้า

ดังนั้น NUnit จึงไม่มีกลไกในการทดสอบสมาชิกที่ไม่ใช่สาธารณะ

แม้ว่าฉันยอมรับว่าจุดเน้นของการทดสอบหน่วยควรเป็นอินเทอร์เฟซสาธารณะ แต่คุณจะได้รับการแสดงผลโค้ดที่ละเอียดกว่ามากหากคุณทดสอบวิธีการส่วนตัวด้วย กรอบการทดสอบ MS อนุญาตให้ใช้งานผ่าน PrivateObject และ PrivateType NUnit ไม่ทำ สิ่งที่ฉันทำแทนคือ:

private MethodInfo GetMethod(string methodName)
{
    if (string.IsNullOrWhiteSpace(methodName))
        Assert.Fail("methodName cannot be null or whitespace");

    var method = this.objectUnderTest.GetType()
        .GetMethod(methodName, BindingFlags.NonPublic | BindingFlags.Instance);

    if (method == null)
        Assert.Fail(string.Format("{0} method not found", methodName));

    return method;
}

วิธีนี้หมายความว่าคุณไม่จำเป็นต้องประนีประนอมกับการห่อหุ้มเพื่อให้สามารถทดสอบได้ โปรดทราบว่าคุณจะต้องแก้ไข BindingFlags ของคุณหากคุณต้องการทดสอบวิธีการคงที่ส่วนตัว ตัวอย่างข้างต้นเป็นเพียงตัวอย่างวิธีการ

รูปแบบทั่วไปสำหรับการเขียนการทดสอบหน่วยคือการทดสอบวิธีการสาธารณะเท่านั้น

หากคุณพบว่าคุณมีวิธีการส่วนตัวมากมายที่คุณต้องการทดสอบโดยปกตินี่เป็นสัญญาณว่าคุณควรปรับรหัสของคุณใหม่

เป็นเรื่องผิดที่จะเผยแพร่วิธีการเหล่านี้ต่อสาธารณะในชั้นเรียนที่พวกเขาอาศัยอยู่ นั่นจะเป็นการทำลายสัญญาที่คุณต้องการให้คลาสนั้นมี

อาจเป็นเรื่องถูกต้องที่จะย้ายพวกเขาไปยังชั้นเรียนผู้ช่วยเหลือและทำให้พวกเขาเป็นสาธารณะที่นั่น API ของคุณอาจไม่เปิดเผยคลาสนี้

วิธีนี้รหัสทดสอบจะไม่ผสมกับรหัสสาธารณะของคุณ

ปัญหาที่คล้ายกันคือการทดสอบคลาสส่วนตัวเช่น คลาสที่คุณไม่ได้ส่งออกจากแอสเซมบลีของคุณ ในกรณีนี้คุณสามารถทำให้ชุดรหัสทดสอบของคุณเป็นเพื่อนของชุดรหัสการผลิตโดยใช้แอตทริบิวต์ InternalsVisibleTo

เป็นไปได้ที่จะทดสอบวิธีการส่วนตัวโดยการประกาศชุดทดสอบของคุณเป็นกลุ่มเพื่อนของชุดประกอบเป้าหมายที่คุณกำลังทดสอบ ดูลิงค์ด้านล่างสำหรับรายละเอียด:

http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx

สิ่งนี้มีประโยชน์เนื่องจากส่วนใหญ่จะแยกรหัสทดสอบของคุณออกจากรหัสการผลิตของคุณ ฉันไม่เคยใช้วิธีนี้ด้วยตัวเองเพราะฉันไม่เคยพบความจำเป็น ฉันคิดว่าคุณสามารถใช้เพื่อทดลองและทดสอบกรณีทดสอบที่รุนแรงซึ่งคุณไม่สามารถทำซ้ำในสภาพแวดล้อมการทดสอบของคุณเพื่อดูว่าโค้ดของคุณจัดการอย่างไร

ดังที่ได้กล่าวไปแล้วคุณไม่จำเป็นต้องทดสอบวิธีการส่วนตัว คุณมากกว่าที่ชอบต้องการ refactor โค้ดของคุณเป็นหน่วยการสร้างขนาดเล็ก เคล็ดลับอย่างหนึ่งที่อาจช่วยคุณได้เมื่อคุณมาที่ refactor ก็คือลองคิดถึงโดเมนที่ระบบของคุณเกี่ยวข้องและคิดถึงวัตถุ 'ของจริง' ที่อาศัยอยู่ในโดเมนนี้ อ็อบเจ็กต์ / คลาสของคุณในระบบของคุณควรเกี่ยวข้องโดยตรงกับอ็อบเจ็กต์จริงซึ่งจะช่วยให้คุณสามารถแยกพฤติกรรมที่แน่นอนที่อ็อบเจ็กต์ควรมีและจำกัดความรับผิดชอบของอ็อบเจ็กต์ด้วย ซึ่งหมายความว่าคุณกำลังปรับโครงสร้างใหม่อย่างมีเหตุผลแทนที่จะเป็นเพียงเพื่อให้สามารถทดสอบวิธีการเฉพาะได้ คุณจะสามารถทดสอบพฤติกรรมของวัตถุได้

หากคุณยังรู้สึกว่าจำเป็นต้องทดสอบภายในคุณอาจต้องการพิจารณาการเยาะเย้ยในการทดสอบของคุณเนื่องจากคุณชอบที่จะมุ่งเน้นไปที่โค้ดชิ้นเดียว การเยาะเย้ยคือการที่คุณฉีดการอ้างอิงวัตถุเข้าไป แต่วัตถุที่ฉีดไม่ใช่วัตถุ 'ของจริง' หรือวัตถุที่ใช้ในการผลิต เป็นวัตถุจำลองที่มีลักษณะการทำงานแบบฮาร์ดโค้ดเพื่อให้ง่ายต่อการแยกข้อผิดพลาดทางพฤติกรรม Rhino.Mocks เป็นกรอบการเยาะเย้ยที่ได้รับความนิยมซึ่งจะเขียนวัตถุให้คุณเป็นหลัก TypeMock.NET (ผลิตภัณฑ์เชิงพาณิชย์ที่มีรุ่นชุมชน) เป็นเฟรมเวิร์กที่มีประสิทธิภาพมากขึ้นซึ่งสามารถจำลองวัตถุ CLR ได้ มีประโยชน์มากสำหรับการล้อเลียนคลาส SqlConnection / SqlCommand และ Datatable เช่นเมื่อทดสอบแอปฐานข้อมูล

หวังว่าคำตอบนี้จะให้ข้อมูลเพิ่มเติมเกี่ยวกับการทดสอบหน่วยโดยทั่วไปและช่วยให้คุณได้ผลลัพธ์ที่ดีขึ้นจากการทดสอบหน่วย

ฉันชอบที่จะมีความสามารถในการทดสอบวิธีการส่วนตัว เมื่อ xUnit เริ่มต้นมีวัตถุประสงค์เพื่อทดสอบฟังก์ชันการทำงานหลังจากเขียนโค้ดแล้ว การทดสอบอินเทอร์เฟซเพียงพอสำหรับจุดประสงค์นี้

การทดสอบหน่วยได้พัฒนาไปสู่การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ การมีความสามารถในการทดสอบวิธีการทั้งหมดมีประโยชน์สำหรับแอปพลิเคชันนั้น

คำถามนี้อยู่ในช่วงหลายปีที่ผ่านมา แต่ฉันคิดว่าฉันจะแบ่งปันวิธีการทำเช่นนี้

โดยทั่วไปฉันมีคลาสทดสอบหน่วยทั้งหมดของฉันในแอสเซมบลีซึ่งกำลังทดสอบในเนมสเปซ 'UnitTest' ด้านล่าง 'ค่าเริ่มต้น' สำหรับแอสเซมบลีนั้น - ไฟล์ทดสอบแต่ละไฟล์จะถูกรวมไว้ใน:

#if DEBUG

...test code...

#endif

บล็อกและทั้งหมดนั้นหมายความว่า a) ไม่มีการแจกจ่ายในรุ่นและ b) ฉันสามารถใช้internal/ Friendการประกาศระดับโดยไม่ต้องกระโดดห่วง

สิ่งอื่นที่นำเสนอซึ่งเกี่ยวข้องกับคำถามนี้มากขึ้นคือการใช้partialคลาสซึ่งสามารถใช้เพื่อสร้างพร็อกซีสำหรับการทดสอบเมธอดส่วนตัวตัวอย่างเช่นเพื่อทดสอบบางอย่างเช่นเมธอดส่วนตัวที่ส่งคืนค่าจำนวนเต็ม:

public partial class TheClassBeingTested
{
    private int TheMethodToBeTested() { return -1; }
}

ในคลาสหลักของแอสเซมบลีและคลาสทดสอบ:

#if DEBUG

using NUnit.Framework;

public partial class TheClassBeingTested
{
    internal int NUnit_TheMethodToBeTested()
    {
        return TheMethodToBeTested();
    }
}

[TestFixture]
public class ClassTests
{
    [Test]
    public void TestMethod()
    {
        var tc = new TheClassBeingTested();
        Assert.That(tc.NUnit_TheMethodToBeTested(), Is.EqualTo(-1));
    }
}

#endif

เห็นได้ชัดว่าคุณต้องตรวจสอบให้แน่ใจว่าคุณไม่ได้ใช้วิธีนี้ในขณะที่กำลังพัฒนาแม้ว่ารุ่น Release จะระบุว่ามีการเรียกใช้โดยไม่ได้ตั้งใจในไม่ช้าหากคุณทำ

เป้าหมายหลักของการทดสอบหน่วยคือการทดสอบวิธีการสาธารณะของชั้นเรียน วิธีสาธารณะเหล่านั้นจะใช้วิธีส่วนตัวเหล่านั้น การทดสอบหน่วยจะทดสอบพฤติกรรมของสิ่งที่เปิดเผยต่อสาธารณะ

ขออภัยหากสิ่งนี้ไม่สามารถตอบคำถามได้ แต่วิธีแก้ปัญหาเช่นการใช้การไตร่ตรองคำสั่ง #if #endif หรือการแสดงวิธีการส่วนตัวไม่สามารถแก้ปัญหาได้ อาจมีสาเหตุหลายประการที่ไม่ทำให้เมธอดส่วนตัวมองเห็นได้ ... จะเกิดอะไรขึ้นถ้าเป็นรหัสการผลิตและทีมงานจะเขียนการทดสอบหน่วยย้อนหลังเป็นต้น

สำหรับโปรเจ็กต์ที่ฉันกำลังทำงานกับ MSTest เท่านั้น (น่าเศร้า) ดูเหมือนจะมีวิธีการใช้ accessors เพื่อทดสอบหน่วยวิธีส่วนตัว

คุณไม่ได้ทดสอบฟังก์ชันส่วนตัว มีหลายวิธีในการใช้การสะท้อนเพื่อเข้าสู่วิธีการและคุณสมบัติส่วนตัว แต่นั่นไม่ใช่เรื่องง่ายเลยและฉันไม่แนะนำให้ปฏิบัติเช่นนี้

คุณไม่ควรทดสอบสิ่งที่ไม่ใช่สาธารณะ

หากคุณมีวิธีการและคุณสมบัติภายในคุณควรพิจารณาเปลี่ยนเป็นสาธารณะหรือส่งการทดสอบของคุณกับแอป (สิ่งที่ฉันไม่เห็นว่าเป็นปัญหาจริงๆ)

หากลูกค้าของคุณสามารถเรียกใช้ Test-Suite ได้และเห็นว่ารหัสที่คุณส่งนั้น "ใช้งานได้จริง" ฉันไม่เห็นว่านี่เป็นปัญหา (ตราบใดที่คุณไม่ให้ IP ของคุณผ่านทางนี้) สิ่งที่ฉันรวมไว้ในทุกรุ่น ได้แก่ รายงานการทดสอบและรายงานความครอบคลุมของรหัส

ในทางทฤษฎีของการทดสอบหน่วยควรทดสอบสัญญาเท่านั้น กล่าวคือเฉพาะสมาชิกสาธารณะของชั้นเรียน แต่ในทางปฏิบัตินักพัฒนามักต้องการทดสอบสมาชิกภายใน - และมันก็ไม่เลว ใช่มันขัดกับทฤษฎี แต่ในทางปฏิบัติบางครั้งก็มีประโยชน์

ดังนั้นหากคุณต้องการทดสอบสมาชิกภายในจริงๆคุณสามารถใช้วิธีใดวิธีหนึ่งต่อไปนี้:

1. ทำให้สมาชิกของคุณเป็นสาธารณะ ในหนังสือหลายเล่มผู้เขียนแนะนำวิธีนี้เป็นเรื่องง่าย
2. คุณสามารถทำให้คุณเป็นสมาชิกภายในและเพิ่มInternalVisibleToเพื่อ assebly
3. คุณสามารถกำหนดให้สมาชิกชั้นเรียนได้รับการปกป้องและสืบทอดชั้นเรียนทดสอบของคุณจากชั้นทดสอบของคุณ

ตัวอย่างโค้ด (รหัสหลอก):

public class SomeClass
{
    protected int SomeMethod() {}
}
[TestFixture]
public class TestClass : SomeClass{

    protected void SomeMethod2() {}
    [Test]
    public void SomeMethodTest() { SomeMethod2(); }
}

คุณสามารถทำให้วิธีการของคุณได้รับการป้องกันภายในจากนั้นใช้ assembly: InternalsVisibleTo("NAMESPACE") กับเนมสเปซการทดสอบของคุณ

ดังนั้นไม่! คุณไม่สามารถเข้าถึงเมธอดส่วนตัวได้ แต่นี่เป็นวิธีแก้ปัญหา

ฉันจะทำให้แพ็กเกจเมธอดส่วนตัวมองเห็นได้ วิธีนี้จะทำให้คุณเก็บไว้เป็นส่วนตัวพอสมควรในขณะที่ยังสามารถทดสอบวิธีการเหล่านั้นได้ ฉันไม่เห็นด้วยกับคนที่บอกว่าอินเทอร์เฟซสาธารณะเป็นสิ่งเดียวที่ควรทดสอบ มักจะมีโค้ดที่สำคัญมากในเมธอดส่วนตัวที่ไม่สามารถทดสอบได้อย่างถูกต้องโดยใช้เฉพาะอินเทอร์เฟซภายนอกเท่านั้น

ดังนั้นจึงเป็นเรื่องยากหากคุณสนใจเพิ่มเติมเกี่ยวกับรหัสที่ถูกต้องหรือการซ่อนข้อมูล ฉันจะบอกว่าการมองเห็นแพ็กเกจเป็นการประนีประนอมที่ดีเนื่องจากในการเข้าถึงวิธีการเหล่านั้นใครบางคนจะต้องจัดชั้นเรียนไว้ในแพ็คเกจของคุณ นั่นควรทำให้พวกเขาคิดทบทวนอีกครั้งว่านั่นเป็นสิ่งที่ควรทำจริงๆหรือไม่

ฉันเป็นคน Java btw ดังนั้นการตรวจสอบแพ็คเกจอาจเรียกได้ว่าเป็นสิ่งที่แตกต่างไปจากเดิมอย่างสิ้นเชิงใน C # พอจะกล่าวได้ว่าเมื่อสองคลาสต้องอยู่ในเนมสเปซเดียวกันเพื่อเข้าถึงวิธีการเหล่านั้น

หากคุณต้องการเข้าถึงเมธอดส่วนตัวที่ไม่คงที่ของคลาสสามารถลองสิ่งนี้:

class Foo 
{
    private int Sum(int num1, int num2)
    {
        return num1 + num2;
    }
}

MethodInfo sumPrivate = 
    typeof(Foo).GetMethod("Sum", BindingFlags.NonPublic | BindingFlags.Instance);

int sum = (int)sumPrivate.Invoke(new Foo(), new object[] { 2, 5 });
// 7