ඒකක පරීක්ෂණයක් නොකිරීම සුදුසු වන්නේ කවදාද?

143

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

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

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

ඒ නිසා මම සෑම අවස්ථාවකම එකම නිගමනයකට එළඹෙමි. ආයෝජන වලින් ලැබෙන ප්‍රතිලාභ ඉතා අඩුය.

යමෙකු ඔවුන්ගේ කුලී දිනය මත පදනම්ව සමාගමෙහි ගත කළ වසර ගණන ගණනය කිරීම වැනි මම ඇල්ගොරිතමයක් නිවැරදිව ලියා ඇති බව සහතික කිරීම සඳහා මම ඉඳහිට පරීක්ෂණ කිහිපයක් සකස් කර ඇත්තෙමි. නමුත් කේත ආවරණ දෘෂ්ටි කෝණයකින් මම මගේ කේතයෙන් 1% ක් ආවරණය කර ඇත්තෙමි.

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

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

unit-testing tdd

— කෙන් පෙස්පීසා
source

1

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

— කෙන් පෙස්පීසා

1

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

— ජෝන් කැස්ටර්

2

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

— ඕ රූනි

1

මෙය සැබවින්ම පිළිතුරක් නොවේ, නිරීක්ෂණයක් පමණි ... "අවශ්‍යතා නිතර නිතර වෙනස් වන නිසා" ඒකක පරීක්ෂාවට එරෙහි ඔබේ තර්කය මට මතක් කර දෙන්නේ මා වැඩ කරන ස්ථානයේ ඇසෙන ප්‍රතිලෝම තර්කයයි: "අපගේ වැඩසටහන් ස්ථිතිකයි, පරීක්ෂණයේ තේරුම කුමක්ද? එය කිසිසේත් වෙනස් නොවේ! ” ;)

— බේන්

3

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

— නියාමියෝ ද ගලියන්තෝප්

85

පරීක්ෂණ පිළිබඳ මා දුටු උදාහරණ බොහොමයක් කේතයේ සියලුම අංග ආවරණය වන පරිදි මිනිත්තුවට බැස යයි.

ඒ නිසා? ඔබට සියල්ල පරීක්ෂා කිරීමට අවශ්‍ය නැත . අදාළ දේවල් පමණි.

මම එකම සංවර්ධකයා වන අතර සමස්ත ව්‍යාපෘතියේ කේතයට මම ඉතා සමීප බැවින්, ලිවීමේ-පසුව-අතින්-පරීක්ෂණ රටාවක් අනුගමනය කිරීම වඩා කාර්යක්ෂම වේ.

එය ඇත්ත වශයෙන්ම අසත්‍යයකි. එය වඩා කාර්යක්ෂම නොවේ. එය ඇත්තෙන්ම පුරුද්දකි.

වෙනත් ඒකල සංවර්ධකයින් කරන්නේ ස්කෙච් එකක් හෝ දළ සටහනක් ලිවීම, පරීක්ෂණ අවස්ථා ලිවීම සහ අවසන් කේතය සමඟ දළ සටහන පුරවන්න.

එය ඉතා කාර්යක්ෂමයි.

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

ඒකත් බොරු. පරීක්ෂණ ඇදගෙන යාම නොවේ. අවශ්‍යතා වෙනස් කිරීම යනු ඇදගෙන යාමයි.

අවශ්‍යතා පිළිබිඹු කිරීම සඳහා ඔබ පරීක්ෂණ නිවැරදි කළ යුතුය. ඒවායේ කුඩා හෝ ඉහළ මට්ටමේ වේවා; පළමුව ලියා හෝ අවසන් වරට ලියා ඇත.

පරීක්ෂණ සමත් වන තුරු කේතය සිදු නොවේ. මෘදුකාංගයේ විශ්වීය සත්‍යය එයයි.

ඔබට සීමිත "මෙන්න එය" පිළිගැනීමේ පරීක්ෂණය තිබිය හැකිය.

නැතහොත් ඔබට ඒකක පරීක්ෂණ කිහිපයක් කළ හැකිය.

නැත්නම් ඔබට දෙකම තිබිය හැකිය.

නමුත් ඔබ කුමක් කළත්, මෘදුකාංගය ක්‍රියාත්මක වන බව පෙන්වීමට සෑම විටම පරීක්ෂණයක් තිබේ.

මම යෝජනා කරන්නේ ටිකක් විධිමත් බව සහ හොඳ ඒකක පරීක්ෂණ මෙවලම් කට්ටලය එම පරීක්ෂණය වඩාත් ප්‍රයෝජනවත් කරයි.

— එස්.ලොට්
source

8

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

— කෙන් පෙස්පීසා

9

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

— එස්.ලොට්

3

En කෙන් පෙස්පීසා: නැත. පිළිතුරු වල සමබරතාවයක් ඇත. බිංදුවෙන් බෙදීම හරිදැයි ඔබ ඇසුවොත්, හේතුවක් නිසා එක් මාර්ගයකට නැඹුරු වන ප්‍රතිචාර ඔබට ලැබෙනු ඇත. ඔබ ඇසුවේ නම් නම් sqrt(-1)පූර්ණ සංඛ්යාවක් විය යුතු, ඔබ එක් ක්රමයක් පක්ෂයට හේත්තු වී විශාල ප්රතිචාර ලබා දෙන්න. ශේෂය "කෙසේද" සහ "කුමන අනුපිළිවෙල" වටා ඇත. හිස් කාරණය නම් ඔබ පරීක්ෂා කළ යුතු බවයි. එබැවින් පරීක්ෂණ පළමුව ලියා ඒවා ක්‍රියාත්මක වන බවට වග බලා ගන්න.

— එස්.ලොට්

21

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

— බිල්තෝර්

12

"පරීක්ෂණ සමත් වන තුරු කේතය සිදු නොවේ" - ඇත්ත වශයෙන්ම නොවේ, IMO. කේතය ආරම්භ වන්නේ එය පරීක්ෂණ සමත් වූ විට ය. කේතය වසරක් හෝ දෙකක් සජීවීව පවතින අතර විශාල, ක්‍රියාකාරී සහ නොඉවසිලිමත් පරිශීලක පදනමක් සහිත ආතති පරීක්ෂණ සහ ඒකාබද්ධතා පරීක්ෂණ වලට භාජනය වන තුරු එය සිදු නොවේ. සැබවින්ම ගණන් කරන එකම පරීක්ෂණය එයයි.

— දෛශික

113

ඔබ ඇසිපිය නොහෙලා ධාවනය කළ හැකි සහ හරිත හෝ රතු එළියක් දැල්විය හැකි පරීක්ෂණ කට්ටලයක් ඇතැයි සිතන්න. මෙම පරීක්ෂණ කට්ටලය සෑම දෙයක්ම අත්හදා බැලූ බව සිතන්න ! පරීක්ෂණ කට්ටලය ක්‍රියාත්මක කිරීම සඳහා ඔබට කළ යුතුව තිබුණේ type T ටයිප් කිරීම පමණක් යැයි සිතන්න. මෙය ඔබට ලබා දෙන බලය කුමක්ද?

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

ඔව්, ඔබට ඒ සියල්ල කළ හැකිය! කාලයත් සමඟ ඔබේ කේතයට කුමක් සිදුවේද? එය පිරිසිදු කිරීමට අවදානමක් නොමැති නිසා එය පිරිසිදු හා පිරිසිදු වනු ඇත.

ඔබේ උරහිස මත කුඩා සුරංගනා කතාවක් ඇතැයි සිතමු. ඔබ කේත රේඛාවක් ලියන සෑම අවස්ථාවකම, සුරංගනා විසින් පරීක්ෂණ කට්ටලයට යමක් එකතු කරනු ඇති අතර එමඟින් එම කේත රේඛාව එය කිරීමට අදහස් කළ දේ කළ බව පරීක්‍ෂා කරන ලදී. සෑම තත්පර දෙකකට වරක් ඔබට hit T පහර දී ඔබ ලියූ අවසාන කේත පේළිය ක්‍රියාත්මක වන බව බලන්න.

ඔබ කොපමණ නිදොස් කිරීමක් කරයි කියා ඔබ සිතනවාද?

මෙය මන asy කල්පිතයක් ලෙස පෙනේ නම්, ඔබ හරි. නමුත් යථාර්ථය ඊට වඩා වෙනස් නොවේ. ඇහිබැම තත්පර කිහිපයකින් ප්‍රතිස්ථාපනය කරන්න, සහ සුරංගනා කතාව TDD හික්මවීම සමඟ ප්‍රතිස්ථාපනය කරන්න, ඔබට එය බොහෝ සෙයින් ලැබී තිබේ.

ඔබ මීට වසරකට පෙර ගොඩනඟන ලද පද්ධතියකට නැවත පැමිණෙන බව කියමු, ඔබට කේන්ද්‍රීය වස්තුවක් නිර්මාණය කරන්නේ කෙසේද යන්න අමතක වී ඇත. එම වස්තුව නිර්මාණය කළ හැකි සෑම ආකාරයකින්ම නිර්මාණය කරන පරීක්ෂණ තිබේ. ඔබට එම පරීක්ෂණ කියවා ඔබේ මතකය විග්‍රහ කළ හැකිය. API එකක් ඇමතිය යුතුද? එම API එක හැඳින්විය හැකි සෑම ආකාරයකින්ම හඳුන්වන පරීක්ෂණ තිබේ. මෙම පරීක්ෂණ කුඩා ලියකියවිලි වන අතර එය ඔබට තේරෙන භාෂාවකින් ලියා ඇත. ඒවා සම්පූර්ණයෙන්ම සැක සහිත ය. ඒවා ක්‍රියාත්මක වන තරමට විධිමත් ය. ඔවුන්ට යෙදුම සමඟ සමමුහුර්තකරණයෙන් ඉවත් විය නොහැක!

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

— බොබ් මාමා.
source

30

බොබ් මාමා? ඔබේ සිතුවිලි මෙහි ලබා ගැනීම සතුටක්. TDD හි ප්‍රතිලාභ පිළිබඳව මම ඔබ සමඟ එකඟ වෙමි, ඇත්ත වශයෙන්ම එහි කිසිදු තර්කයක් නොමැත. ප්රශ්නය වන්නේ කාලය ආයෝජනය කිරීම සහ ROI ය. මේ දේවල් සලකා බැලීම මට මෝඩකමක් නොවේ. ව්‍යාපෘතියක් මට TDD වලින් තොරව නිම කිරීමට 50% වැඩි කාලයක් ගතවනු ඇතැයි සිතන්න. සුරංගනා කතාව මට පවසන්නේ එය ව්‍යාපෘතියේ ජීවිත කාලය තුළ අතින් පරීක්‍ෂා කිරීමෙන් 10% ක කාලයක් පමණක් ඉතිරි කර ගත හැකි බවයි. එය මන asy කල්පිතයක් සේ පෙනෙන්නට තිබුණද, එය සමහර ව්‍යාපෘති සමඟ මුළුමනින්ම පිළිගත හැකි දෙයක් ලෙස මම දකිමි.

— කෙන් පෙස්පීසා

12

En කෙන් "ව්‍යාපෘතියක් නොමැතිව මට වඩා TDD සමඟ අවසන් කිරීමට 50% වැඩි කාලයක් ගතවනු ඇතැයි සිතන්න". එය හරියටම මට මන asy කල්පිතයක් වගේ. ඇත්ත වශයෙන්ම, එය සනාථ කිරීම සඳහා කිසිදු සාක්ෂියක් නොමැතිව ඔබ එම ස්ථානය එම ස්ථානයේදීම සාදා ඇති බවක් පෙනේ.

— රයින් හෙන්රිච්

19

@ රයින් හෙන්රිච් - ඇත්ත වශයෙන්ම මම අංකය සකස් කළෙමි, එය උපකල්පිත ප්‍රකාශයකි. ව්‍යාපෘතියකට TDD සැලකිය යුතු කාලයක් එකතු කරන බව මම පෙන්වා දෙමි, ඒ වෙනුවට මම සමාන හෝ වඩා හොඳ වටිනාකමක් ලබා ගන්නේද යන්න සලකා බැලිය යුතුය. TDD හි සාරධර්ම පිළිබඳව ඔබ මට ඒත්තු ගැන්විය යුතු නැත, මට විශ්වාසයි. නමුත් එය කෝකටත් තෛලයක් නොවේ.

— කෙන් පෙස්පීසා

12

E රයින්, “ලබා ගත හැකි සාක්ෂි” යනු කුමක්ද? කරුණාකර විස්තර කරන්න.

— කෙන් පෙස්පීසා

23

N අන්කල් බොබ් "ඇහිබැම තත්පර කිහිපයකින් ප්‍රතිස්ථාපනය කරන්න": ඔබ විහිළුවක්, ඇත්තෙන්ම. TDD හොඳ මෙවලමක් වන නමුත් ඔබට අදාළ කොටස් පමණක් පරීක්ෂා කළ යුතුය. අවශ්‍යතා ඉතා ඉක්මණින් වෙනස් වන විට මෙය විශේෂයෙන් සත්‍ය වේ: ඔබ නිරන්තරයෙන් වෙනස් වන පන්ති සඳහා පරීක්ෂණ ලිවීම හා විසි කිරීම සිදු කරයි. මම කියන්නේ නැහැ ටීඩීඩී නරකයි, එය බුද්ධිමත්ව භාවිතා කළ යුතු අතර ඔබ යෝජනා කරන පරිදි යාන්ත්‍රිකව භාවිතා නොකළ යුතුයි.

— ජෝජියෝ

34

ඔබ සිදුකරන අත්වැරැද්ද නම්, ක්ෂණික ප්‍රතිලාභයක් නොමැති කාල ආයෝජනයක් ලෙස ඔබ පරීක්ෂණය දකින බවයි. එය අනිවාර්යයෙන්ම එසේ ක්‍රියා නොකරයි.

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

දෙවනුව ඒවා ධාවනය කිරීමෙන් පරීක්ෂණ වලදී මතු විය හැකි දෝෂ අනාවරණය වේ.

තෙවනුව ඒවා ධාවනය කිරීමෙන් සමහර විට දෝෂ පෙන්වනුයේ වෙනත් ආකාරයකින් පරීක්ෂාවට නොපැමිණෙන අතර පසුව නිෂ්පාදනයේ දී බූරුවාට ඔබව දෂ්ට කරනු ඇත.

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

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

මගේ අත්දැකීම නිරන්තරයෙන් පැවතියේ ව්‍යාපෘතියක් සංවර්ධනය කිරීමේදී යහපත් ඒකක පරීක්ෂණ පැවැත්වීම සැමවිටම ක්‍රියාවලිය වේගවත් හා විශ්වාසදායක කර ඇති බවයි.

— ග්ලෙනට්‍රෝන්
source

2

En කෙන්, පරීක්ෂණ කට්ටල යනු ක්‍රියාත්මක කළ හැකි ආකාරයෙන් පිරිවිතර වේ.

33

JUnit (ජාවා ඒකක පරීක්ෂණ රාමුව) හි සිටින පුද්ගලයින්ට දර්ශනයක් තිබේ , එය පරීක්ෂා කිරීමට තරම් සරල නම්, එය පරීක්ෂා නොකරන්න . ඔවුන්ගේ ප්‍රායෝගික පරිචයන් නිතර අසන ප්‍රශ්න කියවීමට මම තරයේ නිර්දේශ කරමි .

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

පරීක්ෂණයක් ලියන්න
එය අසාර්ථක වන ආකාරය බලන්න (ඔබට යමක් කිරීමට ඇති බව ඔප්පු කරන්න)
පරීක්ෂණය සමත් වීමට අවශ්‍ය දේ ලියන්න - තවත් නැත.
එය සමත් වීම නරඹන්න (ඔව්!)
ප්‍රතික්‍රියාකාරකය (එය වඩා හොඳ කරන්න)
සේදීම, මෙයට පිළියමක් සහ නැවත නැවත කරන්න

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

දැන්, ඔබට C # ගුණාංග වැනි දෑ පරීක්ෂා කිරීමට අවශ්‍යද? මේ ආකාරයට අර්ථ දක්වා ඇති දේපලක් ගැන සිතන්න:

bool IsWorthTesting {get; set;}

පිළිතුර "නැත" යන්න පරීක්ෂා කිරීම වටී නැත, මන්ද මේ අවස්ථාවේදී ඔබ භාෂා අංගය පරීක්ෂා කරමින් සිටී. සී # වේදිකා කොල්ලෝ එය නිවැරදිව තේරුම් ගත් බව විශ්වාස කරන්න. අමතරව, එය අසාර්ථක විය නම්, හැකි ඔබ විසින් අදාල කරුණ නිවැරදි කිරීමට ද?

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

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

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

— බෙරින් ලොරිට්ස්
source

24

ඔබ පරීක්ෂා කිරීමේ පිරිවැය දෝෂවල පිරිවැය සමඟ සමතුලිත කළ යුතුය.

ගොනුවක් විවෘත කරන ශ්‍රිතයක් සඳහා පේළි 10 ක ඒකක පරීක්ෂණයක් ලිවීම, එහිදී අසමත් වීම “ගොනුව සොයාගත නොහැකි” වේ.

සංකීර්ණ දත්ත ව්‍යුහයකට සංකීර්ණ දෙයක් කරන ශ්‍රිතයක් - එවිට පැහැදිලිවම ඔව්.

උපක්‍රමශීලී බිට් අතර වේ. නමුත් ඒකක පරීක්ෂණවල සැබෑ වටිනාකම විශේෂිත ශ්‍රිතය පරීක්ෂා නොකරන බව මතක තබා ගන්න, එය ඒවා අතර ඇති උපායශීලී අන්තර්ක්‍රියා පරීක්ෂා කරයි. එබැවින් ඒකක පරීක්ෂණයකින් එක් කේතයක වෙනසක්, පේළි 1000 ක් away තින් වෙනත් මොඩියුලයක යම් කාර්යයක් බිඳ වැටෙන බව පෙන්වන කෝපි වල බර වටී.

— මාටින් බෙකට්
source

23

පරීක්ෂා කිරීම සූදුවකි.

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

ඕනෑම ඔට්ටුවක් මෙන්, සමහර විට ඔබ දිනයි, සමහර විට ඔබට අහිමි වේ.

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

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

— hotpaw2
source

3

හොඳ පිළිතුරක්. මගේ මුල් ප්‍රශ්නයට සැබවින්ම පිළිතුරු සපයන කිහිප දෙනාගෙන් කෙනෙකි. මෙම ලිපිය ලිවීමෙන් පසු මම පරීක්ෂණ ලෝකයට ගිලී සිටිමි (මම එයට කැමතියි btw.) එය භාවිතා කරන්නේ කවදාදැයි දැන ගැනීමට පෙර (හෝ නැත) මම එය තව දුරටත් තේරුම් ගත යුතුය. මෙහි දක්වා ඇති බොහෝ හේතු නිසා මම එය නිතරම භාවිතා කිරීමට කැමැත්තෙමි. නමුත් එය අවසානයේදී රඳා පවතින්නේ මා එය කොතරම් වේගයෙන් ලබා ගන්නේද යන්න මතය, මන්දයත් අවසානයේ එය මගේ කාලය / මගේ සමාගම / සේවාදායකයාගේ පාලනය යටතේ පවතින සූදුවක් වන අතර බොහෝ විට ඔවුන් ව්‍යාපෘති ත්‍රිකෝණයේ පහළ කොන වෙත අවධානය යොමු කරයි: en. wikipedia.org/wiki/Project_triangle

— කෙන් පෙස්පීසා

11

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

ඔබට දෝෂ සහිත වීමට අවශ්‍ය කේතය පරික්ෂා නොකරන්න.

— නික් හොජ්ස්
source

9

මගේ දන්ත වෛද්‍යවරයා පවසන කියමන මට මතක් කර දෙයි: ඔබේ දත් සියල්ලම පාවීමට අවශ්‍ය නැත, ඔබට තබා ගැනීමට අවශ්‍ය ඒවා පමණි.

— කෙන් පෙස්පීසා

මම ඒ ගැන සිතීමට හේතු වූයේ එයයි. ;-)

— නික් හොජ්ස්

8

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

TDD සහ ඒකක පරීක්ෂණ එකම දෙයක් නොවේ.

ඔබට කේතය ලිවිය හැකිය, පසුව ඒකක පරීක්ෂණ එකතු කරන්න. එය TDD නොවන අතර අමතර වැඩ ගොඩක් වේ.

TDD යනු රතු ආලෝකයේ ලූපයක කේතීකරණ ක්‍රමයයි. කොළ එළිය. ප්‍රතික්‍රියාකාරක පුනරාවර්තන.

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

TDD හි ඇති එක් වාසියක් නම්, එය සුළු දේවල් ගැන සිතීමේ අවශ්‍යතාවය අඩු කිරීමයි. ඕෆ්-වන් දෝෂ වැනි දේවල් අතුරුදහන් වේ. එය නැවත ලබා දෙන ලැයිස්තුව 0 හෝ 1 කින් ආරම්භ වේදැයි සොයා ගැනීමට ඔබට API ලියකියවිලි හරහා දඩයම් කිරීමට අවශ්‍ය නැත, එය කරන්න.

— පෝල් බුචර්
source

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

— සිතිය

1

ඇත්ත වශයෙන්ම, TDD ලිවීම API එකක් ගවේෂණය කිරීමට කදිම ක්‍රමයකි (ක්‍රියාකාරීත්වය ලේඛනගත කිරීමේ අරමුණු සඳහා උරුම කේත පදනමක් ඇතුළුව).

— ෆ්‍රෑන්ක් ෂෙයාර්

එම API කවදා හෝ වෙනස් වුවහොත් එයද ඉතා ප්‍රයෝජනවත් වේ ... ඔබට හදිසියේම අසාර්ථක පරීක්ෂණ කිහිපයක් තිබේ :-)

— bitsoflogic

En කෙන් පෙස්පීසා, එය අනිවාර්යයෙන්ම ඉක්මන් වේ - එය 0 හෝ 1 යැයි ඔබ සිතන්නේද යන්න මත පදනම්ව කේතය ලියන්න, එය ක්‍රියාත්මක කරන්න, අවශ්‍ය නම් එය නිවැරදි කරන්න. බොහෝ විට, ඔබ නිවැරදියි, ඔබ එය සොයා බැලීම මග හැරෙනු ඇත, ඔබ වැරදියි නම්, තත්පර 10 ක් ඇතුළත ඔබ දන්නවා.

— පෝල් බුචර්

ඉතා රසවත් ප්‍රතිලාභයක්. මම ඒ වගේ.

— කෙන් පෙස්පිසා

3

මම වැඩ කළේ අපි හැම දෙයක්ම පාහේ පරීක්ෂා කළ පද්ධතියක. පරීක්ෂා කිරීම සඳහා කැපී පෙනෙන utions ාතන වූයේ PDF සහ XLS ප්‍රතිදාන කේතයයි.

මන්ද? දත්ත එක්රැස් කරන ලද කොටස් පරීක්ෂා කිරීමට අපට හැකි වූ අතර ප්‍රතිදානය නිර්මාණය කිරීම සඳහා භාවිතා කළ ආකෘතිය ගොඩනඟා ඇත. පී.ඩී.එෆ් ලිපිගොනු වෙත යන්නේ කුමන මාදිලියේ කොටස්දැයි සොයා බැලූ කොටස් පරීක්ෂා කිරීමට ද අපට හැකි විය. පී.ඩී.එෆ්. මුළුමනින්ම ආත්මීය නිසා අපට එය හොඳින් පෙනේ දැයි පරීක්ෂා කිරීමට අපට නොහැකි විය. පී.ඩී.එෆ් හි ඇති සියලුම කොටස් සාමාන්‍ය පරිශීලකයෙකුට කියවිය හැකි දැයි පරීක්ෂා කිරීමට අපට නොහැකි විය . නැතහොත් දත්ත කට්ටලය සඳහා බාර් සහ පයි ප්‍රස්ථාර අතර තේරීම නිවැරදි නම්.

ප්‍රතිදානය ආත්මීය වීමට යන්නේ නම්, ඔබට උත්සාහ කළ යුතු දේ කළ හැකි ඒකක පරීක්ෂණයක් නොමැත.

— සල්
source

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

— sleske

2

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

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

ඔබ ද නැහැ ඇති වූ minutae පරීක්ෂා කිරීමට. ඔබට අමිහිරි තොරතුරු ලබා ගැනීමට අවශ්‍ය නැතිනම් ඔබේ විශේෂාංග ආවරණය වන පරිදි ඒකාබද්ධතා පරීක්ෂණ ලිවිය හැකිය ... IMO, සමහර ඒකක පරීක්ෂණ මඟින් භාෂාව සහ වේදිකාව පරීක්‍ෂා කිරීම මිස කේතය නොවේ.

TL; DR එය කිසි විටෙකත් සුදුසු නොවේ.

— ස්ටීවන් එවර්ස්
source

2

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

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

ඔබ පැරණි කේතය වෙනස් කරන විට හෝ ප්‍රතික්‍රියා කරන විට ප්‍රතිගාමී වීම වැළැක්වීම සඳහා ඒකක පරීක්ෂණ ද ඉතා වැදගත් වේ. ඔබේ වෙනස පැරණි කේතය බිඳ දමා නැති බව ඔවුන් ඔප්පු නොකරන නමුත් ඔවුන් ඔබට විශාල විශ්වාසයක් ලබා දෙයි (ඔවුන් පා pass මාලාවක් පවතින තාක් කල් :))

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

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

— ස්ටීව්
source

ප්‍රතිගාමී වීම වැළැක්වීම සහ විශ්වාසය එකතු කිරීම පිළිබඳ සිතුවිලි වලට මම කැමතියි. මට හරියටම පරීක්ෂණ එකතු කිරීමට අවශ්‍ය හේතු ඒවාය.

— කෙන් පෙස්පීසා

2

මට හමු වූ ඉතා හොඳ පිළිතුරු දෙකක් මෙහි ඇත:

පෙනෙන පරිදි ඉහළින් වැළකී සිටීම සඳහා වන සාධාරණීකරණයන්:

ඔබේ සමාගම සඳහා ක්ෂණික කාලය / පිරිවැය ඉතිරි කිරීම
ඔබ ගිය පසු පවා දිගු කාලීනව දෝශ නිරාකරණ / නඩත්තු කිරීමේ / දීර් extension කිරීමේ විභව කාලය / පිරිවැය ඉතිරි කිරීම.

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

— ආදිත්‍ය පී
source

1

අවසානයේ හොඳ ප්‍රශ්නයක්. මම මගේ වැඩ ගැන ආඩම්බර වෙමි, නියත වශයෙන්ම මගේ අයදුම්පත් ඉතා හොඳින් ක්‍රියාත්මක වේ (මා එතරම් නිර්භීත නම්). නමුත් ඔබ හරි - සමහර පරීක්ෂණවල සහාය ඇතිව ඒවා ඊටත් වඩා හොඳ විය හැකිය. මම හිතන්නේ මම මෙතැනින් ඉවත් වීම යනු ව්‍යාපෘතියේ වැඩ කිරීමට ඇති කාලය තුළ සහ කේත ආවරණය පිළිබඳ ඕනෑවට වඩා නොසිතා හැකි තරම් ප්‍රයෝජනවත් පරීක්ෂණවලට ගැලපීමට උත්සාහ කිරීමයි.

— කෙන් පෙස්පීසා

1

බොහෝ පිළිතුරු ටීඩීඩී ගැති බව පෙනේ, ප්‍රශ්නය ඇසුවේ ටීඩීඩී ගැන නොව සාමාන්‍යයෙන් ඒකක පරීක්ෂණ ගැන ය.

ඒකක පරීක්ෂාව හෝ ඒකක පරීක්ෂණය නොකළ යුතු දේ පිටුපස සම්පූර්ණයෙන්ම වෛෂයික රීතියක් නොමැත. නමුත් බොහෝ ක්‍රමලේඛකයින් ඒකක පරීක්ෂාවට ලක් නොකරන බව පෙනෙන අවස්ථා කිහිපයක් තිබේ:

පෞද්ගලික ක්‍රම

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

ඔබ දැනටමත් දන්නා දේවල් ක්‍රියාත්මක විය යුතුය (හෝ වෙනත් අයෙකු විසින් පරීක්ෂා කරන ලද දේවල්)

නව ක්‍රමලේඛකයින් බොහෝ දෙනෙක් පළමු වරට පරීක්‍ෂා කිරීමට ඉගෙන ගන්නා විට මෙයට විරුද්ධ වන අතර, ක්‍රියාත්මක වන සෑම පේළියක්ම පරීක්‍ෂා කළ යුතු යැයි සිතති. ඔබ බාහිර පුස්තකාලයක් භාවිතා කරන්නේ නම් සහ එහි ක්‍රියාකාරිත්වය එහි කතුවරුන් විසින් හොඳින් පරීක්‍ෂා කර ලේඛනගත කර තිබේ නම්, සාමාන්‍යයෙන් ඒකක පරීක්ෂණවල නිශ්චිත ක්‍රියාකාරිත්වය පරීක්ෂා කිරීම අර්ථ විරහිත ය. නිදසුනක් ලෙස, රේල් පීලි වල එම හැසිරීම දැනටමත් හොඳින් පරීක්‍ෂා කර තිබුණද, ඔවුන්ගේ ඇක්ටිව් රෙකෝඩ් ආකෘතිය දත්ත ගබඩාවට “පෙර_ සුරකින්න” ඇමතුමක් සහිත ගුණාංගයක් සඳහා නිවැරදි අගය දිගටම පවතින බව තහවුරු කර ගැනීම සඳහා යමෙකු පරීක්ෂණයක් ලිවිය හැකිය. ඇමතුම් ලබා ගැනීමේ ක්‍රමය (ය), සමහර විට, නමුත් ඇමතුම් ආපසු ගැනීමේ හැසිරීමම නොවේ. ආනයනය කරන ලද පුස්තකාල සමඟ ඇති ඕනෑම ගැටළුවක් ඒකක පරීක්ෂණවලට වඩා පිළිගැනීමේ පරීක්ෂණ මගින් අනාවරණය වනු ඇත.

ඔබ TDD කරනවාද නැද්ද යන්න මේ දෙකම අදාළ විය හැකිය.

— රවෙන්ස්ටයින්
source

0

කෙන්, මම සහ තවත් බොහෝ සංවර්ධකයින් අපගේ වෘත්තීන් පුරා ඔබ කිහිප වතාවක්ම එකම නිගමනයකට පැමිණ ඇත.

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

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

public interface ITest {
    public string Name {
        get;
    }
    public string Description {
        get;
    }
    public List<ITest> SubTests {
        get;
    }
    public TestResult Execute();
}

public class TestResult {
    public bool Succesful {
        get;
        set;
    }

    public string ResultMessage {
        get;
        set;
    }

    private Dictionary<ITest, TestResult> subTestResults = new Dictionary<ITest, TestResult>();
    public Dictionary<ITest, TestResult> SubTestResults {
        get {
            return subTestResults;
        }
        set {
            subTestResults = value;
        }
    }
}

ඉන් පසු ඇති එකම උපක්‍රමය වන්නේ ඔබ කරන ඕනෑම ව්‍යාපෘතියක් සඳහා හොඳම “ගාංචුව සඳහා වළල්ල” යැයි ඔබ සිතන කැටිති මට්ටම කුමක්දැයි සොයා බැලීමයි.

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

වාසනාව!

— ඇඩම් කාර්ස්ටන්සන්
source

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

— කෙන් පෙස්පීසා

SubSpec (එය BDD දේවානුභාවයෙන්) වැනි රාමුවක් භාවිතා කිරීමෙන් ඔබට ප්‍රයෝජන ලැබිය හැකි යැයි මම සිතමි, එමඟින් සන්දර්භය සැකසීමේදී හුවමාරු කර ගැනීමේදී ("SubTest") හුදකලාව ලබා ගැනීමට ඔබට ඉඩ සලසයි.

— ජොහැන්නස් රුඩොල්ෆ්