تعلم ASP.NET MVC


الدرس: الاختبارات التلقائية


الصفحة السابقة
بشكل عام ، اختبار التطبيق أمر معقد إلى حد ما. وهي ممارسة غالباً ما تُوضع جانباً.

واحدة من المزايا الكبيرة لـ MVC هي أنه مع هذا التقسيم ، يصبح من السهل جدًا اختبار النموذج ووحدات التحكم بشكل موحد (من ناحية أخرى ، يكون العرض معقدا دائمًا!).
سنتحدث عن الاختبارات في هذا الفصل ، بسرعة كافية حتى لا تشعر بالملل. ولكن من المفيد البدء في رؤية ما هو عليه لأنهم سيخدموننا في الفصول التالية ، عندما نريد اختبار نموذجنا ووحدات التحكم الخاصة بنا.

ما هو اختبار الوحدة وماذا نختبر؟


الاختبار هو طريقة للتحقق من عمل نظام الكمبيوتر. اختبار التطبيق هو ممارسة جيدة. يجب القيام به.

هناك عدة طرق للاختبار. أكثر ما يبدو طبيعيًا هو الذي يتم يدويًا. نطلق تطبيق الويب الخاص بنا ، وننقر في كل مكان ، ونرى ما إذا كان يعمل. وهذا يعني أن اختبار الجزء المرئي من تطبيق الويب الخاص بنا يعني أيضًا اختبار قواعد العمل الخاصة بالتطبيق في نفس الوقت.
إن طريقة الاختبار التي سأقدمها هنا مكملة وسوف تسمح لنا بالتحقق من أن أجزاء التعليمات البرمجية تعمل بطريقة بسيطة واوتوماتيكية. مع هذه الاختبارات الآلية ، سنتمكن من اختبار النموذج وجهاز التحكم.

لن نتمكن من اختبار العرض ، لأنه عنصر بالكاد يمكننا جعله اوتوماتيكيا ويتطلب تفاعلًا مباشرًا مع المرئي ... ومع ذلك ، سيتم اختبار قواعد العمل تلقائيًا ، في نفس الوقت مع النموذج ووحدة التحكم.

يجب أن تغطي اختباراتنا الآلية جميع السيناريوهات لتطبيقنا إن أمكن. عندما تغطي الاختبارات جميع سيناريوهات الكود ، يمكننا التأكد من أن الكود يعمل. بالإضافة إلى ذلك ، يسمح هذا بعمليات الصيانة على الكود مع التأكد من أنها لن تخضع لانتكاسات. وبالمثل ، تعد الاختبارات شبكة أمان عندما تريد إعادة كتابة التعليمات البرمجية الخاصة بك أو تحسينها.
وبالتالي فإن الاختبار عبارة عن جزء من الكود يسمح لك باختبار كود آخر.

إنشاء مشروع تجريبي


تم إجراء هذا التذكير ، فلنعد إلى قلب الاختبارات على الفور.

هناك حلان لإنشاء مشروع اختبار. الأول هو القيام بذلك عند إنشاء مشروع (تذكر أن هناك مربع اختيار يسمح لنا بإنشاء مشروع اختبار). لذلك دعونا نقوم بإنشاء مشروع ASP.NET MVC 4 جديد ، والذي نسميه على سبيل المثال DemoTests . اختر دائمًا نموذج "Empty" ولكن هذه المرة ، حدد المربع الذي يسمح لك بإنشاء مشروع اختبار الوحدة:
ASP.NET framework
قم بإضافة مشروع اختبار لإنشاء مشروع ASP.NET MVC
يمكنك تسمية مشروع اختباري باسم آخر ، ولكن من الجيد أن تضاف إليه الاختبارات ، مثل ما يتم تقديمه. تحقق من إنشاء الحل ويمكنك أن ترى أنه يحتوي الآن على مشروعين: مشروع ASP.NET MVC المعروف ومشروع الاختبار التلقائي الجديد الخاص بنا.
ASP.NET framework
مشروع الاختبار في الحل
الحل الثاني لإضافة مشروع اختبار إلى تطبيق موجود هو إضافة مشروع اختبار. فقط انقر بزر الماوس الأيمن على الحل ، واختر إضافة مشروع جديد ، واستخدم قالب مشروع اختبار الوحدة:
ASP.NET framework
أضف مشروع اختبار
ستكون النتيجة نفسها. ومع ذلك ، في الحالة الأخيرة ، ستحتاج إلى إضافة مرجع إلى مشروع الويب الخاص بك من مشروع الاختبار الخاص بك.

الاختبار الأول


سنقوم الآن بإنشاء اختبارنا الأول. سيكون هذا اختبارًا على سبيل المثال لا يتعلق بتطبيق ويب MVC على الإطلاق ، ولكن لا تقلق ، سيتغير بسرعة. 
يمكننا أن نرى أن Visual Studio أنشأ ملف اختبار افتراضي لنا ، والذي يترك اسمه UnitTest1.cs شيئًا مطلوبًا. في مثالنا ، ليس سيئًا للغاية ، ولكن إذا كان يسبب قلقا ، فلا تتردد في إعادة تسمية الفصل باسم مناسب. من المهم أن يكون لديك أسماء فئة اختبار وأسماء طرق اختبار تتبع معيارًا يتبعه الجميع من أجل التنقل فيها.
هنا لمثالنا سأقوم باختبار طرق الرياضيات الأساسية ، لذلك سأقوم بإعادة تسمية فصلي إلى MathTests  .
إذا قمت بإعادة تسمية الملف UnitTest1.cs مباشرةً من مستكشف حلول Visual Studio ، فسيعرض أيضًا إعادة تسمية الفئة ؛ عملي.
ستلاحظ أن محتوى الملف الذي تم إنشاؤه على النحو التالي:

 [TestClass]
public class MathTests
{
    [TestMethod]
    public void TestMethod1()
    {
    }
}
TestClass   تجعل السمة من الممكن الإشارة إلى إطار الاختبار أن فئة MathTests تحتوي على طرق اختبار وأنه سيكون من الضروري تنفيذها. بدون هذه السمة ، لا يستطيع إطار الاختبار تحديد فئة تحتوي على طرق اختبار.
بنفس الطريقة ، تم تزيين طريقة الاختبار بالسمة TestMethod  .
هنا أيضًا ، من المثير للاهتمام اتباع قاعدة التسمية حتى تتمكن من تحديد هدف طريقة الاختبار بسرعة. أقدم لكم التسمية التالية: MethodeTestee_EtatInitial_EtatAttendu()  . على سبيل المثال ، يمكن استدعاء طريقة لاختبار طريقة حساب عامل Factorielle_AvecValeur3_Retourne6  . نظرًا لأنه من المهم اختبار العديد من سيناريوهات الاختبار ، فإنني أشجعك على إنشاء الكثير من طرق الاختبار.
حان الوقت للبدء. سنقوم بإنشاء طريقة لحساب عاملية وسوف نقوم باختبارها. لذا قم بإنشاء فئة MathHelper   في مشروع الويب الخاص بك ووضعه في المكان الذي تريده ، إنه ليس بالأمر الكبير ، على سبيل المثال ؛ يمكنك بعد ذلك حذفه:

public static class MathHelper
{
    public static long Factorielle(int a)
    {
        if (a <= 1)
            return 1;
        return a * Factorielle(a - 1);
    }
}
ثم قم بتعديل فئة الاختبار الخاصة بك للحصول على الاختبارات الثلاثة التالية ، مما يسمح لنا بالتحقق من صحة طريقة حساب العامل:

 [TestClass]
public class MathTests
{
    [TestMethod]
    public void Factorielle_AvecValeur0_Retourne1()
    {
        double resultat = MathHelper.Factorielle(0);
        Assert.AreEqual(1, resultat);
    }

    [TestMethod]
    public void Factorielle_AvecValeur3_Retourne6()
    {
        double resultat = MathHelper.Factorielle(3);
        Assert.AreEqual(6, resultat);
    }

    [TestMethod]
    public void Factorielle_AvecValeur15_Retourne1307674368000()
    {
        double resultat = MathHelper.Factorielle(15);
        Assert.AreEqual(6, resultat);
    }
}
نظرًا لأن Visual Studio رائع ، فقد أضاف المرجع نفسه عندما أنشأنا مشروع الاختبار في نفس الوقت مثل مشروع ASP.NET MVC . إذا قمت بإنشاء مشروع الاختبار في وقت لاحق يدويًا ، فسيتعين عليك بالطبع إضافة المرجع الخاص بك إلى مشروع الويب.
Assert   تسمح لنا أساليب الفصل الثابت بالتحقق من نتائجنا. هنا ، AreEqual   تجعل الطريقة  من الممكن التحقق من أن قيمة واحدة تساوي بالفعل قيمة أخرى ، وهو شرط أن يعمل الاختبار.
بالطبع ، ستلاحظ أن طريقي الأخير سيفشل ، لأن مضروب الرقم 15 لا يساوي 6 بالتأكيد!
علينا فقط إجراء الاختبارات ومعرفة ما إذا كان كل شيء يسير على ما يرام ... انتقل إلى قائمة TEST واختر تشغيل جميع الاختبارات:
ASP.NET framework
قم بإجراء الاختبارات
يمكنك أيضًا تشغيل الاختبارات في وضع التصحيح بحيث يمكنك معرفة سبب فشل الاختبار بسهولة أكبر.
تفتح نافذة جديدة تظهر لنا نتائج اختباراتنا:
ASP.NET framework
نتائج الاختبار
اختباران ناجحان واختبار فاشل ، تم التخطيط له ... بالإضافة إلى ذلك ، إذا حددنا الاختبار الفاشل ، فيمكننا الحصول على مزيد من المعلومات حول الفشل. فلنصلح الاختبار الأخير بحيث يمر:

 [TestMethod]
public void Factorielle_AvecValeur10_Retourne1307674368000()
{
    double resultat = MathHelper.Factorielle(15);
    Assert.AreEqual(1307674368000, resultat);
}
وها هنا ، جميع الاختبارات خضراء.
ASP.NET framework

إطار زائف simulacre


يوفر إطار عمل وهمي (simulacre) طريقة لاختبار طريقة من خلال عزلها عن باقي النظام. على سبيل المثال ، تخيل طريقة تسمح لك باسترداد حالة الطقس لهذا اليوم ، من خلال قراءتها من خدمة ويب. لدينا مشكلة هنا لأنه عندما نجري الاختبار يوم الاثنين ، تمطر. عندما نجري الاختبار يوم الثلاثاء ، يكون الطقس جيدًا ، إلخ. هنا لدينا معلومات تختلف بمرور الوقت. لذلك ، من الصعب اختبار نجاح الطريقة في بناء الطقس لهذا اليوم من هذه المعلومات ، لأنها تختلف.
الهدف من إطارات simulacre هو أن تكون قادرًا على توصيل الكود الذي يعتمد عليه تطويرنا حتى نتمكن من اختباره بشكل فردي ، دون الاعتماد على عزل النظام عن بقية النظام.
نتحدث عن ازدحام عندما نستبدل وظيفة حقيقية لتطبيق بوظيفة محاكاة وبسيطة.
هذا يعني أنه في اختبارنا ، سنستبدل الاستعلام عن خدمة الويب بطريقة خاطئة والتي دائمًا ما تشير إلى أن الطقس جيد. ومع ذلك ، يجب أن يتم ذلك دون تعديل تطبيقنا ، وإلا فلا فائدة. هذا هو الغرض من هذه الأطر الوهمية.
هناك العديد ، أكثر أو أقل تعقيدًا. دعنا نقتبس على سبيل المثال Moq (تنطق "mock-you" ) التي تعمل بشكل جيد جدًا مع ASP.NET MVC وهي مجانية ، أو إطار عمل Fakes الجديد من Microsoft الذي يأتي مع الإصدار الأغلى من Visual Studio ، ولكن هناك بعض الكثير من الأشياء الأخرى ... ميزة Moq هي أنه من السهل الوصول إليها: فهي تسمح لك بالقيام بالأشياء البسيطة والسهلة.  Fakes هو أكثر تقدمًا ولكنه أكثر تعقيدًا في التعامل معه. يمكنك العودة إلى هذا لاحقًا. في الوقت الحالي ، سنستخدم Moq في هذه الدورة وأسهل طريقة لاستخدامه هي استخدام NuGet لتثبيته. انقر بزر الماوس الأيمن على مشروع الاختبار واختر إدارة حزم NuGet :
ASP.NET framework
إدارة حزم NuGet
NuGet هو مدير حزم مجاني ومفتوح المصدر يعمل كملحق لـ Visual Studio لإضافة مراجع سريعة للمشاريع الشائعة.
ابحث عن حزم Moq عبر الإنترنت واختر تثبيتها:
ASP.NET framework
تثبيت موك عبر NuGet
بمجرد اكتمال التثبيت ، يمكنك إغلاق النافذة. يمكنك أن ترى أن تجميع Moq تمت الإشارة إليه تلقائيًا في مشروع الاختبار.
بعد ذلك ، لكي تتمكن من توصيل فئة بسهولة ، يجب أن تنفذ واجهة.
تخيل فئة الوصول إلى البيانات التالية:

public class Dal : IDal
{
    public Meteo ObtenirLaMeteoDuJour()
    {
        // ici , c'est le code pour accéder au service web
        // mais finalement , peu importe ce qu'on y met vu qu'on va bouchonner la méthode
        throw new NotImplementedException();
    }
}
التي تنفذ الواجهة التالية:

public interface IDal
{
    Meteo ObtenirLaMeteoDuJour();
}
بالكائن Meteo التالي:

public class Meteo
{
    public double Temperature { get; set; }
    public Temps Temps { get; set; }
}
والقائمة Temps التالية:

public enum Temps
{
    Soleil,
    Pluie
}
يمكننا كتابة اختبار يسد استدعاء الطريقة ObtenirLaMeteoDuJour ، والتي يجب أن تذهب عادةً للاستعلام عن خدمة ويب ، لإرجاع كائن زائف بدلاً من ذلك.
لإظهار هذا جيدًا ، جعلت الطريقة ترمي استثناءً ، مثل هذا ، إذا مررنا ، ستكون مرئية على الفور. يجب أن تكون طريقة الاختبار الكلاسيكية:

 [TestMethod]
public void ObtenirLaMeteoDuJour_AvecUnBouchon_RetourneSoleil()
{
    IDal dal = new Dal();
    Meteo meteoDuJour = dal.ObtenirLaMeteoDuJour();
    Assert.AreEqual(25, meteoDuJour.Temperature);
    Assert.AreEqual(Temps.Soleil, meteoDuJour.Temps);
}
إذا أجرينا الاختبار ، سيكون لدينا بالطبع استثناء لأن الطريقة لم يتم تنفيذها. عادي. 
استخدم الآن Moq لتوصيل هذه المكالمة واستبدالها بما تريد:

 [TestMethod]
public void ObtenirLaMeteoDuJour_AvecUnBouchon_RetourneSoleil()
{
    Meteo fausseMeteo = new Meteo
    {
        Temperature = 25,
        Temps = Temps.Soleil
    };
    Mock mock = new Mock();
    mock.Setup(dal => dal.ObtenirLaMeteoDuJour()).Returns(fausseMeteo);

    IDal fausseDal = mock.Object;
    Meteo meteoDuJour = fausseDal.ObtenirLaMeteoDuJour();
    Assert.AreEqual(25, meteoDuJour.Temperature);
    Assert.AreEqual(Temps.Soleil, meteoDuJour.Temps);
}
نستخدم الكائن العام Mock لإنشاء كائن خاطئ من نوع واجهتنا. نستخدم الطريقة من Setup   خلال تعبير lambda للإشارة إلى أن الطريقة ObtenirLaMeteoDuJour   ستقوم بالفعل بإرجاع كائن طقس مزيف. يتم ذلك بشكل طبيعي باستخدام الطريقة Returns()  .
ميزة هذه الإنشاءات هي أن البنية الواضحة تتحدث عن نفسها منذ اللحظة التي نعرف فيها تعابير lambda .
ثم نحصل على مثيل من كائننا بفضل الخاصية Object   وهذا الكائن الزائف الذي يمكننا مقارنته مع قيمنا.
بالطبع ، هنا ، هذا الاختبار ليس له اهمية كبيرة ، ولكن تخيل أننا بحاجة إلى اختبار الوظائف التي تعمل على تنسيق كائن الطقس هذا الذي تم استرداده من خدمة الويب أو الكود الذي يسمح لنا بعمل إحصائيات حول هذه البيانات الطقس. . . هناك ، نحن على يقين من أنه يمكننا أن نركز على قيمة معروفة للاعتماد على خدمة الويب (بالإضافة إلى ذلك ، لا يتعين علينا الاتصال بالإنترنت). سيسمح لك ذلك أيضًا برفض جميع الحالات الممكنة عن طريق تغيير قيمة الحد الأقصى وجعل الاختبارات الأكثر شمولًا ممكنة.
يمكننا أن نفعل نفس الشيء مع الخصائص. تخيل الفئة التالية التي    تُرجع خصائصها Valeur رقمًا عشوائيًا:

public interface IGenerateur
{
    int Valeur { get; }
}

public class Generateur : IGenerateur
{
    private Random r;
    public Generateur()
    {
        r = new Random();
    }

    public int Valeur
    {
        get
        {
            return r.Next(0, 100);
        }
    }
}
قد نحتاج إلى توصيل هذه الخاصية بحيث تُرجع رقمًا معروفًا مسبقًا. سيتم ذلك بنفس الطريقة:

Mock<IGenerateur> mock = new Mock<IGenerateur>();
mock.Setup(generateur => generateur.Valeur).Returns(5);

Assert.AreEqual(5, mock.Object.Valeur);
هنا ،    سترجع الخاصية Valeur دائمًا 5 ، مما يسخر من مولد الأرقام العشوائية. . .
أتوقف عند هذا الحد لإلقاء نظرة عامة على هذا الإطار الزائف. يمكننا أن نرى أنه يمكن أن يسد التبعيات بسهولة مما يسمح لنا بتسهيل تنفيذ اختبارات الوحدة الخاصة بنا. تذكر ، لكي يكون الاختبار فعالًا ، يجب أن يكون قادرًا على التركيز على نقطة معينة في التعليمات البرمجية دون أن يزعجك أي تبعيات يمكن أن تزعج حالة الاختبار في كل مرة.

التطبيق الأول: اختبار الطرق


حسنًا ، من الرائع جدًا استخدام هذا الإطار الوهمي. لقد فهمنا المصلحة العامة ، ولكن ماذا سيفيدنا حقًا مع ASP.NET MVC ؟
الكثير من الأشياء ، ولكن أولاً ، سيسمح لنا باختبار مساراتنا وبشكل أكثر تحديدًا للتحقق مما إذا كانت عناوين URL المختلفة التي نرغب في استخدامها تؤدي إلى إنشاء عمليات تحكم فورية مع المُدخلات الصحيحة ... لأننا رأينا ذلك "مع وجود طرق متعددة ، يمكن أن يكون الأمر معقدًا بسرعة. ماذا لو احتجنا لإضافة واحد؟ كيف يمكننا التأكد من أن جميع القواعد الأخرى لن يتم إزعاجها؟
الاختبارات بالطبع!
في هذا المثال ، لنأخذ حل HelloWorld ونضع المسارين اللذين رأيناهما في الفصل السابق:

public class RouteConfig
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        routes.MapRoute(
            name: "Meteo",
            url: "{jour}/{mois}/{annee}",
            defaults: new { controller = "Meteo", action = "Afficher" },
            constraints: new { jour = @"\d+", mois = @"\d+", annee = @"\d+" });

        routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
        );
    }
}
نجد طريقنا الذي يمكنه توجيه عناوين URL مثل هذا / 04/28/2013 إلى طريقة Afficher  من وحدة  التحكم Meteo، مع مُدخلات اليوم 28 والشهر 04 والسنة 2013.
وبالمثل ، عنوان URL من النوع  /Home/Index/2 ستنفذ أسلوب Index من   وحدة التحكم Home   باستخدام id   إلى 2 كمُدخل . تذكر أيضًا أن / route ستقوم بإنشاء وحدة تحكم Home   واستدعاء الطريقة Index ، وهي القيم الافتراضية.
حسنًا ... هذه هي النظرية ، ماذا لو فحصناها بالاختبارات؟ 
أولاً ، تحتاج إلى إضافة مشروع اختبار وتثبيت Moq ، كما رأينا من قبل. لا تنس الإشارة إلى مشروع HelloWorld من مشروع الاختبار.
لاختبار هذا العنصر ، حتى الآن ، لا يمكننا القيام بذلك إلا من خلال بدء تطبيق ويب والتحقق بأنفسنا من أن عنوان URL قام بإنشاء مثيل لجهاز التحكم ، لأن التوجيه يستخدم التوجيهات الداخلية لـ ASP.NET . باستثناء ذلك مع Moq ، يمكننا الاستغناء عنه.
في النهاية ، ما نريد التحقق منه هو أن الطريقة التي تعلن عن طرقنا تؤدي وظيفتها بشكل جيد. الطريقة المعنية هي الطريقة الثابتة العامة RegisterRoutes ، وهي جزء من الطبقة الثابتة العامة  RouteConfig  . هذا البناء الثابت عملي جدًا ، وسنكون قادرين على استدعاؤه من اختبارنا عن طريق اجتيازه RouteCollection   ، وهو ما سيسمح لنا بالتحقق من أن كل شيء يناسبك. يمكننا بعد ذلك فحص محتوى المسار الذي اختاره ASP.NET MVC .
لذلك ، من الضروري أن نفهم قليلاً كيفية عمل نظام التوجيه داخليًا. في الواقع ، فإن الطريقة MapRoute   التي نستخدمها للإعلان عن مسار جديد تستدعي طريقة لإطار MVC الذي ينشئ كائنًا RouteBase   يستخدم لتعيين طلب ويب والمسار. يستخدم الفئة HttpContextBase   التي تحتوي على معلومات حول طلب HTTP . سنقوم بإنشاء كائن مزيف HttpContextBase   لتحديد عنوان URL الذي نريد اختباره:

Mock<HttpContextBase> mockContext = new Mock<HttpContextBase>();
mockContext.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath).Returns("~/Home/Index/2");
ملاحظة: يجب أن تبدأ عناوين URL برمز ~ للإشارة إلى أنها جذر التطبيق. ستحتاج إلى إضافة مرجع إلى System.Web لتتمكن من استخدام HttpContextBase .
نقوم بتوصيل الخاصية AppRelativeCurrentExecutionFilePath   لأنه يتم استخدام هذه الخاصية بواسطة التوجيه.
يمكننا بعد ذلك إنشاء كائن RouteCollection   ثم تمريره كمُدخلات إلى طريقة الاعدادات الخاصة بنا:

RouteCollection routes = new RouteCollection();
RouteConfig.RegisterRoutes(routes);
RouteData routeData = routes.GetRouteData(mockContext.Object);
ثم سنستدعي الطريقة GetRouteData   لإجراء التعيين من عنوان URL الموجود في كائن النوع HttpContextBase  .
وأخيرًا ، سيكون علينا فقط التحقق من صحة كل شيء ، من خلال الذهاب إلى فحص كائن dataData . الذي يعطي الاختبار التالي في النهاية:

 [TestMethod]
public void Routes_PageHomeIndex2_RetourneControleurHomeEtMethodeIndexEtParam2()
{
    Mock<HttpContextBase> mockContext = new Mock<HttpContextBase>();
    mockContext.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath).Returns("~/Home/Index/2");
    RouteCollection routes = new RouteCollection();
    RouteConfig.RegisterRoutes(routes);
    RouteData routeData = routes.GetRouteData(mockContext.Object);
    Assert.IsNotNull(routeData);
    Assert.AreEqual("Home", routeData.Values["controller"]);
    Assert.AreEqual("Index", routeData.Values["action"]);
    Assert.AreEqual("2", routeData.Values["id"]);
}
قد تبدو تهيئة السياق معقدة ، لكنها لا تزال هي نفسها. نظرًا لأننا سنكتب العديد من الاختبارات ، يمكننا إعادة صياغة قليلاً تهيئة المسار من عنوان URL :

private static RouteData DefinirUrl(string url)
{
    Mock<HttpContextBase> mockContext = new Mock<HttpContextBase>();
    mockContext.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath).Returns(url);
    RouteCollection routes = new RouteCollection();
    RouteConfig.RegisterRoutes(routes);
    RouteData routeData = routes.GetRouteData(mockContext.Object);
    return routeData;
}
وانظر مع الاختبارات الثلاثة التالية كيفية التحقق من السلوك الجيد لعناوين URL مثل:
  • /Home/Index/2
  • /
  • /28/04/2013

 [TestMethod]
public void Routes_PageHome_RetourneControleurHomeEtMethodeIndex()
{
    RouteData routeData = DefinirUrl("~/");
    Assert.IsNotNull(routeData);
    Assert.AreEqual("Home", routeData.Values["controller"]);
    Assert.AreEqual("Index", routeData.Values["action"]);
    Assert.AreEqual(UrlParameter.Optional, routeData.Values["id"]);
}

[TestMethod]
public void Routes_PageHomeIndex2_RetourneControleurHomeEtMethodeIndexEtParam2()
{
    RouteData routeData = DefinirUrl("~/Home/Index/2");
    Assert.IsNotNull(routeData);
    Assert.AreEqual("Home", routeData.Values["controller"]);
    Assert.AreEqual("Index", routeData.Values["action"]);
    Assert.AreEqual("2", routeData.Values["id"]);
}

[TestMethod]
public void Routes_MeteoAujourdhui_RetourneControleurMeteoMethodeAfficherEtParametreAujourdhui()
{
    DateTime aujourdhui = DateTime.Now;
    RouteData routeData = DefinirUrl(string.Format("~/{0}/{1}/{2}", aujourdhui.Day, aujourdhui.Month, aujourdhui.Year));
    Assert.IsNotNull(routeData);
    Assert.AreEqual("Meteo", routeData.Values["controller"]);
    Assert.AreEqual("Afficher", routeData.Values["action"]);
    Assert.AreEqual(aujourdhui.Day.ToString(), routeData.Values["jour"]);
    Assert.AreEqual(aujourdhui.Month.ToString(), routeData.Values["mois"]);
    Assert.AreEqual(aujourdhui.Year.ToString(), routeData.Values["annee"]);
}
للاستخدام UrlParameter  ، ستحتاج إلى إضافة مرجع إلى System.Web.Mvc.dll . أسهل طريقة هي استعادة موقع الملف في مشروع HelloWorld وإضافة المرجع من هذا الموقع.
وهذا هو اختبار الطريق ، جيد جدا أليس كذلك؟
لاحظ أنه عندما لا يتطابق المسار ، خذ عشوائيًا عنوان URL /Url/bidon/pas/bonne ، ثم routeData   سيكون يساوي null  . قف ، اختبار صغير للتأكد:

 [TestMethod]
public void Routes_UrlBidon_RetourneNull()
{
    RouteData routeData = DefinirUrl("/Url/bidon/pas/bonne");
    Assert.IsNull(routeData);
}
انتهت هذه الجولة الصغيرة من اختبار الوحدة. سنعود إلى ذلك في فصول لاحقة عندما يتعلق الأمر باختبار مكونات أخرى.

باختصار


  • الاختبارات جزء أساسي في أي تطبيق حاسوبي للتحقق من أنه يعمل.
  • تقدم بنية MVC انهيارًا يسهل اختبار النموذج والتحكم.
  • يمكننا الجمع بين اختباراتنا التلقائية وإطار عمل وهمي مثل Moq