තනි ඒකක පරීක්ෂණයකදී බහුවිධ ප්‍රකාශයන් තිබීම හරිද?

මෙම ශ්‍රේෂ් post තනතුරට අදහස් දක්වමින් රෝයි ඔෂෙරෝව්, OAPT ව්‍යාපෘතිය ගැන සඳහන් කළේ එක් එක් ප්‍රකාශය තනි පරීක්ෂණයකින් ක්‍රියාත්මක කිරීම සඳහා නිර්මාණය කර ඇති බවයි.

පහත දැක්වෙන්නේ ව්‍යාපෘතියේ මුල් පිටුවේ ය:

නිසි ඒකක පරීක්ෂණ හරියටම එක් හේතුවක් නිසා අසමත් විය යුතුය, එබැවින් ඔබ ඒකක පරීක්ෂණයකට එක් ප්‍රකාශයක් භාවිතා කළ යුතුය.

තවද, රෝයි අදහස් දැක්වීමේදී මෙසේ ලිවීය.

මගේ මාර්ගෝපදේශය සාමාන්‍යයෙන් ඔබ එක් පරීක්ෂණයකට එක් තාර්කික CONCEPT පරීක්‍ෂා කිරීමයි. ඔබට එකම වස්තුව මත බහුවිධ ප්‍රකාශ කළ හැකිය . ඒවා සාමාන්‍යයෙන් එකම සංකල්පයක් වනු ඇත.

මම හිතන්නේ, බහුවිධ ප්‍රකාශයන් අවශ්‍ය වන අවස්ථා තිබේ (උදා: ආරක්ෂක ප්‍රකාශය ), නමුත් පොදුවේ මම මෙය වළක්වා ගැනීමට උත්සාහ කරමි. ඔබගේ මතය කුමක්ද? කරුණාකර බහුවිධ ප්‍රකාශයන් සැබවින්ම අවශ්‍ය වන සැබෑ ලෝක උදාහරණයක් සපයන්න .

එය අත්‍යවශ්‍යයෙන්ම නරක දෙයක් යැයි මම නොසිතමි, නමුත් අපගේ පරීක්ෂණ වලදී තනි ප්‍රකාශයක් පමණක් ලබා ගැනීමට අප උත්සාහ කළ යුතු යැයි මම සිතමි . මෙයින් අදහස් කරන්නේ ඔබ තවත් බොහෝ පරීක්ෂණ ලියන අතර අපගේ පරීක්ෂණ අවසන් වන්නේ වරකට එක් දෙයක් පමණක් පරීක්ෂා කිරීමෙනි.

එසේ පැවසීමෙන් පසු, මගේ පරීක්ෂණවලින් අඩක් ඇත්ත වශයෙන්ම ඇත්තේ එක් ප්‍රකාශයක් පමණක් යැයි මම කියමි. මම හිතන්නේ එය ඔබේ පරීක්ෂණයේදී ප්‍රකාශ පහක් හෝ වැඩි ගණනක් ඇති විට එය කේත (පරීක්ෂණ?) සුවඳක් බවට පත්වේ .

බහුවිධ ප්‍රකාශයන් ඔබ විසඳන්නේ කෙසේද?

පරීක්ෂණ අසාර්ථක විය යුත්තේ එක් හේතුවක් නිසා පමණි, නමුත් සෑම විටම එක Assertප්‍රකාශයක් පමණක් තිබිය යුතු යැයි එයින් අදහස් නොවේ . IMHO " විධිවිධාන, පනත, තහවුරු කිරීම " රටාව තදින් අල්ලා ගැනීම වඩා වැදගත් ය .

ප්රධාන දෙය නම් ඔබට ඇත්තේ එක් ක්රමයක් පමණක් වන අතර පසුව ඔබ එම ක්රියාවලියේ ප්රති results ල තහවුරු කර ගනිමින් පරීක්ෂා කරයි. නමුත් එය "සැකසීම, පනත, තහවුරු කිරීම, පරීක්ෂණයේ අවසානය " ය. වෙනත් ක්‍රියාවක් සිදු කිරීමෙන් පසුව පරීක්‍ෂණය දිගටම කරගෙන යාමට ඔබ පෙළඹෙන්නේ නම් සහ පසුව තවත් තහවුරු කරයි නම්, ඒ වෙනුවට වෙනම පරීක්ෂණයක් කරන්න.

එකම ක්‍රියාව පරීක්ෂා කිරීමේ කොටස් වන බහු ප්‍රකාශ ප්‍රකාශ දැකීම සතුටට කරුණකි. උදා

[Test]
public void ValueIsInRange()
{
  int value = GetValueToTest();

  Assert.That(value, Is.GreaterThan(10), "value is too small");
  Assert.That(value, Is.LessThan(100), "value is too large");
} 

හෝ

[Test]
public void ListContainsOneValue()
{
  var list = GetListOf(1);

  Assert.That(list, Is.Not.Null, "List is null");
  Assert.That(list.Count, Is.EqualTo(1), "Should have one item in list");
  Assert.That(list[0], Is.Not.Null, "Item is null");
} 

ඔබට මේවා එක ප්‍රකාශයකට ඒකාබද්ධ කළ හැකිය , නමුත් එය ඔබ කළ යුතු හෝ කළ යුතු යැයි අවධාරනය කිරීමට වඩා වෙනස් දෙයකි . ඒවා ඒකාබද්ධ කිරීමෙන් කිසිදු දියුණුවක් නොමැත.

උදා: පළමුවැන්න විය හැකිය

Assert.IsTrue((10 < value) && (value < 100), "Value out of range"); 

නමුත් මෙය වඩා හොඳ නැත - එයින් පිටවන දෝෂ පණිවිඩය අඩු නිශ්චිත වන අතර එයට වෙනත් වාසි නොමැත. දෙකක් හෝ තුනක් (හෝ වැඩි ගණනක්) එක් විශාල බූලියන් තත්වයකට ඒකාබද්ධ කිරීම කියවීම දුෂ්කර, වෙනස් කිරීමට අපහසු සහ එය අසාර්ථක වීමට හේතුව සොයා ගැනීමට අපහසු වන වෙනත් උදාහරණ ගැන ඔබට සිතිය හැකි බව මට විශ්වාසයි. මෙය නීතියක් සඳහා පමණක් කරන්නේ ඇයි?

සැ.යු : මම මෙහි ලියන කේතය NUnit සමඟ C # වේ, නමුත් මූලධර්ම වෙනත් භාෂා හා රාමු සමඟ රැඳෙනු ඇත. වාක්‍ය ඛණ්ඩය ද බොහෝ සමාන විය හැකිය.

එකකට වඩා ප්‍රකාශ කිරීම නරක දෙයක් යැයි මම කිසි විටෙකත් නොසිතුවෙමි.

මම එය සැමවිටම කරමි:

public void ToPredicateTest()
{
    ResultField rf = new ResultField(ResultFieldType.Measurement, "name", 100);
    Predicate<ResultField> p = (new ConditionBuilder()).LessThanConst(400)
                                                       .Or()
                                                       .OpenParenthesis()
                                                       .GreaterThanConst(500)
                                                       .And()
                                                       .LessThanConst(1000)
                                                       .And().Not()
                                                       .EqualsConst(666)
                                                       .CloseParenthesis()
                                                       .ToPredicate();
    Assert.IsTrue(p(ResultField.FillResult(rf, 399)));
    Assert.IsTrue(p(ResultField.FillResult(rf, 567)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 400)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 666)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 1001)));

    Predicate<ResultField> p2 = (new ConditionBuilder()).EqualsConst(true).ToPredicate();

    Assert.IsTrue(p2(new ResultField(ResultFieldType.Confirmation, "Is True", true)));
    Assert.IsFalse(p2(new ResultField(ResultFieldType.Confirmation, "Is False", false)));
}

සංකීර්ණ තත්වයන් අපේක්ෂිත පුරෝකථනය බවට හැරවිය හැකි බවට වග බලා ගැනීම සඳහා මෙහිදී මම බහු ප්‍රකාශ භාවිතා කරමි.

මම පරීක්ෂා කරන්නේ එක් ඒකකයක් ( ToPredicateක්‍රමය) පමණි, නමුත් පරීක්ෂණයෙන් මට සිතිය හැකි සියල්ල ආවරණය කරමි.

ඉහළ මට්ටමේ හැසිරීම වලංගු කිරීම සඳහා මම ඒකක පරීක්ෂාව භාවිතා කරන විට, මම එක පරීක්ෂණයකට බහුවිධ ප්‍රකාශ ඉදිරිපත් කරමි. මෙන්න මම හදිසි දැනුම්දීම් කේතයක් සඳහා භාවිතා කරන පරීක්ෂණයකි. පරීක්ෂණයට පෙර ක්‍රියාත්මක වන කේතය මඟින් පද්ධතිය ප්‍රධාන ප්‍රොසෙසරය ක්‍රියාත්මක වුවහොත් අනතුරු ඇඟවීමක් යවනු ලැබේ.

@Test
public void testAlarmSent() {
    assertAllUnitsAvailable();
    assertNewAlarmMessages(0);

    pulseMainProcessor();

    assertAllUnitsAlerting();
    assertAllNotificationsSent();
    assertAllNotificationsUnclosed();
    assertNewAlarmMessages(1);
}

කේතය මා අපේක්ෂා කරන ආකාරයට හැසිරෙන බවට මට විශ්වාසයක් ඇති කර ගැනීම සඳහා ක්‍රියාවලියේ සෑම පියවරකදීම පැවතිය යුතු කොන්දේසි එය නියෝජනය කරයි. එක ප්‍රකාශයක් අසමත් වුවහොත්, ඉතිරි ඒවා ක්‍රියාත්මක නොවනු ඇතැයි මම නොසිතමි. පද්ධතියේ රාජ්ය තවදුරටත් වලංගු නිසා, එම පසු කථනයන් මට වටිනා දෙයක් කියන්න නැහැ. * නම් assertAllUnitsAlerting()අසාර්ථක, මම මොනවා කරන්නද දන්නේ නැහැ assertAllNotificationSent()සාර්ථකත්වය හෝ අසාර්ථකත්වය ගේ මම පෙර දෝෂය ඇති දේ තීරණය වන තෙක් එය නිවැරදි කළා.

(* - හරි, ඒවා ගැටලුව නිරාකරණය සඳහා ප්‍රයෝජනවත් යැයි සිතිය හැකිය. නමුත් පරීක්ෂණය අසාර්ථක වූ වැදගත්ම තොරතුරු දැනටමත් ලැබී ඇත.)

මා සිතීමට තවත් හේතුවක් නම්, එක් ක්‍රමයක බහුවිධ ප්‍රකාශයන් නරක දෙයක් නොවන බව පහත කේතයේ විස්තර කර ඇත:

class Service {
    Result process();
}

class Result {
    Inner inner;
}

class Inner {
    int number;
}

මගේ පරීක්ෂණයේදී මට අවශ්‍ය වන්නේ පන්ති අවස්ථා service.process()වලදී නිවැරදි අංකය ලබා දෙන බව පරීක්ෂා කිරීමයි Inner.

පරීක්ෂා කරනවා වෙනුවට ...

@Test
public void test() {
    Result res = service.process();
    if ( res != null && res.getInner() != null ) Assert.assertEquals( ..., res.getInner() );
}

මම කරනවා

@Test
public void test() {
    Result res = service.process();
    Assert.notNull(res);
    Assert.notNull(res.getInner());
    Assert.assertEquals( ..., res.getInner() );
}

එක් හේතුවක් නිසා පමණක් පරීක්ෂණය අසමත් විය යුතුය යන රීතිය තුළ බහුවිධ ප්‍රකාශ ලිවීම වලංගු වන අවස්ථා ඕනෑ තරම් ඇතැයි මම සිතමි.

නිදසුනක් ලෙස, දිනය නූලක් විග්‍රහ කරන ශ්‍රිතයක් සිතන්න:

function testParseValidDateYMD() {
    var date = Date.parse("2016-01-02");

    Assert.That(date.Year).Equals(2016);
    Assert.That(date.Month).Equals(1);
    Assert.That(date.Day).Equals(0);
}

පරීක්ෂණය අසමත් වුවහොත් එය එක් හේතුවක් නිසා, විග්‍රහ කිරීම වැරදිය. විවිධ හේතු තුනක් නිසා මෙම පරීක්ෂණය අසමත් විය හැකි යැයි ඔබ තර්ක කරන්නේ නම්, “එක් හේතුවක්” පිළිබඳ ඔබේ අර්ථ දැක්වීමේදී ඔබ IMHO ඉතා හොඳින් කටයුතු කරනු ඇත.

[ටෙස්ට්] ක්‍රමය තුළම බහුවිධ ප්‍රකාශයන් තිබීම හොඳ අදහසක් වන කිසිදු තත්වයක් ගැන මම නොදනිමි. බහුවිධ ප්‍රකාශයන් ලබා ගැනීමට මිනිසුන් කැමති වීමට ප්‍රධාන හේතුව වන්නේ ඔවුන් එක් එක් පන්තිය පරීක්ෂා කිරීම සඳහා එක් [TestFixture] පන්තියක් ලබා ගැනීමට උත්සාහ කිරීමයි. ඒ වෙනුවට, ඔබට තවත් [TestFixture] පන්ති වලට ඔබේ පරීක්ෂණ බිඳ දැමිය හැකිය. පළමු ප්‍රකාශය අසාර්ථක වූ ස්ථානය වෙනුවට කේතය ඔබ අපේක්ෂා කළ ආකාරයට ප්‍රතික්‍රියා නොකළ ආකාර කිහිපයක් බැලීමට මෙය ඔබට ඉඩ සලසයි. ඔබ මෙය සාක්ෂාත් කර ගන්නා ආකාරය නම්, ඔබට පන්තියකට අවම වශයෙන් එක් ඩිරෙක්ටරියක්වත් ඇතුළත [TestFixture] පන්ති රාශියක් පරීක්ෂා කර ඇත. සෑම [TestFixture] පන්තියක්ම ඔබ විසින් පරීක්ෂා කරනු ලබන වස්තුවක නිශ්චිත තත්වයට නම් කරනු ලැබේ. [SetUp] ක්‍රමය මඟින් පන්ති නාමයෙන් විස්තර කර ඇති තත්වයට වස්තුව ලැබෙනු ඇත. එවිට ඔබට වස්තුවේ වත්මන් තත්වය අනුව, සත්‍ය යැයි අපේක්ෂා කරන විවිධ දේ තහවුරු කරන බහු [පරීක්ෂණ] ක්‍රම තිබේ. සෑම [ටෙස්ට්] ක්‍රමයක්ම එය තහවුරු කරන දෙයට නම් කර ඇත, සමහර විට එය කේතයේ ඉංග්‍රීසි කියවීමක් වෙනුවට සංකල්පයට නම් කළ හැකිය. එවිට සෑම [පරීක්ෂණ] ක්‍රමයක්ම ක්‍රියාත්මක කිරීමට අවශ්‍ය වන්නේ එය යමක් තහවුරු කරන කේත පේළියක් පමණි. මෙම ප්‍රවේශයේ තවත් වාසියක් නම්, ඔබ පරීක්‍ෂා කරන්නේ කුමක් ද යන්න සහ පන්තියේ සහ ක්‍රමයේ නම් දෙස බැලීමෙන් ඔබ අපේක්ෂා කරන දේ පැහැදිලි වන හෙයින් එය පරීක්ෂණ ඉතා පහසුවෙන් කියවිය හැකි ය. ඔබට පරීක්ෂා කිරීමට අවශ්‍ය කුඩා අවස්ථා සියල්ලම ඔබ තේරුම් ගැනීමට පටන් ගන්නා විට සහ දෝෂ සොයා ගන්නා විට මෙයද වඩා හොඳ වනු ඇත. සමහර විට එය කේතයේ ඉංග්‍රීසි කියවීමක් වෙනුවට සංකල්පයට නම් කළ හැකිය. එවිට සෑම [පරීක්ෂණ] ක්‍රමයක්ම ක්‍රියාත්මක කිරීමට අවශ්‍ය වන්නේ එය යමක් තහවුරු කරන කේත පේළියක් පමණි. මෙම ප්‍රවේශයේ තවත් වාසියක් නම්, ඔබ පරීක්‍ෂා කරන්නේ කුමක් ද යන්න සහ පන්තියේ සහ ක්‍රමයේ නම් දෙස බැලීමෙන් ඔබ අපේක්ෂා කරන දේ පැහැදිලි වන හෙයින් එය පරීක්ෂණ ඉතා පහසුවෙන් කියවිය හැකි ය. ඔබට පරීක්ෂා කිරීමට අවශ්‍ය කුඩා අවස්ථා සියල්ලම ඔබ තේරුම් ගැනීමට පටන් ගන්නා විට සහ දෝෂ සොයා ගන්නා විට මෙයද වඩා හොඳ වනු ඇත. සමහර විට එය කේතයේ ඉංග්‍රීසි කියවීමක් වෙනුවට සංකල්පයට නම් කළ හැකිය. එවිට සෑම [පරීක්ෂණ] ක්‍රමයක්ම ක්‍රියාත්මක කිරීමට අවශ්‍ය වන්නේ එය යමක් තහවුරු කරන කේත පේළියක් පමණි. මෙම ප්‍රවේශයේ තවත් වාසියක් නම්, ඔබ පරීක්‍ෂා කරන්නේ කුමක් ද යන්න සහ පන්තියේ සහ ක්‍රමයේ නම් දෙස බැලීමෙන් ඔබ අපේක්ෂා කරන දේ පැහැදිලි වන හෙයින් එය පරීක්ෂණ ඉතා පහසුවෙන් කියවිය හැකි ය. ඔබට පරීක්ෂා කිරීමට අවශ්‍ය කුඩා අවස්ථා සියල්ලම ඔබ තේරුම් ගැනීමට පටන් ගන්නා විට සහ දෝෂ සොයා ගන්නා විට මෙයද වඩා හොඳ වනු ඇත. පංතියේ සහ ක්‍රම නාම දෙස බැලීමෙන් ඔබ අපේක්ෂා කරන දේ. ඔබට පරීක්ෂා කිරීමට අවශ්‍ය කුඩා අවස්ථා සියල්ලම ඔබ තේරුම් ගැනීමට පටන් ගන්නා විට සහ දෝෂ සොයා ගන්නා විට මෙයද වඩා හොඳ වනු ඇත. පංතියේ සහ ක්‍රම නාම දෙස බැලීමෙන් ඔබ අපේක්ෂා කරන දේ. ඔබට පරීක්ෂා කිරීමට අවශ්‍ය කුඩා අවස්ථා සියල්ලම ඔබ තේරුම් ගැනීමට පටන් ගන්නා විට සහ දෝෂ සොයා ගන්නා විට මෙයද වඩා හොඳ වනු ඇත.

සාමාන්‍යයෙන් මෙයින් අදහස් කරන්නේ [SetUp] ක්‍රමය තුළ ඇති කේතයේ අවසාන පේළිය [TestFixture] හි පුද්ගලික නිදර්ශන විචල්‍යයක දේපල වටිනාකමක් හෝ ප්‍රතිලාභ අගයක් ගබඩා කළ යුතු බවයි. එවිට ඔබට මෙම උදාහරණ විචල්‍යය පිළිබඳ විවිධ [ටෙස්ට්] ක්‍රම වලින් විවිධ දේ ප්‍රකාශ කළ හැකිය. පරීක්ෂණයට භාජනය වන වස්තුවෙහි අපේක්ෂිත තත්වයේ පවතින බවට දැන් සකසා ඇති විවිධ ගුණාංග මොනවාද යන්න පිළිබඳවද ඔබට ප්‍රකාශ කළ හැකිය.

සමහර විට ඔබ පරීක්‍ෂාවට භාජනය වන වස්තුව අපේක්ෂිත තත්වයට ගෙන යන බැවින් ඔබ වස්තුව අපේක්ෂිත තත්වයට ගෙන ඒමට පෙර අවුල් නොවූ බවට වග බලා ගැනීම සඳහා මඟ දිගේ ප්‍රකාශ කළ යුතුය. එවැනි අවස්ථාවකදී, එම අතිරේක ප්‍රකාශයන් [SetUp] ක්‍රමය තුළ දිස්විය යුතුය. [SetUp] ක්‍රමය තුළ යම්කිසි වැරැද්දක් සිදුවුවහොත්, ඔබ පරීක්ෂා කිරීමට අදහස් කළ අපේක්ෂිත තත්වයට වස්තුව කවදා හෝ පැමිණීමට පෙර පරීක්ෂණයේ යම් වැරැද්දක් ඇති බව පැහැදිලි වනු ඇත.

ඔබ මුහුණ දිය හැකි තවත් ගැටළුවක් නම් ඔබ විසි කිරීමට බලාපොරොත්තු වූ ව්‍යතිරේකයක් පරීක්ෂා කිරීමයි. ඉහත ආකෘතිය අනුගමනය නොකිරීමට මෙය ඔබව පොළඹවනු ඇත. කෙසේ වෙතත්, [SetUp] ක්‍රමය තුළ ඇති ව්‍යතිරේකය අල්ලා එය නිදර්ශන විචල්‍යයකට ගබඩා කිරීමෙන් එය තවමත් සාක්ෂාත් කරගත හැකිය. ව්‍යතිරේකය පිළිබඳ විවිධ දේ ප්‍රකාශ කිරීමට මෙය ඔබට ඉඩ සලසයි. පරීක්‍ෂාවට භාජනය වන වස්තුව පිළිබඳ වෙනත් කරුණු ද ඔබට ප්‍රකාශ කළ හැකිය. විසි කිරීම හැරුණු විට අනපේක්ෂිත අතුරු ආබාධ නොමැති බව තහවුරු කර ගන්න.

උදාහරණය (මෙය බහු ලිපිගොනු වලට වෙන් කරනු ඇත):

namespace Tests.AcctTests
{
    [TestFixture]
    public class no_events
    {
        private Acct _acct;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
        }

        [Test]
        public void balance_0() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }

    [TestFixture]
    public class try_withdraw_0
    {
        private Acct _acct;
        private List<string> _problems;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
            Assert.That(_acct.Balance, Is.EqualTo(0));
            _problems = _acct.Withdraw(0m);
        }

        [Test]
        public void has_problem() {
            Assert.That(_problems, Is.EquivalentTo(new string[] { "Withdraw amount must be greater than zero." }));
        }

        [Test]
        public void balance_not_changed() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }

    [TestFixture]
    public class try_withdraw_negative
    {
        private Acct _acct;
        private List<string> _problems;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
            Assert.That(_acct.Balance, Is.EqualTo(0));
            _problems = _acct.Withdraw(-0.01m);
        }

        [Test]
        public void has_problem() {
            Assert.That(_problems, Is.EquivalentTo(new string[] { "Withdraw amount must be greater than zero." }));
        }

        [Test]
        public void balance_not_changed() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }
}

එකම පරීක්ෂණයකදී බහුවිධ ප්‍රකාශයන් තිබීම ගැටලුවක් වන්නේ පරීක්ෂණය අසමත් වූ විට පමණි. එවිට ඔබට පරීක්ෂණය නිදොස් කිරීමට හෝ ව්‍යතිරේකය විශ්ලේෂණය කිරීමට සිදුවන්නේ එය අසාර්ථක වන්නේ කුමන ප්‍රකාශයද යන්න සොයා ගැනීමටය. එක් එක් පරීක්ෂණයෙහි එක් ප්‍රකාශයක් සමඟ සාමාන්‍යයෙන් වැරදි දේ හඳුනා ගැනීම පහසුය.

එකම ප්‍රකාශයේ දී ඔබට විවිධ කොන්දේසි ලෙස නැවත ලිවිය හැකි බැවින්, බහු ප්‍රකාශයන් සැබවින්ම අවශ්‍ය වන අවස්ථාවක් ගැන මට සිතිය නොහැක . කෙසේ වෙතත්, නරක ආදානය හේතුවෙන් පසුකාලීන පියවර බිඳ වැටෙනු ඇතැයි අවදානමට වඩා පියවර අතර අතරමැදි දත්ත සත්‍යාපනය කිරීමට ඔබට පියවර කිහිපයක් තිබේ නම් එය වඩාත් යෝග්‍ය වේ.

ඔබගේ පරීක්ෂණය අසමත් වුවහොත්, පහත දැක්වෙන ප්‍රකාශයන් ද බිඳී යනු ඇත්දැයි ඔබ නොදනී. බොහෝ විට, එයින් අදහස් වන්නේ ගැටලුවේ මූලාශ්‍රය සොයා ගැනීමට ඔබට වටිනා තොරතුරු මග හැරෙනු ඇති බවයි. මගේ විසඳුම වන්නේ එක් ප්‍රකාශයක් නමුත් අගයන් කිහිපයක් භාවිතා කිරීමයි:

String actual = "val1="+val1+"\nval2="+val2;
assertEquals(
    "val1=5\n" +
    "val2=hello"
    , actual
);

සියලු අසාර්ථක ප්‍රකාශයන් එකවර බැලීමට එය මට ඉඩ දෙයි. මම පේළි කිහිපයක් භාවිතා කරමි, මන්ද බොහෝ IDEs එක පැත්තකින් සංසන්දනය කිරීමේ සංවාදයක වචන වෙනස්කම් පෙන්වනු ඇත.

ඔබට එක් පරීක්ෂණ ශ්‍රිතයක බහුවිධ ප්‍රකාශයන් තිබේ නම්, ඔබ විසින් සිදු කරනු ලබන පරීක්ෂණයට ඒවා කෙලින්ම අදාළ වනු ඇතැයි මම අපේක්ෂා කරමි. උදාහරණයක් වශයෙන්,

@Test
test_Is_Date_segments_correct {

   // It is okay if you have multiple asserts checking dd, mm, yyyy, hh, mm, ss, etc. 
   // But you would not have any assert statement checking if it is string or number,
   // that is a different test and may be with multiple or single assert statement.
}

බොහෝ පරීක්ෂණ තිබීම (එය අධික ලෙස මරා දැමීමක් යැයි ඔබට හැඟෙන විට පවා) නරක දෙයක් නොවේ. අත්‍යවශ්‍ය හා අත්‍යවශ්‍ය පරීක්ෂණ පැවැත්වීම වඩා වැදගත් යැයි ඔබට තර්ක කළ හැකිය. SO, ඔබ අවධාරනය කරන විට, බහු ප්‍රකාශයන් ගැන ඕනෑවට වඩා කනස්සල්ලට පත්වීමට වඩා ඔබේ ප්‍රකාශයන් නිවැරදිව ස්ථානගත කර ඇති බවට වග බලා ගන්න. ඔබට එකකට වඩා අවශ්‍ය නම්, එකකට වඩා භාවිතා කරන්න.

ඒකක පරීක්ෂණයේ පරමාර්ථය වන්නේ අසමත් වන දේ පිළිබඳව ඔබට හැකි තරම් තොරතුරු ලබා දීම පමණක් නොව, වඩාත්ම මූලික ගැටලු නිවැරදිව හඳුනා ගැනීමට උපකාර කිරීමයි. එක් ප්‍රකාශයක් අසාර්ථක වන බව ඔබ තර්කානුකූලව දැනගත් විට හෝ වෙනත් වචන වලින් පරීක්ෂණය අතර පරායත්ත සම්බන්ධතාවයක් තිබේ නම්, එක පරීක්ෂණයකින් මේවා බහු ප්‍රකාශයන් ලෙස පෙරළීම අර්ථවත් කරයි. පරීක්ෂණ ප්‍රති results ල පැහැදිලිව අසමත් වීමෙන් පැටවීම නොකිරීමේ වාසිය මෙයට ඇත. මෙම සම්බන්ධතාවය නොපවතින අවස්ථාවක දී මනාපය ස්වාභාවිකවම මෙම ප්‍රකාශයන් තනි පරීක්ෂණවලට වෙන් කිරීම ය.

ඔබ අධික ලෙස සංකීර්ණ පරීක්ෂණ ලිවිය යුතු ආකාරයට ඒකක / පංති සැලසුම් කරන්නේ නම් එය පරීක්ෂණයේදී අඩු බරක් වන අතර වඩා හොඳ නිර්මාණයක් ප්‍රවර්ධනය කරයි.

ඔව්, අසමත් වූ පරීක්‍ෂණයක් මඟින් අසාර්ථකත්වය හඳුනා ගැනීමට ප්‍රමාණවත් තොරතුරු ලබා දෙන තාක් කල් බහුවිධ ප්‍රකාශයන් තිබීම සුදුසුය . මෙය ඔබ පරීක්‍ෂා කරන දේ සහ අසාර්ථක ප්‍රකාරයන් මත රඳා පවතී.

නිසි ඒකක පරීක්ෂණ හරියටම එක් හේතුවක් නිසා අසමත් විය යුතුය, එබැවින් ඔබ ඒකක පරීක්ෂණයකට එක් ප්‍රකාශයක් භාවිතා කළ යුතුය.

එවැනි සූත්‍රයන් ප්‍රයෝජනවත් යැයි මා කිසි විටෙකත් සොයාගෙන නැත (පංතියක් වෙනස් කිරීමට එක් හේතුවක් තිබිය යුතුය යන්න එවැනි උදව්වක් නොවන කියමනකට උදාහරණයකි). නූල් දෙකක් සමාන යැයි ප්‍රකාශයක් සලකා බලන්න, මෙය අර්ථකථන දෙකෙහි දිග සමාන වන අතර අනුරූප දර්ශකයේ එක් එක් අක්‍ෂරය සමාන වේ.

ඕනෑම ප්‍රකාශයක් ඕනෑම ප්‍රකාශයක් තනි ප්‍රකාශයක් ලෙස නැවත ලිවිය හැකි බවත්, ඕනෑම තනි ප්‍රකාශයක් කුඩා ප්‍රකාශ සමූහයකට දිරාපත් කළ හැකි බවත් අපට සාමාන්‍යකරණය කළ හැකිය.

එබැවින්, කේතයේ පැහැදිලිකම සහ පරීක්ෂණ ප්‍රති results ලවල පැහැදිලිකම කෙරෙහි පමණක් අවධානය යොමු කරන්න, එමඟින් ඔබ භාවිතා කරන ප්‍රකාශ ගණනට ප්‍රතිවිරුද්ධ ලෙස නොව මඟ පෙන්වීමට ඉඩ දෙන්න.

මෙම ප්‍රශ්නය ස්පැගටි සහ ලස ag ් code ා කේත ගැටළු අතර තුලනය කිරීමේ සම්භාව්‍ය ගැටලුවට සම්බන්ධ වේ.

පරීක්ෂණය ගැන කුමක් දැයි ඔබට අදහසක් නොමැති ස්පැගටි ගැටළුවට බහුවිධ ප්‍රකාශයන් පහසුවෙන් ලබා ගත හැකිය, නමුත් එක් පරීක්ෂණයකට තනි ප්‍රකාශයක් තිබීම විශාල ලස ag ් in ා එකක බහුවිධ පරීක්ෂණ පැවැත්වීමෙන් ඔබේ පරීක්ෂණය සමානව කියවිය නොහැකි වනු ඇත. .

සමහර ව්‍යතිරේක ඇත, නමුත් මේ අවස්ථාවේ දී පෙන්ඩලය මැද තබා ගැනීම පිළිතුර වේ.

පිළිතුර ඉතා සරලයි - ඔබ එකම ගුණාංගයක, එකම වස්තුවක හෝ වෙනස් වස්තූන් දෙකකට වඩා වෙනස් කරන ශ්‍රිතයක් පරීක්ෂා කරන්නේ නම් සහ ශ්‍රිතයේ නිරවද්‍යතාවය එම සියලු වෙනස්කම්වල ප්‍රති results ල මත රඳා පවතී නම්, ඔබට තහවුරු කිරීමට අවශ්‍යය එම සෑම වෙනස්කමක්ම නිසියාකාරව සිදු කර ඇති බව!

මට තාර්කික සංකල්පයක් පිළිබඳ අදහස ලැබෙයි, නමුත් ප්‍රතිලෝම නිගමනයෙන් කියැවෙන්නේ කිසිදු ශ්‍රිතයක් එක් වස්තුවකට වඩා වෙනස් නොකළ යුතු බවයි. නමුත් මගේ අත්දැකීම් අනුව, සෑම අවස්ථාවකම එය ක්‍රියාත්මක කළ නොහැකිය.

බැංකු ගනුදෙනුවක තාර්කික සංකල්පය ගන්න - බොහෝ අවස්ථාවන්හිදී එක් බැංකු ගිණුමකින් මුදලක් ආපසු ගැනීම එම මුදල වෙනත් ගිණුමකට එකතු කිරීම ඇතුළත් කළ යුතුය. ඔබට එම කරුණු දෙක වෙන් කිරීමට අවශ්‍ය නැත, ඒවා පරමාණුක ඒකකයක් සාදයි. ඔබට කාර්යයන් දෙකක් කිරීමට අවශ්‍ය විය හැකිය (ඉවත් කර ගන්න / එකතු කරන්න) ඒ අනුව වෙනස් ඒකක පරීක්ෂණ දෙකක් ලියන්න - ඊට අමතරව. නමුත් එම ක්‍රියාවන් දෙක එක් ගනුදෙනුවක් තුළ සිදුවිය යුතු අතර ගනුදෙනුව ක්‍රියාත්මක වන බවට සහතික කර ගැනීමටද ඔබට අවශ්‍යය. එවැනි අවස්ථාවකදී තනි පියවර සාර්ථක වූ බවට සහතික කර ගැනීම පමණක් ප්‍රමාණවත් නොවේ. ඔබගේ පරීක්ෂණයෙන් ඔබ බැංකු ගිණුම් දෙකම පරීක්ෂා කළ යුතුය.

ඔබ පළමු වරට ඒකක පරීක්ෂණයකදී පරීක්‍ෂා නොකරන, ඒ වෙනුවට ඒකාබද්ධ කිරීමේ හෝ පිළිගැනීමේ පරීක්ෂණයකදී වඩා සංකීර්ණ උදාහරණ තිබිය හැකිය. නමුත් එම සීමාවන් චතුර ලෙස ක්‍රියාත්මක වේ, IMHO! එය තීරණය කිරීම එතරම් පහසු නැත, එය තත්වයන් පිළිබඳ කාරණයක් සහ පෞද්ගලික මනාපයන් විය හැකිය. එක් අයෙකුගෙන් මුදල් ආපසු ගැනීම සහ එය වෙනත් ගිණුමකට එක් කිරීම තවමත් ඉතා සරල කාර්යයක් වන අතර අනිවාර්යයෙන්ම ඒකක පරීක්ෂණ සඳහා අපේක්ෂකයෙකි.

පොදුවේ “එක් හේතුවක් නිසා පමණක් අසමත් වීම” සමඟ මම එකඟ නොවෙමි. වඩා වැදගත් දෙය නම් පරීක්ෂණ කෙටි වන අතර පැහැදිලිව කියවන ඉමෝ ය.

මෙය සැමවිටම සාක්ෂාත් කරගත නොහැකි අතර පරීක්ෂණයක් සංකීර්ණ වූ විට (දිගු) විස්තරාත්මක නමක් සහ අඩු දේවල් පරීක්ෂා කිරීම වඩාත් අර්ථවත් කරයි.