യൂണിറ്റ് ടെസ്റ്റ് ജനറേഷനും ടെസ്റ്റബിലിറ്റിയും: AI ഉപയോഗിച്ചുള്ള ശക്തമായ പരിശോധന

നേട്ടങ്ങൾ:

• സ്വീകാര്യത നിയമത്തിൽ നിന്ന് സ്വതന്ത്രമായി യൂണിറ്റ് ടെസ്റ്റുകളിൽ പ്രതീക്ഷിക്കുന്ന മൂല്യം കണക്കാക്കി തെറ്റായ പെരുമാറ്റം 'ശരി'യായി അംഗീകരിക്കുന്നതിൽ നിന്ന് കൃത്രിമ ബുദ്ധിയെ തടയാനുള്ള കഴിവ്
• AAA, FIRST തത്ത്വങ്ങൾ പ്രയോഗിച്ചും ബാഹ്യ ഡിപൻഡൻസികളെ പരിഹസിച്ചും വേഗതയേറിയതും സ്വതന്ത്രവും ആവർത്തിക്കാവുന്നതുമായ ടെസ്റ്റുകൾ അച്ചടിക്കാനുള്ള കഴിവ്
• മ്യൂട്ടേഷൻ (കോഡ് ബ്രേക്കിംഗ്) ഉപയോഗിച്ച് ടെസ്റ്റുകൾ പരിശോധിക്കാനുള്ള കഴിവ്, കൂടാതെ ടെസ്റ്റ് ചെയ്യാൻ ബുദ്ധിമുട്ടുള്ള കോഡ് ഡിസൈൻ മണമായി തിരിച്ചറിയുക

ടെസ്റ്റിംഗ് പിരമിഡിൻ്റെ ഏറ്റവും വലുതും വേഗതയേറിയതുമായ പാളി യൂണിറ്റ് ടെസ്റ്റിംഗ് ആണ് - മറ്റെല്ലാ കാര്യങ്ങളിൽ നിന്നും ഒറ്റപ്പെട്ട ഒരു ഫംഗ്ഷൻ അല്ലെങ്കിൽ ചെറിയ കോഡ് പരിശോധിക്കുന്ന ടെസ്റ്റിംഗ്. ഡെവലപ്പറുടെ സ്‌ക്രീനിൽ കോഡ് ഉള്ളപ്പോൾ തന്നെ ആയിരക്കണക്കിന് യൂണിറ്റ് ടെസ്റ്റുകൾ സെക്കൻ്റുകൾക്കുള്ളിൽ പ്രവർത്തിക്കുകയും ബഗ് പിടിക്കുകയും ചെയ്യുന്നു. ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസ് (AI) ഒരുപക്ഷേ യൂണിറ്റ് ടെസ്റ്റുകൾ നിർമ്മിക്കുന്നതിൽ ഏറ്റവും പ്രഗത്ഭനാണ്: നിങ്ങൾ അതിന് ഒരു ഫംഗ്ഷൻ നൽകുന്നു, AI ഡസൻ കണക്കിന് ടെസ്റ്റുകൾ നിർമ്മിക്കുന്നു. എന്നാൽ ഈ സൗകര്യം തന്നെ ഏറ്റവും വലിയ കെണിയിലേക്ക് നയിക്കുന്നു: AI എളുപ്പത്തിൽ "പച്ചനിറത്തിൽ തിളങ്ങുന്ന എന്നാൽ ഒന്നും പരിശോധിക്കരുത്" അല്ലെങ്കിൽ കോഡിൻ്റെ നിലവിലെ (ഒരുപക്ഷേ തെറ്റായ) പെരുമാറ്റം "ശരി" എന്ന് അംഗീകരിക്കുന്ന ടെസ്റ്റുകൾ നിർമ്മിക്കുന്നു. ഈ യൂണിറ്റിൽ നിങ്ങൾ AI ഉപയോഗിച്ച് യഥാർത്ഥ സംരക്ഷണ യൂണിറ്റ് ടെസ്റ്റുകൾ എങ്ങനെ എഴുതാമെന്നും പരിശോധിക്കാവുന്ന കോഡും AI-യും തമ്മിലുള്ള ബന്ധവും പഠിക്കും.

ഒരു നല്ല യൂണിറ്റ് ടെസ്റ്റിൻ്റെ ഗുണങ്ങൾ: FIRST

നല്ല യൂണിറ്റ് ടെസ്റ്റുകൾ ആദ്യ തത്ത്വങ്ങൾ പാലിക്കുന്നു: വേഗതയേറിയതും സ്വതന്ത്രവുമായ (പരസ്‌പരം ആശ്രയിക്കരുത്), ആവർത്തിച്ചുള്ള (ആവർത്തിക്കാവുന്ന - ഏത് പരിതസ്ഥിതിയിലും ഒരേ ഫലം), സ്വയം-സാധുവാക്കൽ (വ്യക്തമായ പാസ്/പരാജയം), സമയബന്ധിതമായി (യഥാസമയം). AI പ്രൊഡക്ഷൻ ടെസ്റ്റുകൾ നടത്തുമ്പോൾ ഈ തത്ത്വങ്ങൾ സ്വയം ഓർമ്മിപ്പിക്കുക; ടെസ്റ്റ് പുറം ലോകത്തെ (യഥാർത്ഥ ഡാറ്റാബേസ്, നെറ്റ്‌വർക്ക്, ക്ലോക്ക്) ആശ്രയിക്കരുതെന്ന് പ്രത്യേകം ആവശ്യപ്പെടുക.

AAA പാറ്റേണും പ്രകടിപ്പിക്കുന്ന ഉറപ്പും

ഒരു സോളിഡ് യൂണിറ്റ് ടെസ്റ്റ് AAA ഘടനയെ പിന്തുടരുന്നു: ക്രമീകരിക്കുക (തയ്യാറാക്കുക - ഇൻപുട്ടുകളും ഡിപൻഡൻസികളും സജ്ജീകരിക്കുക), നിയമം (എക്‌സിക്യൂട്ട് ചെയ്യുക - ടെസ്റ്റിന് കീഴിലുള്ള ഫംഗ്‌ഷനെ വിളിക്കുക), ഉറപ്പിക്കുക (സാധുവാക്കുക - ഫലം പ്രതീക്ഷിച്ച മൂല്യവുമായി താരതമ്യം ചെയ്യുക). നിർണായകമായത് ഉറപ്പാണ്. AI ചെയ്യുന്ന ഏറ്റവും സാധാരണമായ തെറ്റ്, പരീക്ഷണത്തിൻ കീഴിലുള്ള കോഡിൻ്റെ ഔട്ട്പുട്ടിൽ നിന്ന് അവകാശവാദം ഉന്നയിക്കുന്നതാണ് - "കോഡ് നൽകുന്നതെന്തും ശരിയാണ്" എന്ന യുക്തി. ഇത് പരീക്ഷയെ അർത്ഥശൂന്യമാക്കുന്നു. പ്രതീക്ഷിക്കുന്ന മൂല്യം സ്വതന്ത്രമായി നിർണ്ണയിക്കുക എന്നതാണ് ശരിയായ മാർഗം (സ്വീകാര്യത മാനദണ്ഡത്തിൽ നിന്ന്, അത് സ്വമേധയാ കണക്കാക്കുക).

ശ്രദ്ധിക്കുക: നിങ്ങൾ AI-യോട് "ഈ ഫംഗ്‌ഷനായി ഒരു ടെസ്റ്റ് എഴുതുക" എന്ന് പറഞ്ഞാൽ, AI ഫംഗ്‌ഷൻ പ്രവർത്തിപ്പിക്കുകയും അതിൻ്റെ ഔട്ട്‌പുട്ട് "പ്രതീക്ഷിച്ചത്" എന്ന് എഴുതുകയും ചെയ്തേക്കാം. ഫംഗ്‌ഷൻ തെറ്റാണെങ്കിൽപ്പോലും ഈ പരിശോധന കടന്നുപോകുന്നു. പകരം, "ഈ നിയമങ്ങൾക്കനുസൃതമായി നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന ഫലങ്ങൾ കണക്കാക്കുന്നു, ഫംഗ്ഷൻ്റെ നിലവിലെ ഔട്ട്പുട്ട് പരാമർശിക്കരുത്" എന്ന് പറയുക.

പരിഹാസങ്ങളും അപൂർണ്ണങ്ങളും ആശ്രിതത്വങ്ങളും

യൂണിറ്റ് പരിശോധനയ്ക്ക് ഐസൊലേഷൻ ആവശ്യമാണ്. നിങ്ങളുടെ ഫംഗ്‌ഷൻ ഒരു ഡാറ്റാബേസിനെയോ API-യെയോ ആശ്രയിച്ചിരിക്കുന്നുവെങ്കിൽ, അവ ടെസ്റ്റിംഗിൽ മോക്ക് ഒബ്‌ജക്‌റ്റുകൾ (മോക്ക്/സ്റ്റബ് - നിയന്ത്രിത, യഥാർത്ഥ ഡിപൻഡൻസിക്ക് പകരമുള്ള ഡമ്മി) ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കും. ഇത് പരിശോധനയെ വേഗമേറിയതും സ്വതന്ത്രവും പുനരുൽപ്പാദിപ്പിക്കാവുന്നതുമാക്കുന്നു. AI-ക്ക് മോക്ക് ഇൻസ്റ്റാളേഷൻ നിർമ്മിക്കാൻ കഴിയും; എന്നാൽ അമിതമായ പരിഹാസത്തെ സൂക്ഷിക്കുക: നിങ്ങൾ എല്ലാം പരിഹസിക്കുകയാണെങ്കിൽ, "എന്താണ് മോക്ക് റിട്ടേൺസ്" എന്ന് മാത്രമേ പരിശോധന പരിശോധിക്കൂ, യഥാർത്ഥ യുക്തിയല്ല. ബാലൻസ്: പുറം ലോകത്തെ അനുകരിക്കുക, പരീക്ഷണത്തിൻ കീഴിൽ യഥാർത്ഥ യുക്തി നടപ്പിലാക്കുക.

ടെസ്റ്റബിലിറ്റിയും AI

രസകരമായ ഒരു ഫീഡ്‌ബാക്ക് ഉണ്ട്: പരീക്ഷിക്കാൻ പ്രയാസമുള്ള കോഡ് പലപ്പോഴും മോശമായി രൂപകൽപ്പന ചെയ്ത കോഡാണ്. ഒരു ഫംഗ്‌ഷനിലേക്ക് ടെസ്റ്റുകൾ എഴുതുന്നതിൽ AI-ക്ക് പ്രശ്‌നമുണ്ടെങ്കിൽ (വളരെയധികം ഡിപൻഡൻസികൾ, മറഞ്ഞിരിക്കുന്ന ആഗോള നില, പാർശ്വഫലങ്ങൾ), അത് ഒരു ഡിസൈൻ മണമാണ്. AI-യോട് "ഈ കോഡ് പരീക്ഷിക്കാവുന്നതാക്കാൻ നിങ്ങൾ എങ്ങനെ റീഫാക്റ്റർ ചെയ്യും" എന്ന് ചോദിക്കുന്നത് മികച്ച ടെസ്റ്റിംഗിലേക്കും മികച്ച കോഡിലേക്കും നയിക്കുന്നു.

പാരാമീറ്ററൈസ്ഡ് ടെസ്റ്റുകളും ഡാറ്റാ വൈവിധ്യവും

വ്യത്യസ്‌ത ഇൻപുട്ടുകൾ ഉപയോഗിച്ച് ഒരേ നിയമം പരിശോധിക്കാൻ ഓരോ തവണയും ഒരു പ്രത്യേക പരീക്ഷ എഴുതുന്നത് മടുപ്പിക്കുന്നതും പരിപാലിക്കാൻ ബുദ്ധിമുട്ടുള്ളതുമാണ്. പാരാമീറ്ററൈസ്ഡ് ടെസ്റ്റിംഗ് - ഇൻപുട്ടുകളുടെയും പ്രതീക്ഷിച്ച ഫലങ്ങളുടെയും ലിസ്റ്റിൽ ഒരേ ടെസ്റ്റ് ലോജിക്ക് ആവർത്തിച്ച് പ്രവർത്തിപ്പിക്കുന്ന ഒരു ഘടന - ഈ ആവർത്തനത്തെ ഇല്ലാതാക്കുന്നു: ഒരു ടെസ്റ്റ് ബോഡിക്ക് ഡസൻ കണക്കിന് ഇൻപുട്ട് ജോഡികൾ നൽകുന്നു. നിങ്ങളുടെ സ്വീകാര്യത നിയമങ്ങൾ നൽകുമ്പോൾ ഈ ഇൻപുട്ട്-പ്രതീക്ഷിച്ച ഫല പട്ടികകൾ നിർമ്മിക്കുന്നതിൽ AI വളരെ കാര്യക്ഷമമാണ്; പ്രത്യേകിച്ചും, ഇത് വ്യവസ്ഥാപിതമായി പരിധി മൂല്യങ്ങളും തുല്യത ക്ലാസുകളും പട്ടികപ്പെടുത്തുന്നു.

എന്നാൽ ഇവിടെയും ഒരു കെണിയുണ്ട്: പരീക്ഷണത്തിൻ കീഴിലുള്ള കോഡിൽ നിന്ന് ജനറേറ്റ് ചെയ്ത പട്ടികയിൽ പ്രതീക്ഷിക്കുന്ന ഫലങ്ങൾ നേടാൻ AI പ്രവണത കാണിക്കുന്നു. പാരാമീറ്ററൈസ്ഡ് ടെസ്റ്റിംഗിൽ ഈ പിശക് കൂടുതൽ അപകടകരമാണ്, കാരണം ഒരൊറ്റ തെറ്റായ ലോജിക് ഡസൻ കണക്കിന് വരികളെ അസാധുവാക്കുന്നു. അതിനാൽ, എല്ലായ്‌പ്പോഴും പ്രതീക്ഷിക്കുന്ന ഫല കോളം സ്വീകാര്യത നിയമം അനുസരിച്ച് സ്വതന്ത്രമായി കണക്കാക്കുകയും കുറഞ്ഞത് കുറച്ച് വരികളെങ്കിലും സ്വമേധയാ സാധൂകരിക്കുകയും ചെയ്യുക. "ഓരോ വരിയും എന്താണ് പ്രതിനിധീകരിക്കുന്നത്" എന്ന ഒരു വിവരണ കോളവും ആവശ്യപ്പെടുക; അതിനാൽ ഒരു വരി പൊട്ടുമ്പോൾ ഏത് അവസ്ഥയാണ് തകർന്നതെന്ന് നിങ്ങൾ തൽക്ഷണം കാണും.

നുറുങ്ങ്: പാരാമീറ്റർ ചെയ്ത ടെസ്റ്റ് ടേബിളിലേക്ക് മനഃപൂർവ്വം ഒരു "ട്രാപ്പ് റോ" ചേർക്കുക - അതായത്, അറിഞ്ഞുകൊണ്ട് ഫലം തെറ്റായി ടൈപ്പ് ചെയ്യുക. നിങ്ങൾ ടെസ്റ്റ് നടത്തുമ്പോൾ ആ ലൈൻ ചുവപ്പായി മാറുന്നില്ലെങ്കിൽ, നിങ്ങളുടെ ടെസ്റ്റ് യഥാർത്ഥത്തിൽ ആ സാഹചര്യം പരിശോധിക്കുന്നില്ല. ഇതൊരു ദ്രുത മോക്ക്-പാസ് പരിശോധനയാണ്.

ദുർബലമായ പ്രോംപ്റ്റ് / ശക്തമായ പ്രോംപ്റ്റ്

ദുർബലമായത്: "ഈ പ്രവർത്തനത്തിനായി ഒരു യൂണിറ്റ് ടെസ്റ്റ് എഴുതുക."

ശക്തമായത്: "നികുതി കണക്കുകൂട്ടൽ (തുക, നിരക്ക്) ഫംഗ്‌ഷനായി [ഭാഷ/ചട്ടക്കൂട്] യൂണിറ്റ് ടെസ്റ്റുകൾ എഴുതുക. സ്വീകാര്യത നിയമം: ഫലം = തുക * നിരക്ക്, 2 ദശാംശങ്ങളിലേക്ക് റൗണ്ട് ചെയ്‌തിരിക്കുന്നു; നെഗറ്റീവ് തുക അല്ലെങ്കിൽ നിരക്ക് ഒരു പിശക് നൽകുന്നു; നിരക്ക് 0 ആണെങ്കിൽ 0 നൽകുന്നു. AAA ഘടന ഉപയോഗിക്കുക. ഈ റഫറൻസ് നിയമങ്ങൾ അനുസരിച്ച് പ്രതീക്ഷിക്കുന്ന മൂല്യങ്ങൾ സ്വമേധയാ കണക്കാക്കുക. (0, നെഗറ്റീവ്, വളരെ വലുത്, വൃത്താകൃതിയിലുള്ളത് മുതൽ ദശാംശം വരെ).

ശക്തമായ പ്രോംപ്റ്റ്; ഇത് സ്വീകാര്യത നിയമം, സ്വതന്ത്ര പ്രതീക്ഷിക്കുന്ന മൂല്യ പ്രതീക്ഷ, ഘടന, എഡ്ജ് കേസുകൾ എന്നിവ നൽകുന്നു. അങ്ങനെ, ടെസ്റ്റ് നിയമത്തിൻ്റെ രക്ഷാധികാരിയായി മാറുന്നു, കോഡിൻ്റെ കണ്ണാടിയല്ല.

യൂണിറ്റ് ടെസ്റ്റ് ഗുണനിലവാര പട്ടിക

ലക്ഷണം

മോശം പരിശോധന (വ്യാജ-വിശ്വാസം)

നല്ല പരീക്ഷണം

ഉറപ്പിക്കുക

ഒന്നുമില്ല അല്ലെങ്കിൽ "ശൂന്യമല്ല"

പ്രതീക്ഷിക്കുന്ന കോൺക്രീറ്റ് മൂല്യം

പ്രതീക്ഷിക്കുന്ന മൂല്യത്തിൻ്റെ ഉറവിടം

ഫംഗ്ഷൻ്റെ ഔട്ട്പുട്ട്

സ്വീകാര്യത നിയമം / മാനുവൽ കണക്കുകൂട്ടൽ

ആസക്തി

യഥാർത്ഥ DB/നെറ്റ്‌വർക്ക്/മണിക്കൂർ

മോക്ക്/സ്റ്റബ് ഉപയോഗിച്ച് ഇൻസുലേറ്റ് ചെയ്തിരിക്കുന്നു

എഡ്ജ് കേസ്

സന്തോഷകരമായ റോഡ് മാത്രം

പരിധി, നെഗറ്റീവ്, പിശക്

നിങ്ങൾ കോഡ് തകർക്കുമ്പോൾ

പച്ചയായി തുടരുന്നു

ചുവപ്പായി മാറുന്നു

പേര്

test1, testMethod

അത് സ്ഥിരീകരിക്കുന്ന നിയമം വിവരിക്കുന്നു

പകർത്താവുന്ന നാല് ടെംപ്ലേറ്റുകൾ

1) റൂൾ-ഡ്രൈവ് യൂണിറ്റ് ടെസ്റ്റിംഗ്:

നിങ്ങളുടെ റോൾ: സീനിയർ സോഫ്‌റ്റ്‌വെയർ ടെസ്റ്റ് എഞ്ചിനീയർ. ഇനിപ്പറയുന്ന ഫംഗ്‌ഷനിൽ [ഭാഷ/ഫ്രെയിംവർക്ക്] ഉപയോഗിച്ച് ഒരു യൂണിറ്റ് ടെസ്റ്റ് എഴുതുക: [ഒപ്പ്]. സ്വീകാര്യത നിയമങ്ങൾ: [നിയമങ്ങൾ].- AAA ഘടന ഉപയോഗിക്കുക.- ഈ നിയമങ്ങൾ അനുസരിച്ച് പ്രതീക്ഷിക്കുന്ന മൂല്യങ്ങൾ സ്വമേധയാ കണക്കാക്കുക; ഫംഗ്‌ഷൻ്റെ നിലവിലെ ഔട്ട്‌പുട്ട് പരാമർശിക്കരുത്. - പ്രത്യേക പരിശോധനകൾ ഉപയോഗിച്ച് പരിധി, നെഗറ്റീവ്, പിശക്, സന്തോഷകരമായ പാത എന്നിവ മറയ്ക്കുക. - ഓരോ ടെസ്റ്റ് നാമവും അത് പരിശോധിച്ചുറപ്പിക്കുന്ന നിയമം വിവരിക്കട്ടെ. - മോക്ക് ബാഹ്യ ഡിപൻഡൻസികൾ; യഥാർത്ഥ യുക്തി പ്രവർത്തിക്കുക.

2) മ്യൂട്ടേഷൻ പ്രതിരോധ നിയന്ത്രണം:

ഈ യൂണിറ്റ് ടെസ്റ്റുകൾ പരിശോധിക്കുക. ടെസ്റ്റിന് കീഴിലുള്ള കോഡിൽ എനിക്ക് വരുത്താൻ കഴിയുന്ന 5 ചെറിയ മാറ്റങ്ങൾ ലിസ്റ്റുചെയ്യുക (a - പകരം ഒരു +, a >= എന്നതിന് പകരം, ഒരു ബൗണ്ടറി ഷിഫ്റ്റ്) കൂടാതെ ഈ ടെസ്റ്റുകളിൽ ഏതാണ് ചുവപ്പായി മാറുന്നത്? ഒന്നും തിരികെ നൽകിയില്ലെങ്കിൽ, പരിശോധന അപര്യാപ്തമാണ്. കോഡ് + ടെസ്റ്റുകൾ: [ഒട്ടിക്കുക]

3) ടെസ്റ്റബിലിറ്റി അവലോകനം:

ഈ ഫംഗ്‌ഷനായി ഒരു യൂണിറ്റ് ടെസ്റ്റ് എഴുതുന്നത് എന്തുകൊണ്ട് ബുദ്ധിമുട്ടാണ്? മറഞ്ഞിരിക്കുന്ന ആസക്തി, ആഗോള പദവി, പാർശ്വഫലങ്ങൾ, നിരവധി ഉത്തരവാദിത്തങ്ങൾ ഉണ്ടോ? ഇത് പരീക്ഷിക്കാവുന്നതാക്കാൻ ഏറ്റവും കുറഞ്ഞ റീഫാക്‌ടറിംഗ് നിർദ്ദേശിക്കുക; സ്വഭാവം മാറ്റരുത്. കോഡ്: [ഒട്ടിക്കുക]

4) അപൂർണ്ണമായ സാഹചര്യം പൂർത്തീകരണം:

ഇനിപ്പറയുന്ന പ്രവർത്തനവും ലഭ്യമായ ടെസ്റ്റുകളും നൽകിയിരിക്കുന്നു. ഏത് പെരുമാറ്റം/എഡ്ജ്കേസ് ഒരിക്കലും പരീക്ഷിച്ചിട്ടില്ല (സ്കോപ്പ് ഗ്യാപ്പ്) ലിസ്റ്റ് ചെയ്ത് ഓരോന്നിനും ഒരു ടെസ്റ്റ് ചേർക്കുക. ഫംഗ്‌ഷൻ+ടെസ്റ്റുകൾ: [ഒട്ടിക്കുക]

മൂന്ന് മിനി കേസുകൾ

കേസ് 1 - കോഡ് മിററിംഗ് ടെസ്റ്റ്. റൗണ്ടിംഗ് ഫംഗ്‌ഷനുവേണ്ടി ഒരു ഡെവലപ്പർ AI യെ ഒരു ടെസ്റ്റ് എഴുതിച്ചു; 10 ടെസ്റ്റുകൾ പച്ചയായിരുന്നു. വാസ്തവത്തിൽ, ഫംഗ്ഷൻ തെറ്റായ ദിശയിലാണ് റൗണ്ട് ചെയ്യുന്നത്, പക്ഷേ ഫംഗ്ഷൻ്റെ ഔട്ട്പുട്ടിൽ നിന്ന് AI പ്രതീക്ഷിച്ച മൂല്യങ്ങൾ എടുത്തിരുന്നു, അതിനാൽ പരിശോധനകൾ പിശക് "ശരി" ആയി കണക്കാക്കി. "റൂൾ-ഡ്രൈവ്" ടെംപ്ലേറ്റ് ഉപയോഗിച്ച് പ്രതീക്ഷിച്ച മൂല്യങ്ങൾ സ്വമേധയാ കണക്കാക്കിയപ്പോൾ, 4 ടെസ്റ്റുകൾ ചുവപ്പായി മാറുകയും യഥാർത്ഥ പിശക് വെളിപ്പെടുത്തുകയും ചെയ്തു.

കേസ് 2 - മ്യൂട്ടേഷൻ നിയന്ത്രണത്തിൻ്റെ മൂല്യം. ഒരു ടീം 45 യൂണിറ്റ് ടെസ്റ്റുകളെ ആശ്രയിച്ചു. "മ്യൂട്ടേഷൻ റോബസ്റ്റ്‌നെസ് ചെക്ക്" ഉപയോഗിച്ച് കോഡിലേക്ക് 20 ചെറിയ മാറ്റങ്ങൾ പരീക്ഷിച്ചു; പരിശോധനയിൽ 11 പേരെ മാത്രമാണ് പിടികൂടിയത്. ബാക്കിയുള്ള 9 തടസ്സങ്ങൾ നിശബ്ദമായി കടന്നുപോയി. ദുർബലമായ ടെസ്റ്റുകൾ ടീം ശക്തമാക്കി; അടുത്ത റിലീസിൽ ഈ മെച്ചപ്പെടുത്തിയ ടെസ്റ്റുകളിൽ ഒരു യഥാർത്ഥ കണക്കുകൂട്ടൽ പിശക് കണ്ടെത്തി.

കേസ് 3 - അൺടെസ്റ്റബിലിറ്റി ഒരു ഡിസൈൻ മണമാണ്. AI-ക്ക് ഒരു ഓർഡറിംഗ് ഫംഗ്‌ഷനായി ടെസ്റ്റുകൾ എഴുതാൻ കഴിഞ്ഞില്ല, അതിന് യഥാർത്ഥ ഡാറ്റാബേസ് നിരന്തരം ആവശ്യമാണ്. "ടെസ്റ്റബിലിറ്റി റിവ്യൂ" ടെംപ്ലേറ്റ് ഫംഗ്ഷൻ ഉൾച്ചേർത്ത ഡാറ്റാബേസ് ആക്സസ് കാണിച്ചു. ഡിപൻഡൻസി ഇഞ്ചക്ഷൻ നീക്കം ചെയ്തപ്പോൾ, ടെസ്റ്റുകൾ എഴുതാനും കോഡ് ശുദ്ധീകരിക്കാനും കഴിഞ്ഞു.

സാധാരണ തെറ്റുകൾ

• കോഡിൽ നിന്ന് പ്രതീക്ഷിക്കുന്ന മൂല്യം ലഭിക്കുന്നു. AI ഫംഗ്‌ഷൻ ഔട്ട്‌പുട്ട് "ശരി" ആയി സ്വീകരിക്കുന്നു; തെറ്റായ കോഡ് സ്ഥിരീകരിക്കുന്ന പരിശോധന.
• ഉറപ്പില്ലാതെ അല്ലെങ്കിൽ നിസ്സാരമായ ഉറപ്പോടെ പരീക്ഷിക്കുക. "അവൻ ഒരു തെറ്റ് എറിഞ്ഞില്ല, അവൻ പാസായി" യുക്തി; അത് ഒന്നും സ്ഥിരീകരിക്കുന്നില്ല.
• അങ്ങേയറ്റം പരിഹാസം. എല്ലാറ്റിനെയും പരിഹസിക്കുകയും പരിഹാസം തിരികെ നൽകുന്നത് മാത്രം പരീക്ഷിക്കുകയും ചെയ്യുക; യഥാർത്ഥ യുക്തി പരീക്ഷിച്ചിട്ടില്ല.
• സന്തോഷകരമായ വഴി മാത്രം. പരിധി, നെഗറ്റീവ്, പിശക് അവസ്ഥകൾ എന്നിവ മറികടക്കുന്നു.
• കോഡ് തകർത്ത് പരീക്ഷിക്കുന്നില്ല. മ്യൂട്ടേഷൻ പരിശോധിക്കാതെ പച്ചയെ വിശ്വസിക്കുന്നു.
• അസ്ഥിരതയെ അവഗണിക്കുന്നു. കഠിനമായ പരിശോധനയ്ക്ക് പകരം മോശമായ ഡിസൈൻ തിരിച്ചറിയുകയും ശരിയാക്കുകയും ചെയ്യുന്നില്ല.

ചുരുക്കത്തിൽ

ടെസ്റ്റിംഗ് പിരമിഡിൻ്റെ ഏറ്റവും വേഗതയേറിയതും വലുതുമായ പാളിയാണ് യൂണിറ്റ് ടെസ്റ്റുകൾ; അത് ഏറ്റവും വിലകുറഞ്ഞ നിമിഷത്തിൽ തെറ്റ് പിടിക്കുന്നു. യൂണിറ്റ് ടെസ്റ്റുകൾ നിർമ്മിക്കാൻ AI വളരെ പ്രാപ്തമാണ്, എന്നാൽ അതിൻ്റെ ഏറ്റവും വലിയ പോരായ്മ കോഡിൽ നിന്ന് തന്നെ പ്രതീക്ഷിച്ച മൂല്യം ഉരുത്തിരിഞ്ഞുകൊണ്ട് തെറ്റായ പെരുമാറ്റം "ശരി" എന്ന് അനുമാനിക്കുന്ന ടെസ്റ്റുകൾ എഴുതുന്നതാണ്. പരിഹാരം: സ്വീകാര്യത നിയമങ്ങൾ നൽകുക, പ്രതീക്ഷിക്കുന്ന മൂല്യങ്ങൾ സ്വമേധയാ കണക്കാക്കുക, AAA, FIRST തത്ത്വങ്ങൾ നടപ്പിലാക്കുക, പുറം ലോകത്തെ പരിഹസിക്കുക, യഥാർത്ഥ ലോജിക് പ്രവർത്തിപ്പിക്കുക, കൂടാതെ ഓരോ ടെസ്റ്റും മ്യൂട്ടേഷൻ വഴി പരീക്ഷിക്കുക (കോഡ് തകർക്കുക). പരിശോധിക്കാൻ ബുദ്ധിമുട്ടുള്ള കോഡ് ഫിക്സിംഗ് ആവശ്യമുള്ള ഒരു ഡിസൈൻ ചിഹ്നമാണ്.

ആപ്ലിക്കേഷൻ ടാസ്ക്

നിങ്ങളുടെ സ്വന്തം പ്രോജക്റ്റിൽ നിന്ന് ഒരു ബിസിനസ്സ് റൂൾ അടങ്ങുന്ന ഒരു ഫംഗ്ഷൻ തിരഞ്ഞെടുക്കുക. സ്വീകാര്യത നിയമങ്ങൾ എഴുതുക, "റൂൾ-ഡ്രൈവ് യൂണിറ്റ് ടെസ്റ്റിംഗ്" ടെംപ്ലേറ്റ് ഉപയോഗിച്ച് AI ടെസ്റ്റുകൾ എഴുതുക; പ്രതീക്ഷിക്കുന്ന മൂല്യങ്ങൾ സ്വമേധയാ കണക്കാക്കുക. തുടർന്ന് "മ്യൂട്ടേഷൻ റോബസ്റ്റ്‌നെസ് ചെക്ക്" പ്രയോഗിക്കുക: കോഡിൽ കുറഞ്ഞത് 5 ചെറിയ ഇടവേളകളെങ്കിലും വരുത്തി എത്ര ടെസ്റ്റുകൾ ചുവപ്പായി മാറുന്നുവെന്ന് അളക്കുക. പിടിക്കപ്പെടാത്ത അഴിമതികൾക്കായി പുതിയ പരിശോധന ചേർക്കുക. എത്ര തടസ്സങ്ങൾ പിടികൂടി (മ്യൂട്ടേഷൻ സ്കോർ പോലുള്ളവ) റിപ്പോർട്ട് ചെയ്യുക.

ചെക്ക്ലിസ്റ്റ്

• [ ] ഞാൻ സ്വീകാര്യത നിയമങ്ങൾ നൽകുകയും പ്രതീക്ഷിച്ച മൂല്യങ്ങൾ സ്വമേധയാ കണക്കാക്കുകയും ചെയ്തു.
• [ ] ടെസ്റ്റുകൾ കോഡിൽ നിന്ന് പ്രതീക്ഷിച്ച മൂല്യം നേടിയിട്ടില്ലെന്ന് ഞാൻ ഉറപ്പുവരുത്തി.
• [ ] AAA, FIRST മാർഗ്ഗനിർദ്ദേശങ്ങൾ പിന്തുടർന്ന് ഞാൻ സ്വതന്ത്ര പരിശോധന സ്ഥാപിച്ചു.
• [ ] ഞാൻ ബാഹ്യ ആശ്രിതത്വങ്ങളെ പരിഹസിക്കുകയും യഥാർത്ഥ യുക്തി പ്രവർത്തിപ്പിക്കുകയും ചെയ്തു.
• [ ] ഞാൻ പരിധി, നെഗറ്റീവ്, പിശക് കേസുകൾ കവർ ചെയ്തു.
• [ ] കോഡ് (മ്യൂട്ടേഷൻ) തകർത്തുകൊണ്ട്, ടെസ്റ്റുകൾ തീർച്ചയായും സംരക്ഷിക്കുമെന്ന് ഞാൻ തെളിയിച്ചു.