නිෂ්පාදනයේ දෝෂයක් හමු වූ විට මම හිතාමතාම ගොඩනැගීම බිඳ දැමිය යුතුද?

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

මගේ සගයන් කිහිප දෙනෙකු අසමත් වී ඇත්තේ අසමත් ඒකක පරීක්ෂණයක් පරීක්ෂා නොකළ යුතු බවයි. සාමාන්‍ය ටීඩීඩී පිළිවෙත් අනුව මම මෙම මතය සමඟ එකඟ වෙමි, නමුත් නිෂ්පාදන දෝෂ වෙනස් ලෙස හැසිරවිය යුතු යැයි මම සිතමි - සියල්ලට පසු ඔබට ඉඩ දිය යුත්තේ ඇයි? දන්නා අඩුපාඩු සමඟ සාර්ථක වීමට ගොඩනැඟීමක් ද?

මෙම තත්වය හැසිරවීම සඳහා වෙනත් අයෙකුට ඔප්පු කළ හැකි උපාය මාර්ග තිබේද? මම හිතාමතාම ගොඩනැගීම බිඳ දැමීම අනෙක් කණ්ඩායම් සාමාජිකයින්ට බාධාවක් විය හැකි නමුත් එය සම්පූර්ණයෙන්ම රඳා පවතින්නේ ඔබ ශාඛා භාවිතා කරන ආකාරය මත ය.

අපගේ උපායමාර්ගය නම්:

අසමත් පරීක්ෂණයකදී පරීක්ෂා කරන්න, නමුත් එය සමඟ විවරණය කරන්න @Ignore("fails because of Bug #1234").

ඒ ආකාරයෙන්, පරීක්ෂණය පවතී, නමුත් ගොඩනැගීම කැඩී යන්නේ නැත.

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

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

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

දන්නා අඩුපාඩු සමඟ ගොඩනැගීමට සාර්ථක වීමට ඔබට අවශ්‍ය ඇයි?

මන්ද සමහර විට ඔබට කාල සීමාවන් ඇත. නැතහොත් දෝෂය ඉතා සුළු බැවින් ඒකකය පරීක්ෂා කර එය නිවැරදි කිරීමට අවශ්‍ය දින කිහිපයක් නිෂ්පාදන නැව්ගත කිරීම ප්‍රමාද කිරීම වටී නැත.

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

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

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

බොහෝ ගොඩනංවන සේවාදායකයන් කාලයත් සමඟ පරීක්ෂණ වල තත්වය නිරීක්ෂණය කරන අතර, එය ප්‍රතිගාමීත්වයට එරෙහිව එකතු කළ දා සිට අසමත් වූ පරීක්ෂණයකට වෙනස් වර්ගීකරණයක් ලබා දෙනු ඇත (පරීක්ෂණය සමත් වීමට සහ තවදුරටත් සිදු නොවන). ප්‍රතිගාමීත්වය සිදුවිය.

අසමත් පරීක්ෂණය එකතු කළ යුතු යැයි මම තර්ක කරමි, නමුත් පැහැදිලිවම "අසමත් පරීක්ෂණයක්" ලෙස නොවේ.

En බෙන් වොයිට් ඔහුගේ පිළිතුරෙන් පෙන්වා දෙන පරිදි , අසමත් පරීක්ෂණයක් අනිවාර්යයෙන්ම “ගොඩනැගීම බිඳ දැමිය යුතු” නොවේ. මම හිතන්නේ පාරිභාෂිතය කණ්ඩායමෙන් කණ්ඩායමට වෙනස් විය හැකි නමුත් කේතය තවමත් සම්පාදනය වන අතර නිෂ්පාදනයට තවමත් අසමත් පරීක්ෂණයකින් නැව්ගත කළ හැකිය.

මෙම තත්වය තුළ ඔබ ඔබෙන්ම අසාගත යුතු දේ නම්,

ඉටු කිරීමට අදහස් කරන පරීක්ෂණ මොනවාද?

සෑම කෙනෙකුම කේතය ගැන හොඳ හැඟීමක් ඇති කිරීම සඳහා පරීක්ෂණ තිබේ නම්, කේතය ගැන සෑම කෙනෙකුටම නරක හැඟීමක් ඇති කිරීම සඳහා අසමත් පරීක්ෂණයක් එක් කිරීම produc ලදායී බවක් නොපෙනේ. නමුත් එසේ නම්, පරීක්ෂණ මුලින් කොතරම් tive ලදායීද?

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

පළමුව නිවැරදි කළ යුතු දෝෂය එයයි . ඔබ "අසමත් පරීක්ෂණයක් එකතු නොකරයි." ඔබ කරන්නේ නිවැරදි පරීක්ෂණ ව්යාපාර අවශ්යතා පිළිබඳව වඩා නිවැරදි පිළිබිඹුවක් විය. කේතය එම පරීක්ෂණ සමත් වීමට අසමත් වුවහොත් එය හොඳ දෙයකි. එයින් අදහස් වන්නේ පරීක්ෂණ ඔවුන්ගේ කාර්යය ඉටු කරන බවයි.

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

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

එය වෙනත් ආකාරයකින් පැවසීමට ... ගොඩනැගීම දැනටමත් කැඩී ඇත. ඔබ තීරණය කරන්නේ එම කාරණය කෙරෙහි අවධානය යොමු කළ යුතුද නැද්ද යන්නයි.

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

දෝෂය නිවැරදි වන තෙක් ඔබ අසමත් වන බව ඔබ දන්නා පරීක්ෂණයක් ලිවීම හොඳ අදහසකි, එය TDD හි පදනමයි.

ගොඩනැගීම බිඳ දැමීම නරක අදහසකි. මන්ද? එයට හේතුව එය සවි කරන තුරු කිසිවක් ඉදිරියට යා නොහැකි බවයි. එය සංවර්ධනයේ අනෙක් සියලුම අංග අවහිර කරයි.

උදාහරණ 1
ඔබගේ යෙදුම බොහෝ සංරචක සහිතව විශාල නම් කුමක් කළ යුතුද? එම සංරචක වෙනත් කණ්ඩායම් විසින් ඔවුන්ගේම නිදහස් චක්‍රයක් සමඟ වැඩ කරන්නේ නම් කුමක් කළ යුතුද? දැඩි! ඔබේ දෝෂ නිරාකරණය සඳහා ඔවුන් බලා සිටිය යුතුය!

උදාහරණ 2
පළමු දෝෂය නිවැරදි කිරීමට අපහසු නම් සහ වැඩි ප්‍රමුඛතාවයක් ඇති තවත් දෝෂයක් ඔබ සොයා ගන්නේ නම් කුමක් කළ යුතුද? දෙවන දෝෂය සඳහා වන ගොඩනැගීමද ඔබ බිඳ දමනවාද? දෙකම නිවැරදි වන තුරු ඔබට දැන් ගොඩනගා ගත නොහැක . ඔබ කෘතිම යැපීමක් නිර්මාණය කර ඇත.

පරීක්ෂණය අසමත් වීම ගොඩනැගීම නැවැත්වීමට තර්කානුකූල හේතුවක් නොමැත. මෙය දන්නා දෝෂ සහිත ගොඩනැඟිල්ලක් මුදා හැරීමේ වාසි සහ අවාසි කිරා මැන බැලීමට dev කණ්ඩායම (සමහර විට කළමනාකරණ සාකච්ඡාව සමඟ) ගත යුතු තීරණයක්. මෘදුකාංග සංවර්ධනයේදී මෙය ඉතා සුලභ ය, බොහෝ ප්‍රධාන මෘදුකාංග අවම වශයෙන් දන්නා ගැටළු කිහිපයක් සමඟ මුදා හරිනු ලැබේ .

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

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

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

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

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

ඔබේ කණ්ඩායමට එම මානසිකත්වයට පිවිසීමට උදව් කිරීමට ඔබට අවශ්‍ය නැත.

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

ඔබ යම් ආකාරයකින් දෝෂය පරීක්‍ෂණයක් ලෙස පරීක්ෂා කර බැලිය යුතු යැයි මා සිතන අතර, ඔබ එය නිවැරදි කළ විට එය නැවත සිදු නොවන අතර යම් ආකාරයකින් එයට ප්‍රමුඛත්වය දෙන විට, ගොඩනැගීම (/ පරීක්ෂණ) බිඳ නොදැමීම වඩාත් සුදුසු යැයි මම සිතමි. . හේතුව, පසුව බිඳුණු පරීක්ෂණ ඔබේ බිඳුණු පරීක්ෂණය පිටුපස සැඟවී තිබීමයි. එබැවින් මෙම දෝෂය සඳහා බිඳුණු පරීක්ෂණයකින් පරීක්ෂා කිරීමෙන් ඔබ ඉල්ලා සිටින්නේ මෙම දෝෂය නිවැරදි කිරීම සඳහා මුළු කණ්ඩායමම ඔවුන්ගේ වැඩ කටයුතු වෙන් කරන ලෙසයි. එය සිදු නොවන්නේ නම්, ඔබට සොයාගත නොහැකි බිඳවැටීම් බිඳ දැමිය හැකිය.

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

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