19 ਦਸੰ 2025·3 ਮਿੰਟ
Claude Code ਲਈ ਸੀਮਾ-ਕੇਸ ਟੈਸਟ ਬਣਾਉਣ ਵਾਲਾ ਪ੍ਰੰਪਟ
Claude Code ਲਈ ਇੱਕ ਟੈਸਟ ਜਨਰੇਸ਼ਨ ਪ੍ਰੰਪਟ ਸਿੱਖੋ ਜੋ ਹੈਪੀ-ਪਾਥਾਂ ਦੀ ਥਾਂ ਸੀਮਾਵਾਂ, ਇਨਵੈਰੀਐਂਟ ਅਤੇ ਫੇਲਿਊਰ ਮੋਡ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾ ਕੇ ਉੱਚ-ਸਿਗਨਲ ਟੈਸਟ ਤਿਆਰ ਕਰਦਾ ਹੈ।
Claude Code ਲਈ ਇੱਕ ਟੈਸਟ ਜਨਰੇਸ਼ਨ ਪ੍ਰੰਪਟ ਸਿੱਖੋ ਜੋ ਹੈਪੀ-ਪਾਥਾਂ ਦੀ ਥਾਂ ਸੀਮਾਵਾਂ, ਇਨਵੈਰੀਐਂਟ ਅਤੇ ਫੇਲਿਊਰ ਮੋਡ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾ ਕੇ ਉੱਚ-ਸਿਗਨਲ ਟੈਸਟ ਤਿਆਰ ਕਰਦਾ ਹੈ।
ਆਟੋ-ਜਨਰੇਟ ਕੀਤੀਆਂ ਟੈਸਟ ਸੂਟਾਂ ਅਕਸਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ: ਦਹਾਂ ਟੈਸਟ, ਬਹੁਤ ਸਾਰਾ ਸੈਟਅਪ ਕੋਡ, ਅਤੇ ਹਰ ਫੰਕਸ਼ਨ ਨਾਂ ਉਦੋਂ ਕਿਸੇ ਨਾ ਕਿਸੇ ਟੈਸਟ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ। ਪਰ ਬਹੁਤ ਸਾਰੇ ਉਹ ਟੈਸਟ ਸਿਰਫ਼ "ਜਦੋਂ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ ਤਾਂ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ" ਵਾਲੇ ਚੈੱਕ ਹੁੰਦੇ ਹਨ। ਉਹ ਆਸਾਨੀ ਨਾਲ ਪਾਸ ਹੋ ਜਾਂਦੇ ਹਨ, ਕਮ ਹੀ ਬੱਗ ਫੜਦੇ ਹਨ, ਅਤੇ ਪੜ੍ਹਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਕਰਨ ਵਿੱਚ ਵੀ ਸਮਾਂ ਲਾਿੰਦੇ ਹਨ।
ਇੱਕ ਆਮ Claude Code ਟੈਸਟ ਜਨਰੇਸ਼ਨ ਪ੍ਰੰਪਟ ਨਾਲ, ਮਾਡਲ ਅਕਸਰ ਉਹੀ ਇਨਪੁੱਟ ਉਮੀਦਾਂ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਮਿਲਦੀਆਂ ਹਨ। ਤੁਹਾਨੂੰ ਵੱਖ-ਵੱਖ ਦਿੱਖ ਵਾਲੀਆਂ ਵੀਰੀਐਂਟ ਸ ਮਿਲਦੀਆਂ ਹਨ ਪਰ ਉਹੀ ਵਿਵਹਾਰ ਕਵਰ ਹੁੰਦਾ ਹੈ। ਨਤੀਜਾ ਇਕ ਵੱਡੀ ਸੂਟ ਹੁੰਦੀ ਹੈ ਜਿਸ ਦੀ ਝਿੱਲੀ ਕਵਰੇਜ ਅਹਮ ਥਾਵਾਂ `ਤੇ ਕਮਜ਼ੋਰ ਹੁੰਦੀ ਹੈ।
ਉੱਚ-ਸਿਗਨਲ ਟੈਸਟ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਉਹ ਛੋਟਾ ਸੈੱਟ ਹੁੰਦੇ ਹਨ ਜੋ ਪਿਛਲੇ ਮਹੀਨੇ ਦੀ ਘਟਨਾ ਨੂੰ ਫੜ ਸਕਦੇ ਸਨ। ਜੇ ਵਿਵਹਾਰ ਖਤਰਨਾਕ ਢੰਗ ਨਾਲ ਬਦਲਿਆ ਤਾਂ ਉਹFail ਹੁੰਦੇ ਹਨ, ਅਤੇ ਨਿਰਪੱਖ ਰੀਫੈਕਟਰਾਂ 'ਤੇ ਠੋਸ ਰਹਿੰਦੇ ਹਨ। ਇਕ ਉੱਚ-ਸਿਗਨਲ ਟੈਸਟ ਵੀ ਵੀਹ "ਉਮੀਦਤ ਮੁੱਲ ਵਾਪਸ ਕਰਦਾ ਹੈ" ਵਾਲੇ ਚੈੱਕਾਂ ਦੇ ਬਰਾਬਰ ਹੋ ਸਕਦਾ ਹੈ।
ਘੱਟ-ਮੁੱਲ ਵਾਲੀ ਹੈਪੀ-ਪਾਥ ਜਨਰੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਸਪਸ਼ਟ ਲੱਛਣ ਰੱਖਦੀ ਹੈ:
ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਫੰਕਸ਼ਨ ਜੋ ਇੱਕ ਡਿਸਕਾਊਂਟ ਕੋਡ ਲਗਾਉਂਦਾ ਹੈ। ਹੈਪੀ-ਪਾਥ ਟੈਸਟ ਪਕਿਰਤੀਗਤ ਤੌਰ 'ਤੇ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ ਕਿ "SAVE10" ਕੀਮਤ ਘਟਾਉਂਦਾ ਹੈ। ਅਸਲ ਬੱਗ ਹੋਰ ਜਗ੍ਹਾ 'ਚ ਛੁਪੇ ਹੁੰਦੇ ਹਨ: 0 ਜਾਂ ਨੈਗੇਟਿਵ ਕੀਮਤਾਂ, ਮਿਆਦਗਜ਼ਰ ਕੋਡ, ਰਾਉਂਡਿੰਗ ਦੀਆਂ ਕਿਨਾਰਿਆਂ, ਜਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਡਿਸਕਾਊਂਟ ਕੈਪ। ਇਹ ਉਹ ਮਾਮਲੇ ਹਨ ਜੋ ਗਲਤ ਟੋਟਲ, ਗੁੱਸੇ ਵਾਲੇ ਗ੍ਰਾਹਕ, ਅਤੇ ਅਧੀਰ ਰੋਲਬੈਕਾਂ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ।
ਮਕਸਦ ਹੈ "ਜ਼ਿਆਦਾ ਟੈਸਟ" ਤੋਂ "ਵਧੀਆ ਟੈਸਟ" ਵੱਲ ਵੱਧਣਾ — ਤਿੰਨ ਨਿਸ਼ਾਨਿਆਂ ਨੂੰ ਟਾਰਗੇਟ ਕਰਕੇ: ਸੀਮਾਵਾਂ, ਫੇਲਿਊਰ ਮੋਡ ਅਤੇ ਇਨਵੈਰੀਐਂਟ।
ਜੇ ਤੁਸੀਂ ਉੱਚ-ਸਿਗਨਲ ਯੂਨਿਟ ਟੈਸਟ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ "ਹੋਰ ਟੈਸਟ" ਮੰਗਣਾ ਬੰਦ ਕਰੋ ਅਤੇ ਤਿੰਨ ਖਾਸ ਕਿਸਮਾਂ ਲਈ ਮੰਗ ਕਰੋ। ਇਹ Claude Code ਟੈਸਟ ਜਨਰੇਸ਼ਨ ਪ੍ਰੰਪਟ ਦਾ ਕੇਂਦਰ ਹੈ ਜੋ ਇੱਕ ਢੇਰ "ਸਧਾਰਨ ਇਨਪੁੱਟ" ਟੈਸਟਾਂ ਦੀ ਥਾਂ ਉਪਯੋਗੀ ਕਵਰੇਜ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਸੀਮਾਵਾਂ ਉਹ ਧਾਰੇ ਹਨ ਜੋ ਕੋਡ ਸਵੀਕਾਰ ਜਾਂ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਅਸਲੀ ਖਾਮੀਆਂ ਆਫ-ਬਾਈ-ਵਨ, ਖਾਲੀ-ਅਵਸਥਾ, ਜਾਂ ਟਾਈਮਆਊਟ ਸਮੱਸਿਆਵਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਹੈਪੀ-ਪਾਥ 'ਤੇ ਕਦੇ ਨਹੀਂ ਨਜ਼ਰ ਆਉਂਦੀਆਂ।
ਘੱਟੋ-ਘੱਟ ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ (0, 1, max ਲੰਬਾਈ), ਖਾਲੀ ਬਨਾਮ ਮੌਜੂਦ ("", [], nil), ਆਫ-ਬਾਇ-ਵਨ (n-1, n, n+1), ਅਤੇ ਟਾਈਮ ਲਿਮਿਟ (ਕੱਟਆਫ ਦੇ ਨੇੜੇ) ਨੂੰ ਸੋਚੋ।
ਉਦਾਹਰਣ: ਜੇ ਇੱਕ API "100 ਆਈਟਮ ਤੱਕ" ਸਵੀਕਾਰਦਾ ਹੈ, ਤਾਂ 100 ਅਤੇ 101 ਦੀ ਟੈਸਟ ਕਰੋ, ਸਿਰਫ਼ 3 ਨਹੀਂ।
ਫੇਲਿਊਰ ਮੋਡ ਉਹ ਤਰੀਕੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਸਿਸਟਮ ਟੁੱਟ ਸਕਦਾ ਹੈ: ਖਰਾਬ ਇਨਪੁੱਟ, ਗੁੰਮDependencies, ਅਧੂਰੇ ਨਤੀਜੇ, ਜਾਂ ਅੱਪਸਟਰੀਮ ਏਰਰ। ਚੰਗੇ ਫੇਲਿਊਰ ਮੋਡ ਟੈਸਟ ਦਬਾਣ 'ਤੇ ਵਿਵਹਾਰ ਜਾਂਚਦੇ ਹਨ, ਸਿਰਫ਼ ਆਈਡੀਆਲ ਹਾਲਤ ਵਿੱਚ ਆਉਟਪੁੱਟ ਨਹੀਂ।
ਉਦਾਹਰਣ: ਜਦੋਂ ਇੱਕ ਡੇਟਾਬੇਸ ਕਾਲ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਕੀ ਫੰਕਸ਼ਨ ਇੱਕ ਸਪਸ਼ਟ ਏਰਰ ਵਾਪਸ ਕਰਦਾ ਹੈ ਅਤੇ ਅਧੂਰਾ ਡਾਟਾ ਲਿਖਣ ਤੋਂ ਬਚਦਾ ਹੈ?
ਇਨਵੈਰੀਐਂਟ ਉਹ ਸੱਚਾਈਆਂ ਹਨ ਜੋ ਇੱਕ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਸਦਾ ਸੱਚ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਉਹ ਅਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਸਪਸ਼ਟ ਐਸਰਸ਼ਨ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।
ਉਦਾਹਰਣ:
ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਤਿੰਨ ਨਿਸ਼ਾਨੇ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਘੱਟ ਟੈਸਟ ਮਿਲਦੇ ਹਨ ਪਰ ਹਰ ਇੱਕ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸਿਗਨਲ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਜਲਦੀ ਟੈਸਟ ਮੰਗਦੇ ਹੋ, ਤਾਂ ਅਕਸਰ ਤੁਹਾਨੂੰ ਇੱਕ ਢੇਰ "ਠੀਕ ਚੱਲ ਰਿਹਾ ਹੈ" ਚੈੱਕ ਮਿਲਦਾ ਹੈ। ਇੱਕ ਸਾਦਾ ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ contract ਲਿਖੋ, ਫਿਰ ਉਸ contract ਤੋਂ ਟੈਸਟ ਜਨਰੇਟ ਕਰੋ। ਇਹ Claude Code ਟੈਸਟ ਜਨਰੇਸ਼ਨ ਪ੍ਰੰਪਟ ਨੂੰ ਅਸਲੀ ਬੱਗ ਪਕੜਨ ਵਾਲਾ ਬਣਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ।
ਇੱਕ ਲਾਭਕਾਰੀ contract ਇੰਨਾ ਛੋਟਾ ਹੋਵੇ ਕਿ ਇੱਕ ਸਾਹ ਵਿੱਚ ਪੜ੍ਹਿਆ ਜਾ ਸਕੇ। 5 ਤੋਂ 10 ਲਾਈਨਾਂ ਦਾ ਟੀਚਾ ਕਰੋ ਜੋ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ: ਕੀ ਜਾਏਗਾ, ਕੀ ਆਏਗਾ, ਅਤੇ ਹੋਰ ਕੀ ਬਦਲੇਗਾ।
ਆਪਣੇ contract ਨੂੰ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ, ਕੋਡ ਨਹੀਂ, ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਤੁਸੀਂ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ।
ਇਕ ਵਾਰੀ ਇਹ ਹੋ ਜਾਵੇ, ਤਾਂ ਇਸਨੂੰ ਸਕੈਨ ਕਰੋ ਕਿ ਕਿੱਥੇ ਹਕੀਕਤ ਤੁਹਾਡੇ ਅਨੁਮਾਨ ਨੂੰ ਟੋੜ ਸਕਦੀ ਹੈ। ਉਹ ਸੀਮਾ-ਕੇਸ (ਮਿਨ/ਮੈਕਸ, ਜ਼ੀਰੋ, ਓਵਰਫਲੋ, ਖਾਲੀ ਸਟਰਿੰਗ, ਡੁਪਲਿਕੇਟ) ਅਤੇ ਫੇਲਿਊਰ ਮੋਡ (ਟਾਈਮਆਊਟ, परमീഷਨ ਡਿਨਾਈ, ਯੂਨੀਕ ਕੰਸਟਰੈਂਟ ਵਾਇਓਲੇਸ਼ਨ, ਕਰਪਟਡ ਇਨਪੁੱਟ) ਬਣ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਵਿਸ਼ੇਸ਼ ਉਦਾਹਰਣ ਲਈ ਫੀਚਰ reserveInventory(itemId, qty) ਵਰਗਾ ਸੋਚੋ:
Contract ਕਹਿ ਸਕਦਾ ਹੈ ਕਿ qty ਇੱਕ ਸਕਾਰਾਤਮਕ ਪੂਰਨ ਅੰਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਫੰਕਸ਼ਨ ਐਟੋਮਿਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਦੇ ਨੈਗੇਟਿਵ ਸਟਾਕ ਨਹੀਂ ਬਣਾਉਣਾ ਚਾਹੀਦਾ। ਇਸ ਨਾਲ ਤੁਰੰਤ ਉੱਚ-ਸਿਗਨਲ ਟੈਸਟ ਸੁਝਾਉਂਦੇ ਹਨ: qty = 0, qty = 1, qty ਉਪਲਬਧ ਤੋਂ ਵੱਧ, ਸਮਕਾਲੀ ਕਾਲਾਂ, ਅਤੇ ਅੱਧੇ ਰਾਸਤੇ ਵਿੱਚ ਡੇਟਾਬੇਸ ਏਰਰ ਨੂੰ ਬਲਦੇ ਕਰਨਾ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਚੈਟ-ਪ੍ਰੋਡਕਟ ਦਾ ਉਪਯੋਗ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਹੀ ਵਰਕਫਲੋ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਪਹਿਲਾਂ ਚੈਟ ਵਿੱਚ contract ਲਿਖੋ, ਫਿਰ ਸੀਮਾਵਾਂ, ਫੇਲਿਊਰ ਮੋਡ ਅਤੇ "ਕਦੇ-ਨਹੀਂ" ਸੂਚੀ 'ਤੇ ਡਾਇਰੈਕਟ ਟੈਸਟ ਜਨਰੇਟ ਕਰੋ।
ਜਦੋਂ ਤੁਸੀਂ ਘੱਟ ਪਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਟੈਸਟ ਚਾਹੁੰਦੇ ਹੋ, ਇਹ Claude Code ਟੈਸਟ ਜਨਰੇਸ਼ਨ ਪ੍ਰੰਪਟ ਵਰਤੋ। ਮੁੱਖ ਚਾਲ ਇਹ ਹੈ ਕਿ ਪਹਿਲਾਂ ਇੱਕ ਟੈਸਟ ਯੋਜਨਾ ਮੰਗੋ, ਫਿਰ ਤੁਹਾਡੇ ਮਨਜ਼ੂਰ ਹੋਣ 'ਤੇ ਟੈਸਟ ਕੋਡ ਜਨਰੇਟ ਕਰੋ।
You are helping me write HIGH-SIGNAL unit tests.
Context
- Language/framework: <fill in>
- Function/module under test: <name + short description>
- Inputs: <types, ranges, constraints>
- Outputs: <types + meaning>
- Side effects/external calls: <db, network, clock, randomness>
Contract (keep it small)
1) Preconditions: <what must be true>
2) Postconditions: <what must be true after>
3) Error behavior: <how failures are surfaced>
Task
PHASE 1 (plan only, no code):
A) Propose 6-10 tests max. Do not include “happy path” unless it protects an invariant.
B) For each test, state: intent, setup, input, expected result, and WHY it is high-signal.
C) Invariants: list 3-5 invariants and how each will be asserted.
D) Boundary matrix: propose a small matrix of boundary values (min/max/empty/null/off-by-one/too-long/invalid enum).
E) Failure modes: list negative tests that prove safe behavior (no crash, no partial write, clear error).
Stop after PHASE 1 and ask for approval.
PHASE 2 (after approval):
Generate the actual test code with clear names and minimal mocks.
ਇੱਕ ਪ੍ਰਯੋਗਕਾਰੀ ਚਾਲ ਇਹ ਹੈ ਕਿ boundary matrix ਨੂੰ ਇਕ ਸੰਕੁਚਿਤ ਟੇਬਲ ਵਾਂਗ ਮੰਗੋ, ਤਾਂ ਜੋ ਖਾਲੀਆਂ ਥਾਂ ਤੇਜ਼ੀ ਨਾਲ ਝਲਕਦੀਆਂ ਹਨ:
| Dimension | Valid edge | Just outside | “Weird” value | Expected behavior |
|---|---|---|---|---|
| length | 0 | -1 | 10,000 | error vs clamp vs accept |
ਜੇ Claude 20 ਟੈਸਟ ਪ੍ਰਸਤਾਵਿਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਵਾਪਸ ਡਟੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਣ ਲਈ ਕਹੋ ਅਤੇ ਸਿਰਫ਼ ਉਹ ਰੱਖੋ ਜੋ ਅਸਲ ਬੱਗ ਫੜਨਗੇ (ਆਫ-ਬਾਈ-ਵਨ, ਗਲਤ ਏਰਰ ਟਾਈਪ, ਖੁਫੀਆ ਡੇਟਾ ਲੋਸ, ਟੁੱਟਿਆ ਇਨਵੈਰੀਐਂਟ)।
ਛੋਟੇ, ਨਿਰਧਾਰਤ contract ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਵਿਵਹਾਰ ਕਰੇ। ਫੰਕਸ਼ਨ ਸਿਗਨੇਚਰ ਪੇਸਟ ਕਰੋ, ਇਨਪੁੱਟ ਅਤੇ ਆਊਟਪੁੱਟ ਦਾ ਛੋਟਾ ਵੇਰਵਾ, ਅਤੇ ਮੌਜੂਦਾ ਟੈਸਟ (ਚਾਹੇ ਉਹ ਸਿਰਫ਼ ਹੈਪੀ-ਪਾਥ ਹੀ ਹੋਣ)। ਇਹ ਮਾਡਲ ਨੂੰ ਅਸਲ ਕੋਡ ਵਿਚ ਜੁਟੇ ਰਹਿਣ ਲਈ ਐਂਕਰ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਇਸ ਦੇ ਅਨੁਮਾਨਾਂ 'ਤੇ।
ਅੱਗੇ, ਕਿਸੇ ਵੀ ਟੈਸਟ ਕੋਡ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਰਿਸਕ ਟੇਬਲ ਮੰਗੋ। ਤਿੰਨ ਕਾਲਮ ਲਾਜ਼ਮੀ ਕਰੋ: ਬਾਊਂਡਰੀ ਕੇਸ (ਮਨਜ਼ੂਰ ਇਨਪੁੱਟ ਦੇ ਕਿਨਾਰੇ), ਫੇਲਿਊਰ ਮੋਡ (ਖਰਾਬ ਇਨਪੁੱਟ, ਗੁੰਮ ਡੇਟਾ, ਟਾਈਮਆਊਟ), ਅਤੇ ਇਨਵੈਰੀਐਂਟ (ਜੋ ਹਮੇਸ਼ਾ ਸਹੀ ਰਹਿਣੇ)। ਹਰ ਰੋ ਨੂੰ ਇੱਕ ਵਾਕ ਦਿਓ: "ਇਹ ਕਿਉਂ ਟੁੱਟ ਸਕਦਾ ਹੈ"। ਇੱਕ ਸਾਦਾ ਟੇਬਲ ਇੱਕ ਢੇਰ ਟੈਸਟ ਫਾਈਲਾਂ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਖ਼ਾਮੀਆਂ ਖੋਲ੍ਹਦਾ ਹੈ।
ਫਿਰ ਸਭ ਤੋਂ ਛੋਟਾ ਸੈੱਟ ਚੁਣੋ ਜਿੱਥੇ ਹਰ ਟੈਸਟ ਦਾ ਇੱਕ ਵਿਲੱਖਣ ਬੱਗ-ਫੜਨ ਦਾ ਉਦੇਸ਼ ਹੋਵੇ। ਜੇ ਦੋ ਟੈਸਟ ਇਕੋ ਕਾਰਨ ਨਾਲ ਫੇਲ ਹੋਂਦੇ ਹਨ, ਤਾਂ ਤੀਬਰ ਵਾਲਾ ਇੱਕ ਰੱਖੋ।
ਇੱਕ ਪ੍ਰਯੋਗਕਾਰੀ ਚੋਣ ਨਿਯਮ:
ਅੰਤ ਵਿੱਚ, ਹਰ ਟੈਸਟ ਲਈ ਇੱਕ ਛੋਟਾ ਵਾਕ ਲੋ: ਜੇ ਇਹ ਫੇਲ ਹੋਇਆ ਤਾਂ ਇਹ ਕਿਹੜਾ ਬੱਗ ਫੜੇਗਾ। ਜੇ ਵਾਕ ਕੁਝ ਢਿੱਲਾ ਹੈ ("ਵਿਵਹਾਰ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ"), ਤਾਂ ਟੈਸਟ ਸ਼ਾਇਦ ਘੱਟ-ਮੁੱਲ ਹੈ।
ਇਕ ਇਨਵੈਰੀਐਂਟ ਇੱਕ ਨਿਯਮ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਮਨਜ਼ੂਰ ਇਨਪੁੱਟ 'ਤੇ ਸੱਚ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਨਵੈਰੀਐਂਟ-ਅਧਾਰਿਤ ਟੈਸਟਿੰਗ ਵਿੱਚ, ਪਹਿਲਾਂ ਨਿਯਮ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ, ਫਿਰ ਇਸਨੂੰ ਇੱਕ ਐਸਰਸ਼ਨ ਵਿੱਚ ਬਦਲੋ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ।
1 ਜਾਂ 2 ਇਨਵੈਰੀਐਂਟ ਚੁਣੋ ਜੋ ਅਸਲ ਬੱਗ ਤੋਂ ਤੁਹਾਨੂੰ ਬਚਾਉਂਦੇ ਹਨ। ਚੰਗੀਆਂ ਇਨਵੈਰੀਐਂਟ ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਆ (ਕੋਈ ਡੇਟਾ-ਲੋਸ ਨਹੀਂ), ਅਸਥਿਰਤਾ (ਉਹੇ ਇਨਪੁੱਟ = ਉਹੇ ਆਊਟਪੁੱਟ), ਜਾਂ ਸੀਮਾਵਾਂ (ਕਦੇ ਕੈਪ ਤੋਂ ਵੱਧ ਨਹੀਂ) ਬਾਰੇ ਹੁੰਦੀਆਂ ਹਨ।
ਇਨਵੈਰੀਐਂਟ ਨੂੰ ਇੱਕ ਛੋਟੇ ਸੈਂਟੇਂਸ ਵਾਂਗ ਲਿਖੋ, ਫਿਰ ਸੋਚੋ ਕਿ ਤੁਹਾਡਾ ਟੈਸਟ ਕਿਹੜਾ ਸਬੂਤ ਦੇ ਸਕਦਾ ਹੈ: ਰਿਟਰਨ ਵੈਲਯੂ, ਸਟੋਰਡ ਡੇਟਾ, ਜਾਰੀ ਕੀਤੇ ਇਵੇਂਟ, ਜਾਂ ਡੀਪੈਂਡੈਂਸੀ ਕਾਲ। ਮਜ਼ਬੂਤ ਐਸਰਸ਼ਨ ਦੋਹਾਂ ਨਤੀਜੇ ਅਤੇ ਸਾਈਡ-ਇਫੈਕਟ ਚੈੱਕ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਬੱਗ "OK ਵਾਪਸ ਕੀਤਾ ਪਰ ਗਲਤ ਲਿਖਿਆ" ਵਿੱਚ ਛੁਪਦੇ ਹਨ।
ਉਦਾਹਰਣ: ਇੱਕ ਫੰਕਸ਼ਨ ਜੋ ਆਰਡਰ 'ਤੇ ਕੁਪਨ ਲਗਾਉਂਦਾ ਹੈ:
ਹੁਣ ਇਨ੍ਹਾਂ ਨੂੰ ਐਸਰਸ਼ਨਾਂ ਵਾਂਗ ਐਨਕੋਡ ਕਰੋ ਜੋ ਕੁਝ ਮਾਪ ਸਕਦੇ ਹਨ:
expect(result.total).toBeGreaterThanOrEqual(0)
expect(db.getOrder(orderId).discountCents).toBe(originalDiscountCents)
ਢਿੱਲੀ ਐਸਰਸ਼ਨਾਂ ਤੋਂ ਬਚੋ ਜਿਵੇਂ "ਉਮੀਦਤ ਨਤੀਜਾ ਵਾਪਸ ਹੋਇਆ"। ਓਸ ਦੀ ਥਾਂ ਖਾਸ ਨਿਯਮ (ਨੈਗੇਟਿਵ ਨਹੀਂ) ਅਤੇ ਖਾਸ ਸਾਈਡ-ਇਫੈਕਟ (ਔਫਸੈਟ ਇੱਕ ਵਾਰੀ ਹੀ ਮੋੜਿਆ ਗਿਆ) ਨੂੰ ਦੱਸੋ।
ਹਰ ਇਨਵੈਰੀਐਂਟ ਲਈ ਟੈਸਟ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਨੋਟ ਜੋੜੋ ਕਿ ਕਿਹੜੇ ਡੇਟਾ ਇਸਨੂੰ ਟੈੱਟੇਗਾ। ਇਹ ਟੈਸਟ ਨੂੰ ਹੈਪੀ-ਪਾਥ ਵਾਲੀ ਚੈੱਕ ਬਣਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਸਧਾਰਣ ਨਮੂਨਾ ਜੋ ਸਮੇਂ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ:
ਉੱਚ-ਸਿਗਨਲ ਟੈਸਟ ਅਕਸਰ ਉਹ ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਕੋਡ ਦੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਫੇਲ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ। ਜੇ ਮਾਡਲ ਸਿਰਫ਼ ਹੈਪੀ-ਪਾਥ ਟੈਸਟ ਲਿਖਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਲਗਭਗ ਕੁਝ ਵੀ ਨਹੀਂ ਸਿੱਖਦੇ ਕਿ ਫੀਚਰ ਗੰਦੇ ਇਨਪੁੱਟ ਜਾਂ ਡੀਪੈਂਡੈਂਸੀ ਬਦਲਣ 'ਤੇ ਕਿ ਹੇਠਾਂ ਕਰੇਗਾ।
ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਇਸ ਫੀਚਰ ਲਈ "ਸੁਰੱਖਿਅਤ" ਦਾ ਕੀ ਅਰਥ ਹੈ। ਕੀ ਇਹ ਇੱਕ ਟਾਈਪਡ ਏਰਰ ਵਾਪਸ ਕਰਦਾ ਹੈ? ਕੀ ਇਹ ਡਿਫੌਲਟ 'ਤੇ ਪਿੱਛੇ ਹਟਦਾ ਹੈ? ਕੀ ਇਹ ਇੱਕ ਵਾਰੀ ਰੀਟ੍ਰਾਈ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਰੁਕ ਜਾਂਦਾ ਹੈ? ਉਸ ਵਿਵਹਾਰ ਨੂੰ ਇਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ, ਫਿਰ ਟੈਸਟ ਬਣਾਉ ਕਿ ਇਹ ਪੱਕਾ ਕਰੇ।
ਜਦੋਂ ਤੁਸੀਂ Claude Code ਨੂੰ ਫੇਲਿਊਰ ਮੋਡ ਟੈਸਟ ਮੰਗਦੇ ਹੋ, ਤਾਂ ਹਦ ਸਖਤ ਰੱਖੋ: ਸਿਸਟਮ ਦੇ ਟੁੱਟਣ ਦੇ ਤਰੀਕਿਆਂ ਨੂੰ ਕਵਰ ਕਰੋ ਅਤੇ ਉਹ ਸਪਸ਼ਟ ਪ੍ਰਤੀਕਰੀਆਂ ਐਸਰਟ ਕਰੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ। ਇੱਕ ਵਰਤੋਂਯੋਗ ਲਾਈਨ: "ਘੱਟ ਪਰ ਮਜ਼ਬੂਤ ਐਸਰਸ਼ਨਾਂ ਵਾਲੇ ਟੈਸਟ ਪਸੰਦ ਕਰੋ, ਬਹੁਤ ਸਾਰੀਆਂ ਢੀਲੀਆਂ ਟੈਸਟਾਂ ਦੀ ਥਾਂ।"
ਉੱਤਮ ਫੇਲਿਊਰ ਸ਼੍ਰੇਣੀਆਂ:
ਉਦਾਹਰਣ: ਇੱਕ ਐਂਡਪਾਇੰਟ ਜੋ ਯੂਜ਼ਰ ਬਣਾਉਂਦਾ ਅਤੇ ਵੈਲਕਮ ਈਮੇਲ ਭੇਜਦਾ। ਇੱਕ ਨੀਚੀ-ਮੁੱਲ ਟੈਸਟ ਸਿਰਫ਼ "201 ਵਾਪਸ ਕਰੋ" ਨੰੂ ਚੈੱਕ ਕਰੇਗਾ। ਇੱਕ ਉੱਚ-ਸਿਗਨਲ ਫੇਲਿਊਰ ਟੈਸਟ ਚੈੱਕ ਕਰੇਗਾ ਕਿ ਜੇ ਈਮੇਲ ਸੇਵਾ ਟਾਈਮਆਊਟ ਹੋ ਜਾਵੇ, ਤਾਂ ਤੁਸੀਂ ਜਾਂ (a) ਯੂਜ਼ਰ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ email_pending ਫਲੈਗ ਨਾਲ 201 ਵਾਪਸ ਕਰਦੇ ਹੋ, ਜਾਂ (b) 503 ਵਾਪਸ ਕਰਦੇ ਹੋ ਅਤੇ ਯੂਜ਼ਰ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਇਕ ਵਿਵਹਾਰ ਚੁਣੋ, ਫਿਰ ਰਿਸਪਾਂਸ ਅਤੇ ਸਾਈਡ-ਇਫੈਕਟ ਦੋਹਾਂ ਐਸਰਟ ਕਰੋ।
ਇਸਦੇ ਨਾਲ-ਨਾਲ ਇਹ ਵੀ ਟੈਸਟ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ-ਕੀ ਲੀਕ ਨਹੀਂ ਕਰਦੇ: ਜੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਫੇਲ ਹੋਵੇ ਤਾਂ ਬੇਨਤੀ ਸਟੋਰੇਜ ਵਿੱਚ ਕੁਝ ਨਾ ਲਿਖੋ। ਜੇ Dependencies ਕਰਪਟਡ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਅਣ-ਹੈਂਡਲਡ ਐਕਸਪਸ਼ਨ ਜਾਂ ਰਾਂ ਟਰੇਸ ਨਾਂ ਵਾਪਸ ਕਰੋ।
ਘੱਟ-ਮੁੱਲ ਟੈਸਟ ਸੈੱਟ ਅਕਸਰ ਉਸ ਸਮੇਂ ਬਣਦੇ ਹਨ ਜਦ ਮਾਡਲ ਨੂੰ ਮਾਤਰਤਾ ਲਈ ਇਨਾਮ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ Claude Code ਪ੍ਰੰਪਟ "20 ਯੂਨਿਟ ਟੈਸਟ" ਮੰਗਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅਕਸਰ ਛੋਟੀ-ਛੋਟੀ ਵੈਰੀਐਂਟ ਭਰਦਾ ਦੱਸਦੇ ਹਨ ਜੋ ਕੁਝ ਨਵਾਂ ਨਹੀਂ ਫੜਦੇ।
ਆਮ ਫੰਸੇ:
ਉਦਾਹਰਣ: "ਯੂਜ਼ਰ ਬਣਾਓ" ਫੰਕਸ਼ਨ ਸੋਚੋ। ਦੱਸ ਹੈਪੀ-ਪਾਥ ਟੈਸਟ ਇਮੇਲ ਸਟਰਿੰਗ ਨੂੰ ਭਿੰਨ-ਭਿੰਨ ਕਰ ਸਕਦੇ ਹਨ ਪਰ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ਾਂ ਛੱਡ ਦੇਂਦੇ ਹਨ: ਨਕਲ-ਈਮੇਲ ਰੱਦ ਕਰਨਾ, ਖਾਲੀ ਪਾਸਵਰਡ ਸੰਭਾਲਣਾ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ ਵਾਪਸ ਕੀਤੇ ਯੂਜ਼ਰ IDs ਵਿਲੱਖਣ ਅਤੇ ਸਥਿਰ ਹਨ।
ਸਮੀਖਿਆ ਲਈ ਗਾਰਡਰੇਲ:
ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਫੀਚਰ: ਚੈਕਆਊਟ 'ਤੇ ਇੱਕ ਕੁਪਨ ਕੋਡ ਲਗਾਉਣਾ।
ਛੋਟਾ ਅਤੇ ਟੈਸਟਯੋਗ contract: ਸੈਂਟ ਵਿੱਚ ਇੱਕ ਕਾਰਟ ਸਬਟੋਟਲ ਅਤੇ ਇੱਕ ਵਿਕਲਪਿਕ ਕੁਪਨ ਦੇ ਕੇ ਇੱਕ ਅੰਤਿਮ ਟੋਟਲ ਸੈਂਟ ਵਿੱਚ ਵਾਪਸ ਕਰੋ। ਨਿਯਮ: ਪ੍ਰਤੀਸ਼ਤ ਕੁਪਨ ਨਜ਼ਦੀਕੀ ਸੈਂਟ ਤੱਕ ਘਟਾਕੇ ਰਾਉਂਡ ਡਾਊਨ ਹੁੰਦੇ ਹਨ, ਫਿਕਸ ਕੁਪਨ ਇੱਕ ਨਿਰਧਾਰਤ ਰਕਮ ਘਟਾਉਂਦੇ ਹਨ, ਅਤੇ ਟੋਟਲ ਕਦੇ ਨੈਗੇਟਿਵ ਨਹੀਂ ਹੁੰਦਾ। ਇਕ ਕੁਪਨ ਅਨਵੈਧ, ਮਿਆਦ-ਖ਼ਤਮ, ਜਾਂ ਪਹਿਲਾਂ ਵਰਤਿਆ ਹੋ ਸਕਦਾ ਹੈ।
"applyCoupon()" ਲਈ ਸਿਰਫ਼ ਟੈਸਟ ਨਾ ਮੰਗੋ। ਸੀਮਾ ਕੇਸ ਟੈਸਟਿੰਗ, ਫੇਲਿਊਰ ਮੋਡ ਟੈਸਟ, ਅਤੇ ਇਸ contract ਨਾਲ ਜੁੜੇ ਇਨਵੈਰੀਐਂਟ ਮੰਗੋ।
ਉਹ ਇਨਪੁੱਟ ਚੁਣੋ ਜੋ ਗਣਿਤ ਜਾਂ ਵੈਧਤਾ ਨੂੰ ਤੋੜਦੇ ਹਨ: ਇੱਕ ਖਾਲੀ ਕੁਪਨ ਸਟਰਿੰਗ, subtotal = 0, ਨਿਯੁਕਤ ਖਰੀਦ ਦੀ ਹੱਦ ਤੋਂ ਥੋੜ੍ਹਾ ਥੱਲੇ ਅਤੇ ਉੱਪਰ, ਇੱਕ ਫਿਕਸਡ ਡਿਸਕਾਊਂਟ ਜੋ subtotal ਤੋਂ ਵੱਧ ਹੈ, ਅਤੇ 33% ਵਰਗਾ ਪ੍ਰਤੀਸ਼ਤ ਜੋ ਰਾਉਂਡਿੰਗ ਬਣਾਉਂਦਾ ਹੈ।
ਮਾਨੋ ਕਿ ਕੁਪਨ ਲੁੱਕਅਪ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਸਟੇਟ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ: ਕੁਪਨ ਸਰਵਿਸ ਡਾਉਨ ਹੈ, ਕੁਪਨ ਮਿਆਦ-ਖ਼ਤਮ ਹੈ, ਜਾਂ ਇਹ ਯੂਜ਼ਰ ਦੁਆਰਾ ਪਹਿਲਾਂ ਹੀ ਰੀਡੀਮ ਕੀਤਾ ਗਿਆ ਹੈ। ਟੈਸਟ ਇਹ ਸਾਬਤ ਕਰੇ ਕਿ ਅਗਲੇ ਕਦਮ ਕੀ ਹਨ (ਕੁਪਨ ਰੱਦ, ਟੋਟਲ ਬਦਲਦਾ ਨਹੀਂ)।
ਇੱਕ ਘੱਟ ਪਰ ਉੱਚ-ਸਿਗਨਲ ਟੈਸਟ ਸੈੱਟ (5 ਟੈਸਟ) ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਕਿਆ ਫੜਦਾ ਹੈ:
ਜੇ ਇਹ ਪਾਸ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਆਮ ਤੋੜ-ਮਰੋੜ ਬਿਨਾਂ ਆਮ ਤੋਰ 'ਤੇ ਕਵਰੇਜ ਲੈ ਲਏ ਹੋ।
ਮਾਡਲ ਦੁਆਰਾ ਜਨਰੇਟ ਕੀਤੇ ਪ੍ਰੋਡਕਟ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਗੁਣਵੱਤਾ ਪਾਸ ਕਰੋ। ਲਕੜੀ ਟੀਚਾ ਉਹ ਟੈਸਟ ਹਨ ਜੋ ਹਰ ਇੱਕ ਤੁਹਾਨੂੰ ਕਿਸੇ ਖਾਸ, ਸੰਭਵ ਬਗ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ।
ਇਸ ਚੈੱਕਲਿਸਟ ਨੂੰ ਇੱਕ ਗੇਟ ਵਜੋਂ ਵਰਤੋਂ:
ਇੱਕ ਛੋਟਾ ਕਰਨਯੋਗ ਚਾਲ: ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਟੈਸਟਾਂ ਦੇ ਨਾਮਾਂ ਨੂੰ "should <ਵਿਵਹਾਰ> when <ਏਜ ਕੰਡਿਸ਼ਨ>" ਅਤੇ "should not <ਖਰਾਬ ਨਤੀਜਾ> when <ਫੇਲਿਊਰ>" ਵਾਂਗ ਰੀ-ਨੇਮ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਨੂੰ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਨਾਂ-ਬਦਲ ਸਕਦੇ ਤਾਂ ਉਹ ਧਿਆਨ ਕੇਂਦਰਿਤ ਨਹੀਂ ਹਨ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ऐप ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਚੈੱਕਲਿਸਟ snapshot ਅਤੇ rollback ਨਾਲ ਵੀ ਚੰਗੀ ਤਰੀਕੇ ਨਾਲ ਫ਼ਿੱਟ ਹੋ ਜਾਂਦੀ ਹੈ: ਟੈਸਟ ਜਨਰੇਟ ਕਰੋ, ਚਲਾਓ, ਅਤੇ ਜੇ ਨਵਾਂ ਸੈੱਟ ਸ਼ੋਰ ਵਧਾਉਂਦਾ ਹੈ ਬਿਨਾਂ ਕਵਰੇਜ ਸੁਧਾਰਨ ਦੇ ਤਾਂ rollback ਕਰੋ।
ਆਪਣੇ ਪ੍ਰੰਪਟ ਨੂੰ ਇੱਕ ਪੁਨਰ-ਉਪਯੋਗ ਹਾਰਨੈਸ ਵਜੋਂ ਰੱਖੋ, ਨਾ ਕਿ ਇੱਕ ਇਕ-ਵਾਰੀ ਬੇਨਤੀ ਵਜੋਂ। ਇੱਕ ਬਲੂਪ੍ਰਿੰਟ ਪ੍ਰੰਪਟ (ਜੋ ਸੀਮਾਵਾਂ, ਫੇਲਿਊਰ ਮੋਡ ਅਤੇ ਇਨਵੈਰੀਐਂਟ ਨੂੰ ਮਜ਼ਬੂਤ ਤੌਰ 'ਤੇ ਮੰਗਦਾ ਹੈ) ਸਾਂਭ ਕੇ ਰੱਖੋ ਅਤੇ ਹਰ ਨਵੇਂ ਫੰਕਸ਼ਨ, ਐਂਡਪਾਇੰਟ, ਜਾਂ UI ਫਲੋ ਲਈ ਦੁਹਰਾਓ।
ਇੱਕ ਸਧਾਰਣ ਆਦਤ ਜੋ ਨਤੀਜਿਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਪਗਰੇਡ ਕਰਦੀ ਹੈ: ਹਰ ਟੈਸਟ ਲਈ ਇੱਕ ਵਾਕ ਲਿਖਵਾਓ ਜੋ ਦੱਸੇ ਕਿ ਜੇ ਇਹ ਫੇਲ ਹੋਇਆ ਤਾਂ ਕਿਹੜਾ ਬੱਗ ਫੜਿਆ ਜਾਂਦਾ। ਜੇ ਵਾਕ ਸਧਾਰਨ ਹੈ, ਤਾਂ ਟੈਸਟ ਸ਼ਾਇਦ ਸ਼ੋਰ ਹੋਵੇ।
ਡੋਮੇਨ ਇਨਵੈਰੀਐਂਟ ਦੀ ਇੱਕ ਜ਼ਿੰਦੀ ਸੂਚੀ ਰੱਖੋ। ਇਹ ਆਪਣੇ ਦਿਮਾਗ ਵਿੱਚ ਨਾ ਰੱਖੋ। ਜਦ ਤੂਸੀਂ ਅਸਲ ਬੱਗ ਲੱਭੋ ਤਾਂ ਇਸਨੂੰ ਜੋੜੋ।
ਇੱਕ ਹਲਕਾ ਵਰਕਫਲੋ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾਵੋਗੇ:
ਜੇ ਤੁਸੀਂ ਚੈਟ ਰਾਹੀਂ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਸ ਚੱਕਰ ਨੂੰ Koder.ai (Koder.ai) ਵਿੱਚ ਚਲਾਓ ਤਾਂ ਕਿ contract, ਯੋਜਨਾ, ਅਤੇ ਜਨਰੇਟ ਕੀਤੇ ਟੈਸਟ ਇੱਕ ਥਾਂ ਤੇ ਰਹਿਣ। ਜਦੋਂ ਰਿਫੈਕਟਰ ਨੇ ਅਣਚਾਹੇ ਢੰਗ ਨਾਲ ਵਿਵਹਾਰ ਬਦਲਿਆ, snapshot ਅਤੇ rollback ਨਾਲ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਤੁਲਨਾ ਅਤੇ ਦੁਹਰਾਓ ਕਰ ਸਕਦੇ ਹੋ ਤਾਕਿ ਤੁਹਾਡਾ ਉੱਚ-ਸਿਗਨਲ ਸੈੱਟ ਸਥਿਰ ਰਹੇ।
ਡਿਫ਼ੌਲਟ: ਇੱਕ ਅਸਲੀ ਬਗ ਫੜਨ ਯੋਗ ਛੋਟਾ ਸੈੱਟ ਲਕੜੋ।
ਇੱਕ ਚੰਗਾ ਨਿਯਮ ਕੰਮ ਲਈ ਹੈ ਹਰ ਯੂਨਿਟ ਲਈ 6–10 ਟੈਸਟ (ਫੰਕਸ਼ਨ/ਮੋਡੀਊਲ)। ਜੇ ਇਸ ਤੋਂ ਵੱਧ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ ਤਾਂ ਅਕਸਰ ਅਰਥ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡਾ ਯੂਨਿਟ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਤੁਹਾਡਾ contract ਅਸਪਸ਼ਟ ਹੈ।
ਹੈਪੀ-ਪਾਥ ਟੈਸਟ ਵੱਧਤਰ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਡਾ ਉਦਾਹਰਣ ਅਜੇ ਵੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਇਹ ਅਕਸਰ ਉਹ ਚੀਜ਼ਾਂ ਛੱਡ ਜਾਂਦੇ ਹਨ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਟੁੱਟਦੀਆਂ ਹਨ।
ਉੱਚ-ਸਿਗਨਲ ਟੈਸਟ ਹੇਠਾਂ ਨਿਸ਼ਾਨੇ ਬਣਾਉਂਦੇ ਹਨ:
ਇੱਕ ਛੋਟਾ contract ਲਿਖੋ ਜੋ ਇੱਕ ਸਾਹੀਂ ਸਾਹ 'ਚ ਪੜ੍ਹਿਆ ਜਾ ਸਕੇ:
ਫਿਰ ਉਸ contract ਤੋਂ ਟੈਸਟ ਜਨਰੇਟ ਕਰੋ, ਸਿਰਫ ਉਦਾਹਰਣਾਂ ਤੋਂ ਨਹੀਂ।
ਪਹਿਲਾਂ ਇਹਨਾਂ ਨੂੰ ਟੈਸਟ ਕਰੋ:
ਹਰ ਇਨਪੁੱਟ ਡਾਇਮੇਨਸ਼ਨ ਲਈ ਇੱਕ ਜਾਂ ਦੋ ਚੁਣੋ ਤਾਂ ਹਰ ਟੈਸਟ ਇੱਕ ਵਿਲੱਖਣ ਖਤਰੇ ਨੂੰ ਢੱਕੇ।
ਇੱਕ ਚੰਗਾ ਫੇਲਿਊਰ-ਮੋਡ ਟੈਸਟ ਦੋ ਗੱਲਾਂ ਸਾਬਤ ਕਰਦਾ ਹੈ:
ਜੇ ਡੇਟਾਬੇਸ ਲਿਖਤ ਸੰਬੰਧੀ ਹੈ ਤਾਂ ਹਮੇਸ਼ਾ ਫੇਲ ਦੇ ਬਾਅਦ ਸਟੋਰੇਜ ਵਿੱਚ ਕੀ ਹੋਇਆ ਇਹ ਵੇਰਵਾ ਚੈੱਕ ਕਰੋ।
ਮੂਲ ਤਰੀਕਾ: ਇਨਵੈਰੀਐਂਟ ਨੂੰ ਵੇਖਣਯੋਗ ਨਤੀਜੇ 'ਤੇ ਐਸਰਸ਼ਨ ਵਾਂਗ ਬਦਲੋ।
ਉਦਾਹਰਣ:
expect(total).toBeGreaterThanOrEqual(0)ਅਕਸਰੇ ਭੁੱਲਾਂ ਉਹੀ ਹਨ ਜਿੱਥੇ ਰਿਟਰਨ ਵੈਲਯੂ ਠੀਕ ਲੱਗਦੀ ਹੈ ਪਰ ਸਾਈਡ-ਇਫੈਕਟ ਗਲਤ ਹੁੰਦਾ ਹੈ—ਇਸ ਲਈ ਦੋਹਾਂ ਨੂੰ ਚੈਕ ਕਰੋ।
ਉਚਿਤ ਹੈ ਕਿ ਹੈਪੀ-ਪਾਥ ਟੈਸਟ ਨੂੰ ਰੱਖਣਾ ਜਦੋਂ ਇਹ ਕਿਸੇ ਇਨਵੈਰੀਐਂਟ ਜਾਂ ਆਮ ਇੰਟੈਗਰੇਸ਼ਨ ਨੂੰ ਬਚਾਉਂਦਾ ਹੋਵੇ।
ਰੱਖਣ ਦੇ ਚੰਗੇ ਕਾਰਨ:
ਨਹੀਂ ਤਾਂ, ਇਸ ਨੂੰ ਸੀਮਾ/ਫੇਲਿਊਰ ਟੈਸਟ ਲਈ ਤਬਦੀਲ ਕਰੋ ਜੋ ਹੋਰ ਬੱਗ ਕਲਾਸਾਂ ਫੜ ਸਕਦੇ ਹਨ।
PHASE 1: ਪਹਿਲਾਂ ਯੋਜਨਾ ਲਵੋ। ਮਾਡਲ ਨੂੰ ਇਹ ਮੰਗੋ:
ਤੁਹਾਡੇ ਮਨਜ਼ੂਰ ਹੋਣ 'ਤੇ ਹੀ PHASE 2 (ਕੋਡ ਜਨਰੇਟ ਕਰੋ) ਦੀ ਮੰਗ ਕਰੋ। ਇਹ “20 ਸਮਾਨ ਟੈਸਟ” ਆਉਣ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਮਲ-ਮੋਕਿੰਗ ਤੋਂ brittle/tests ਬਚਾਓ ਲਈ:
ਜੇ ਕੋਈ ਟੈਸਟ ਰਿਫੈਕਟਰ ਤੇ ਟੁੱਟਦਾ ਹੈ ਪਰ ਬਿਹੇਵਿਅਰ ਨਹੀਂ ਬਦਲਿਆ, ਤਾਂ ਆਮਤੌਰ 'ਤੇ ਉਹ ਓਵਰ-ਮੌਕਡ ਜਾਂ implementation-coupled ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਡਿਲੀਸ਼ਨ ਟੈਸਟ ਵਰਤੋਂ:
ਡੁਪਲਿਕੇਟਾਂ ਲਈ ਵੀ ਸਕੈਨ ਕਰੋ: