اختبارات الوحدة لمقارنة الملفات النصية في NUnit

Question

لدي فصل يقوم بمعالجة ملفين xml وينتج ملفًا نصيًا.

أرغب في كتابة مجموعة من اختبارات الوحدة/التكامل التي يمكن أن تنجح أو تفشل بشكل فردي لهذا الفصل والتي تقوم بما يلي:

1. بالنسبة للإدخال A وB، قم بإنشاء الإخراج.
2. قارن محتويات الملف الذي تم إنشاؤه بمحتويات الإخراج المتوقع
3. عندما تختلف المحتويات الفعلية عن المحتويات المتوقعة، تفشل وتظهر بعضها مفيد معلومات حول الاختلافات.

يوجد أدناه النموذج الأولي للفصل بالإضافة إلى أول طعنة لي في اختبارات الوحدة.

هل هناك نمط يجب أن أستخدمه لهذا النوع من الاختبارات، أم أن الناس يميلون إلى كتابة ملايين من وظائف TestX()؟

هل هناك طريقة أفضل لاقناع اختلافات الملفات النصية من NUnit؟ هل يجب علي تضمين خوارزمية فرق ملف نصي؟

---

class ReportGenerator
{
    string Generate(string inputPathA, string inputPathB)
    {
        //do stuff
    }
}

---

[TextFixture]
public class ReportGeneratorTests
{
     static Diff(string pathToExpectedResult, string pathToActualResult)
     {
         using (StreamReader rs1 = File.OpenText(pathToExpectedResult))
         {
             using (StreamReader rs2 = File.OpenText(pathToActualResult))
             {
                 string actualContents = rs2.ReadToEnd();
                 string expectedContents = rs1.ReadToEnd();                  

                 //this works, but the output could be a LOT more useful.
                 Assert.AreEqual(expectedContents, actualContents);
             }
         }
     }

     static TestGenerate(string pathToInputA, string pathToInputB, string pathToExpectedResult)
     {
          ReportGenerator obj = new ReportGenerator();
          string pathToResult = obj.Generate(pathToInputA, pathToInputB);
          Diff(pathToExpectedResult, pathToResult);
     }

     [Test]
     public void TestX()
     {
          TestGenerate("x1.xml", "x2.xml", "x-expected.txt");
     }

     [Test]
     public void TestY()
     {
          TestGenerate("y1.xml", "y2.xml", "y-expected.txt");
     }

     //etc...
}

---

تحديث

لست مهتمًا باختبار وظيفة الفرق.أريد فقط استخدامه لإنتاج المزيد من حالات الفشل القابلة للقراءة.

Answer 1

أما بالنسبة للاختبارات المتعددة ذات البيانات المختلفة، فاستخدم ملحق NUnit RowTest:

using NUnit.Framework.Extensions;

[RowTest]
[Row("x1.xml", "x2.xml", "x-expected.xml")]
[Row("y1.xml", "y2.xml", "y-expected.xml")]
public void TestGenerate(string pathToInputA, string pathToInputB, string pathToExpectedResult)
 {
      ReportGenerator obj = new ReportGenerator();
      string pathToResult = obj.Generate(pathToInputA, pathToInputB);
      Diff(pathToExpectedResult, pathToResult);
 }

Answer 2

من المحتمل أنك تطلب إجراء الاختبار مقابل البيانات "الذهبية".لا أعرف إذا كان هناك مصطلح محدد لهذا النوع من الاختبارات المقبولة في جميع أنحاء العالم، ولكن هذه هي الطريقة التي نقوم بها.

إنشاء فئة لاعبا أساسيا.يحتوي بشكل أساسي على "void DoTest(string fileName)"، والذي سيقرأ ملفًا محددًا في الذاكرة، وينفذ طريقة التحويل المجردة "string Transform(string text)"، ثم يقرأ fileName.gold من نفس المكان ويقارن النص المحول بما كان متوقعًا .إذا كان المحتوى مختلفًا، فسيطرح استثناءً.يحتوي الاستثناء الذي تم طرحه على رقم السطر الخاص بالفرق الأول بالإضافة إلى نص السطر المتوقع والفعلي.نظرًا لأن النص مستقر، فهذه عادةً ما تكون معلومات كافية لاكتشاف المشكلة على الفور.تأكد من وضع علامة على السطور التي تحتوي على "المتوقع:" و"الفعلي:"، وإلا ستخمن إلى الأبد ما هو الحال عند النظر إلى نتائج الاختبار.

بعد ذلك، سيكون لديك تجهيزات اختبار محددة، حيث تقوم بتنفيذ طريقة التحويل التي تقوم بالمهمة الصحيحة، ثم يكون لديك اختبارات تبدو كما يلي:

[Test] public void TestX() { DoTest("X"); }
[Test] public void TestY() { DoTest("Y"); }

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

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

Answer 3

ربما سأكتب اختبار وحدة واحدة يحتوي على حلقة.داخل الحلقة، قرأت ملفين xml وملف فرق، ثم قمت بتفريق ملفات xml (دون كتابتها على القرص) ومقارنتها بملف الفرق المقروء من القرص.سيتم ترقيم الملفات، على سبيل المثال.a1.xml، b1.xml، diff1.txt؛a2.xml، b2.xml، diff2.txt؛a3.xml، وb3.xml، وdiff3.txt، وما إلى ذلك، وتتوقف الحلقة عندما لا تجد الرقم التالي.

وبعد ذلك، يمكنك كتابة اختبارات جديدة فقط عن طريق إضافة ملفات نصية جديدة.

Answer 4

بدلاً من استدعاء .AreEqual، يمكنك تحليل تدفقي الإدخال بنفسك، والاحتفاظ بعدد الأسطر والأعمدة ومقارنة المحتويات.بمجرد العثور على اختلاف، يمكنك إنشاء رسالة مثل...

السطر 32 العمود 12 - تم العثور على "x" عندما كان من المتوقع وجود "y".

يمكنك تحسين ذلك اختياريًا من خلال عرض أسطر متعددة من المخرجات

الفرق في السطر 32، العمود 12، يظهر الفرق الأول
أ = هذا هو رسشارع
ب = هذا هو رهالقديسون

لاحظ، كقاعدة عامة، سأقوم فقط بإنشاء أحد التدفقين الموجودين لديك من خلال الكود الخاص بي.والآخر سأحصل عليه من ملف اختبار/نصي، بعد التحقق بالعين المجردة أو بطريقة أخرى من صحة البيانات الواردة!

Answer 5

ربما سأستخدم XmlReader للتكرار عبر الملفات ومقارنتها.عندما أتوصل إلى اختلاف، سأعرض XPath على الموقع الذي تختلف فيه الملفات.

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