ടെസ്റ്റ് പ്രൊഡക്ഷൻ, ക്വാളിറ്റി അഷ്വറൻസ്

നേട്ടങ്ങൾ:

• AI ഉപയോഗിച്ച് യൂണിറ്റ് ടെസ്റ്റിംഗ്, എഡ്ജ് കേസുകൾ, കവറേജ് ഗ്യാപ്പ് വിശകലനം എന്നിവ നിർമ്മിക്കാനുള്ള കഴിവ്
• കോഡിൻ്റെ നിലവിലെ സ്വഭാവമല്ല, സ്പെസിഫിക്കേഷനെ അടിസ്ഥാനമാക്കി ടെസ്റ്റ് പ്രതീക്ഷകൾ പ്രിൻ്റ് ചെയ്യാനുള്ള കഴിവ്
• പിശകുകൾ കുത്തിവയ്ക്കുന്നതിലൂടെ ഒരു പരിശോധന യഥാർത്ഥത്തിൽ സംരക്ഷിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കാനുള്ള കഴിവ്

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

ഈ യൂണിറ്റിൽ, നിങ്ങൾ യൂണിറ്റ് ടെസ്റ്റിംഗ് (ഒരു ഫംഗ്‌ഷൻ ഒറ്റയ്‌ക്ക്, ഐസൊലേഷനിൽ പരിശോധിക്കുന്ന ടെസ്റ്റിംഗ്), എഡ്ജ് കേസ് ടെസ്റ്റുകൾ, AI ഉപയോഗിച്ച് ടെസ്റ്റ് ഡാറ്റ സൃഷ്‌ടിക്കൽ എന്നിവ പഠിക്കും; ടെസ്റ്റ് കവറേജിലെ വിടവുകൾ അടയ്ക്കൽ; AI ടെസ്റ്റുകളെ അന്ധമായി വിശ്വസിക്കുന്നത് എന്തുകൊണ്ട് അപകടകരമാണ്.

പരിശോധനയുടെ രണ്ട് വശങ്ങൾ: ഫിക്സിംഗ് ബിഹേവിയർ വേഴ്സസ്

ഒരു ടെസ്റ്റിന് രണ്ട് വ്യത്യസ്ത ആവശ്യങ്ങൾക്ക് കഴിയും. ആദ്യത്തേത് സ്ഥിരീകരണമാണ്: ഇത് കോഡ് ശരിയാണോ, അത് സ്പെസിഫിക്കേഷനുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്ന് പരിശോധിക്കുന്നു. രണ്ടാമത്തേത് റിഗ്രഷൻ പരിരക്ഷയാണ്: ഇത് ഇന്നത്തെ കോഡിൻ്റെ സ്വഭാവത്തെ മരവിപ്പിക്കുന്നു, അതിനാൽ ആരെങ്കിലും അബദ്ധവശാൽ നാളെ അത് മാറ്റുകയാണെങ്കിൽ, പരിശോധന തകർക്കുകയും അറിയിക്കുകയും ചെയ്യും.

AI രണ്ടാമത്തേതിൽ വളരെ മികച്ചതാണ്; ഇത് കോഡ് നോക്കുകയും "ഇത് ഇപ്പോൾ എന്താണ് ചെയ്യുന്നത്" എന്ന് പരിശോധിക്കുന്ന കേസുകൾ സൃഷ്ടിക്കുകയും ചെയ്യുന്നു. എന്നാൽ തുടക്കം മുതൽ കോഡ് തെറ്റാണെങ്കിൽ, AI ആ തെറ്റായ പെരുമാറ്റം "ശരിയാണ്" എന്ന് പിൻ ചെയ്യാൻ കഴിയും. അതിനാൽ AI ഉത്പാദിപ്പിക്കുന്ന ഓരോ ടെസ്റ്റിൻ്റെയും ഉറപ്പ് നിങ്ങൾ അവലോകനം ചെയ്യണം: "കോഡ് 42 നൽകുന്നു, ടെസ്റ്റ് 42 പ്രതീക്ഷിക്കുന്നു" എന്നതിനർത്ഥം 42 ശരിയായ ഉത്തരമാണെന്ന് അർത്ഥമാക്കുന്നില്ല.

മുന്നറിയിപ്പ്: AI ടെസ്റ്റ് വിജയിക്കുകയാണെങ്കിൽ, കോഡ് "പ്രവർത്തിക്കുന്നു" എന്ന് അർത്ഥമാക്കുന്നില്ല; അതിൻ്റെ അർത്ഥം "അത് AI പ്രതീക്ഷിക്കുന്നത് പോലെ പ്രവർത്തിക്കുന്നു" എന്നാണ്. സ്‌പെസിഫിക്കേഷൻ നോക്കിയാണ് പ്രതീക്ഷ ശരിയാണോ അല്ലയോ എന്ന് നിങ്ങൾ തീരുമാനിക്കുക.

ഘട്ടം ഘട്ടമായി: AI ഉപയോഗിച്ച് ശക്തമായ ടെസ്റ്റുകൾ എഴുതുക

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

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

കേസ് 1 - കവറേജ് 52% മുതൽ 85% വരെ. ഒരു സേവന മൊഡ്യൂളിൻ്റെ ടെസ്റ്റ് കവറേജ് 52% ആയിരുന്നു. ടീം നിലവിലുള്ള ടെസ്റ്റുകൾ AI-ക്ക് നൽകി, അത് പരിശോധിക്കാത്ത ശാഖകൾ ലിസ്റ്റ് ചെയ്യുകയും അവയ്‌ക്കായി ടെസ്റ്റുകൾ സൃഷ്ടിക്കുകയും ചെയ്തു. മനുഷ്യ അവലോകനത്തോടെ, കവറേജ് 85% ആയി വർദ്ധിച്ചു; ഈ പ്രക്രിയയിൽ, മുമ്പ് പരീക്ഷിച്ചിട്ടില്ലാത്ത ഒരു ബഗ് ബ്രാഞ്ചിൽ ഒരു യഥാർത്ഥ ബഗ് (തെറ്റായ പിശക് കോഡ് തിരികെ നൽകിയ ഒരു പാത) AI കണ്ടെത്തി.

കേസ് 2 - തെറ്റായ പ്രതീക്ഷ ഫിക്സേഷൻ ട്രാപ്പ്. പണം റൗണ്ടിംഗ് ഫംഗ്‌ഷൻ യഥാർത്ഥത്തിൽ തെറ്റായിരുന്നു; 2.675 മുതൽ 2.67 വരെ റൗണ്ട് ചെയ്യുന്നതിനുപകരം, 2.68 ന് പകരം 2.67 റൗണ്ട് ചെയ്യുകയായിരുന്നു. AI കോഡ് നോക്കി, assert round_money(2.675) == 2.67 എന്ന് എഴുതി - പിശക് "ശരി" എന്ന് മരവിപ്പിച്ചു. ഡെവലപ്പർ സ്പെസിഫിക്കേഷൻ വായിച്ചപ്പോൾ, അവൻ പ്രതീക്ഷ തിരുത്തി, യഥാർത്ഥ ബഗ് പിടിക്കപ്പെട്ടു. കോഡല്ല, ചട്ടം പരീക്ഷിക്കുന്നത് വ്യത്യാസം വരുത്തി.

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

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

സ്പെസിഫിക്കേഷൻ അടിസ്ഥാനമാക്കിയുള്ള ടെസ്റ്റ് ജനറേഷൻ:

റോൾ: ടെസ്റ്റുകൾ എഴുതുന്ന ഒരു ഡെവലപ്പർ. ചട്ടക്കൂട്: {{pytest/JUnit/Jest...}}. ഫംഗ്‌ഷൻ എന്തുചെയ്യണം (സ്‌പെസിഫിക്കേഷൻ): {{rule}}ഇനിപ്പറയുന്ന ഫംഗ്‌ഷനായി ടെസ്റ്റുകൾ എഴുതുക. സ്പെസിഫിക്കേഷൻ അനുസരിച്ച് പ്രതീക്ഷകൾ എഴുതുക, കോഡിൻ്റെ നിലവിലെ ഔട്ട്പുട്ട് അല്ല. ഹാപ്പി പാത്ത് + കുറഞ്ഞത് 4 എഡ്ജ് കേസുകളെങ്കിലും ചേർക്കുക. ഓരോ ടെസ്റ്റും ഒരു കാര്യം പരീക്ഷിക്കട്ടെ, വിവരണാത്മക നാമം ഉപയോഗിക്കുക. {{പ്രവർത്തനം}}

എഡ്ജ് കേസ് ബ്രെയിൻസ്റ്റോമിംഗ്:

ഈ ഫംഗ്‌ഷൻ്റെ പരിശോധനയിൽ പരീക്ഷിക്കേണ്ട എഡ്ജ്/പരാജയ കേസുകൾ ലിസ്റ്റ് ചെയ്യുക (നൾ, നൾ, ബ്രേക്ക്‌പോയിൻ്റുകൾ, മോശം ഫോർമാറ്റ്, കൺകറൻസി, ബാഹ്യ പിശക്). ഓരോ കേസിനും: ഇൻപുട്ട്, പ്രതീക്ഷിക്കുന്ന പെരുമാറ്റം. ഇതുവരെ കോഡ് എഴുതരുത്, ലിസ്റ്റ് ചെയ്യുക.{{function}}

കവറേജ് വിടവ് വിശകലനം:

പ്രവർത്തനങ്ങളും ലഭ്യമായ ടെസ്റ്റുകളും ചുവടെയുണ്ട്. ഏതൊക്കെ ശാഖകളും വ്യവസ്ഥകളും കേസുകളും പരീക്ഷിച്ചിട്ടില്ല? പോരായ്മകൾ പട്ടികപ്പെടുത്തുകയും ന്യൂനതകൾക്കായി മാത്രം പുതിയ പരീക്ഷകൾ എഴുതുകയും ചെയ്യുക. നിലവിലുള്ളവ ആവർത്തിക്കരുത്. പ്രവർത്തനം:{{function}}ടെസ്റ്റുകൾ:{{existing_tests}}

ടെസ്റ്റ് ഡാറ്റ / മോക്ക് ഒബ്ജക്റ്റ് ജനറേഷൻ:

{{function/service}} ടെസ്റ്റുകൾക്കായി റിയലിസ്റ്റിക് ടെസ്റ്റ് ഡാറ്റ സൃഷ്ടിക്കുക: സാധുവായ സാമ്പിളുകൾ, ബോർഡർ സാമ്പിളുകൾ, അസാധുവായ സാമ്പിളുകൾ എന്നിവ പ്രത്യേകം. ബാഹ്യ ആശ്രിതത്വത്തിന് {{X}} ഒരു ലളിതമായ മോക്ക് പെരുമാറ്റം നിർദ്ദേശിക്കുക. യഥാർത്ഥ രഹസ്യാത്മക ഡാറ്റ/PII ഉപയോഗിക്കുന്നു; വ്യാജ ഡാറ്റ സൃഷ്ടിക്കുക.

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

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

ശക്തമായത്: "പൈറ്റെസ്റ്റിനൊപ്പം. ഫംഗ്‌ഷൻ apply_ഡിസ്‌കൗണ്ട് (മൊത്തം, ശതമാനം) - റൂൾ: കിഴിവ് 0%–30% ആയിരിക്കണം, പരിധിക്ക് പുറത്ത് ValueError എറിയണം, ഫലം 2 ദശാംശങ്ങളായി റൗണ്ട് ചെയ്യണം. ഈ റൂൾ പ്രകാരം പ്രതീക്ഷകൾ എഴുതുക (കോഡ് വഴിയല്ല). ഹാപ്പി പാത്ത് + ഈ എഡ്ജ് കേസുകൾ: 0%, മൊത്തം, 31% [കോഡ്]"

അവൻ ശക്തമായ റിലീസ് റൂൾ നൽകുകയും "കോഡല്ല, ചട്ടം അനുസരിച്ച് പ്രതീക്ഷ എഴുതുക" എന്ന് പറയുകയും ചെയ്യുന്നു; ഈ ഒറ്റ വാചകം AI ഫിക്സിംഗ് മോശം പെരുമാറ്റത്തിൻ്റെ കെണി അടയ്ക്കുന്നു.

ടെസ്റ്റ് തരം

AI സംഭാവന

മനുഷ്യ നിയന്ത്രണം

ഹാപ്പി റോഡ് യൂണിറ്റ് ടെസ്റ്റിംഗ്

വേഗത്തിലുള്ള അസ്ഥികൂടം

പ്രതീക്ഷ ശരിയാണോ?

എഡ്ജ് കേസുകൾ

വിപുലമായ മസ്തിഷ്കപ്രക്ഷോഭം

അപ്രസക്തമായത് ഇല്ലാതാക്കുക

സ്കോപ്പ് വിടവ് പൂരിപ്പിക്കൽ

ഒഴിവാക്കിയ ശാഖകൾ കണ്ടെത്തുന്നു

പ്രാധാന്യം സ്ഥിരീകരിക്കുക

ടെസ്റ്റ് ഡാറ്റ/മോക്ക്

റിയലിസ്റ്റിക് സാമ്പിൾ നിർമ്മിക്കുന്നു

PII ഇല്ല, റിയലിസം നിയന്ത്രണം

പരിശോധനകൾ ഗുണനിലവാരം നിയന്ത്രിക്കുന്നു, അത് ഉറപ്പ് നൽകുന്നില്ല

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

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

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

• റൂൾ നൽകാതെ പരീക്ഷ ആവശ്യപ്പെടുന്നു. മോഡൽ നിലവിലെ പെരുമാറ്റം മരവിപ്പിക്കുന്നു; പിശക് "ശരി" എന്ന് പരിഹരിക്കുന്നു.
• പ്രതീക്ഷകൾ വായിക്കാതെ സ്വീകരിക്കുക. സ്ഥിരീകരണങ്ങൾ ശരിയായ മൂല്യത്തിനാണോ പരിശോധിക്കുന്നതെന്ന് നിങ്ങൾ പരിശോധിച്ചില്ലെങ്കിൽ, പരിശോധന തെറ്റിദ്ധരിപ്പിക്കുന്നതാണ്.
• സന്തോഷകരമായ പാത പരീക്ഷിക്കുക മാത്രമാണ്. യഥാർത്ഥ പിശകുകൾ അരികുകളിൽ ജീവിക്കുന്നു; എഡ്ജ് കേസുകൾ വ്യക്തമായി ചോദിക്കുക.
• ലക്ഷ്യത്തിൻ്റെ വ്യാപ്തി തെറ്റിദ്ധരിക്കുന്നു. ഉയർന്ന ശതമാനം ശരിയായ പെരുമാറ്റത്തിന് യാതൊരു ഉറപ്പുമില്ല.
• യഥാർത്ഥ/മറഞ്ഞിരിക്കുന്ന ഡാറ്റ ടെസ്റ്റ് ഡാറ്റയായി നിർമ്മിക്കുന്നു. ഉപഭോക്തൃ വിവരങ്ങളോ രഹസ്യങ്ങളോ പരിശോധനയിലും സംഭരണത്തിലും പ്രവേശിക്കരുത്; സിന്തറ്റിക് ഡാറ്റ സൃഷ്ടിക്കുക.

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

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

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

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

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

• [ ] പെരുമാറ്റം ശരിയാക്കാനോ സ്ഥിരീകരിക്കാനോ ഉള്ള പരിശോധനയാണോ എന്ന് ഞാൻ വേർതിരിച്ചറിയുന്നു.
• [ ] ഞാൻ ഒരു ടെസ്റ്റ് അഭ്യർത്ഥിക്കുമ്പോൾ, കോഡല്ല, നിലവിലുള്ള നിയമമാണ് (സ്പെസിഫിക്കേഷൻ) ഞാൻ നൽകുന്നത്.
• [ ] ഞാൻ സൃഷ്ടിച്ച ഓരോ അവകാശവാദവും സ്പെസിഫിക്കേഷനുമായി താരതമ്യം ചെയ്യുന്നു.
• [ ] എഡ്ജ്, പരാജയ കേസുകൾ ഞാൻ വ്യക്തമായി അഭ്യർത്ഥിക്കുന്നു.
• [ ] ഞാൻ ശതമാനം കവറേജ് ഒരു ടൂൾ ആയി കാണുന്നു, ഒരു ലക്ഷ്യമല്ല.
• [ ] പിശകുകൾ കുത്തിവച്ചുകൊണ്ട് ഒരു പരിശോധന യഥാർത്ഥത്തിൽ സംരക്ഷിക്കുന്നുണ്ടോ എന്ന് ഞാൻ പരിശോധിക്കുന്നു.