03 ਮਈ 2025·8 ਮਿੰਟ
ਕਿਵੇਂ ਆਟੋਮੇਟੇਡ ਟੈਸਟ ਜਨਰੇਸ਼ਨ AI-ਲਿਖੀ ਲੌਜਿਕ ਨੂੰ ਪੂਰਕ ਬਣਾਉਂਦਾ ਹੈ
ਜਾਣੋ ਕਿਉਂ ਆਟੋ-ਜਨਰੇਟ ਟੈਸਟ AI-ਲਿਖੀ ਐਪ ਲੌਜਿਕ ਨਾਲ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਕਿਵੇਂ ਇੱਕ ਵਰਕਫਲੋ ਬਣਾਈਏ ਜਿੱਥੇ ਕੋਡ, ਟੈਸਟ ਅਤੇ CI ਚੈੱਕ ਇੱਕੱਠੇ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ।
ਜਾਣੋ ਕਿਉਂ ਆਟੋ-ਜਨਰੇਟ ਟੈਸਟ AI-ਲਿਖੀ ਐਪ ਲੌਜਿਕ ਨਾਲ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਕਿਵੇਂ ਇੱਕ ਵਰਕਫਲੋ ਬਣਾਈਏ ਜਿੱਥੇ ਕੋਡ, ਟੈਸਟ ਅਤੇ CI ਚੈੱਕ ਇੱਕੱਠੇ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ।
AI-ਦੁਆਰਾ ਲਿਖਿਆ ਗਿਆ ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਅਰਥ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਦੇ "ਕੰਮ ਕਰਨ ਵਾਲੇ" ਹਿੱਸੇ ਇੱਕ ਸਹਾਇਕ ਦੀ ਮਦਦ ਨਾਲ ਤਿਆਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ: ਨਵੀਆਂ ਫੰਕਸ਼ਨਾਂ, ਛੋਟੇ ਫੀਚਰ, ਰਿਫੈਕਟਰ, ਏਡਜ-ਕੇਸ ਹੈਂਡਲਿੰਗ ਅਤੇ ਮੌਜੂਦਾ ਮਾਡਿਊਲਾਂ ਦੀਆਂ ਦੁਬਾਰਾ ਲਿਖਤਾਂ। ਤੁਸੀਂ ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ ਕੀ ਬਣਾਉਣਾ ਹੈ, ਪਰ ਪਹਿਲੀ ਵਰਜਨ ਅਕਸਰ ਜਲਦੀ ਮਿਲ ਜਾਂਦੀ ਹੈ—ਅਤੇ ਕਈ ਵਾਰੀ ਅਜਿਹੀਆਂ ਅਨੁਮਾਨਾਂ ਨਾਲ ਜੋ ਤੁਹਾਨੂੰ ਬਾਦ ਵਿੱਚ ਨਜ਼ਰ ਨਹੀਂ ਆਉਂਦੀਆਂ।
ਆਟੋਮੇਟਿਕ ਟੈਸਟ ਜਨਰੇਸ਼ਨ ਵੈਰੀਫਿਕੇਸ਼ਨ ਪਾਸੇ ਦੀ ਮਿਲਦੀ ਜੁਲਦੀ ਸਮਰੱਥਾ ਹੈ। ਹਰ ਟੈਸਟ ਹੱਥੋਂ ਨਹੀਂ ਲਿਖਣੀ ਪਈਦੀ; ਟੂਲ ਤੁਹਾਡੇ ਕੋਡ, ਕਿਸੇ ਸਪੈਸ ਜਾਂ ਪਿਛਲੀਆਂ ਬਗਾਂ ਤੋਂ ਸਿੱਖੇ ਨਮੂਨਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਟੈਸਟ ਕੇਸ ਅਤੇ assertions ਪੇਸ਼ ਕਰ ਸਕਦੇ ਹਨ। ਅਮਲ ਵਿੱਚ, ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸ਼ਾ ਹੋ ਸਕਦਾ ਹੈ:
ਇੱਕ ਜਨਰੇਟ ਕੀਤਾ ਟੈਸਟ ਭਟਕਾਉਣ ਵਾਲਾ ਹੋ ਸਕਦਾ ਹੈ: ਇਹ ਮੌਜੂਦਾ ਵਿਵਹਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਵਿਵਹਾਰ ਗਲਤ ਹੋ, ਜਾਂ ਇਹ ਉਹ ਪ੍ਰੋਡਕਟ ਨਿਯਮ ਮਿਸ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਲੋਕਾਂ ਦੇ ਦਿਮਾਗ ਵਿੱਚ ਅਤੇ ਟਿਕਟ ਕੰਮੈਂਟਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ। ਇਸੇ ਲਈ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਜ਼ਰੂਰੀ ਹੈ। ਕਿਸੇ ਨੂੰ ਇਹ ਜਾਂਚਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਟੈਸਟ ਦਾ ਨਾਮ, ਸੈਟਅਪ ਅਤੇ assertions ਅਸਲ ਇਰਾਦੇ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ—ਨਾ ਕਿ ਸਿਰਫ ਉਹ ਜੋ ਕੋਡ ਅੱਜ ਕਰ ਰਿਹਾ ਹੈ।
ਮੂਲ ਵਿਚਾਰ ਸਾਦਾ ਹੈ: ਕੋਡ ਅਤੇ ਟੈਸਟ ਇਕ ਹੀ ਵਰਕਫਲੋ ਵਾਂਗ ਵਿਕਸਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਜੇ AI ਤੁਹਾਡੀ ਮਦਦ ਨਾਲ ਲੌਜਿਕ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦਾ ਹੈ, ਆਟੋ-ਜਨਰੇਟ ਟੈਸਟ ਉਸ ਇਰਾਦੇ ਨੂੰ ਵੀ ਉਤਨੀ ਹੀ ਤੇਜ਼ੀ ਨਾਲ ਲਾਕ ਕਰਦੇ ਹਨ—ਤਾਂ ਜੋ ਅਗਲਾ ਬਦਲਾਅ (ਮਨੁੱਖੀ ਜਾਂ AI) ਲਈ "ਹਾਲੇ ਵੀ ਸਹੀ" ਦੀ ਸਪਸ਼ਟ, ਐਗਜ਼ੀਕਿuble ਪਰਿਭਾਸ਼ਾ ਹੋਵੇ।
ਅਮਲ ਵਿੱਚ, ਇਹ “ਜੋੜ-ਆਉਟਪੁੱਟ” ਵਿਧੀ ਉਸ ਵੇਲੇ ਰੱਖਣ ਵਿੱਚ ਸਹੂਲਤਮੰਦ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਹਾਡੀ ਡਿਵਫਲੋ ਪਹਿਲਾਂ ਹੀ ਚੈਟ-ਚਲਿਤ ਹੋਵੇ। ਉਦਾਹਰਣ ਵਜੋਂ, Koder.ai (ਇੱਕ vibe-coding ਪਲੇਟਫ਼ਾਰਮ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਲਈ ਚੈਟ ਰਾਹੀਂ) ਵਿੱਚ, “ਫੀਚਰ + ਟੈਸਟ” ਨੂੰ ਇੱਕ ਹੀ ਡਿਲਿਵਰੇਬਲ ਦੀ ਤਰ੍ਹਾਂ ਸਲੋਚਨਾ ਨੈ츄ਰਲ ਹੈ: ਤੁਸੀਂ ਵਿਹਾਰ ਨੂੰ ਵਰਣਨ ਕਰੋ, ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਜਨਰੇਟ ਕਰੋ, ਫਿਰ ਇੱਕੋ ਗੱਲਬਾਤ ਵਿੱਚ ਟੈਸਟ ਜਨਰੇਟ ਅਤੇ ਸਮੀਖਿਆ ਕਰੋ ਪਹਿਲਾਂ ਡਿਪਲੋਇ ਕਰਨ ਤੋਂ।
AI-ਲਿਖਿਆ ਕੋਡ ਇੱਕ ਸੁਪਰਪਾਵਰ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ: ਫੀਚਰ ਤੇਜ਼ੀ ਨਾਲ ਆਉਂਦੇ ਹਨ, ਬੋਇਲਰਪਲੇਟ ਘੱਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਰਿਫੈਕਟਰ ਜੋ ਘੰਟਿਆਂ ਲੈਂਦੇ ਸਨ ਉਹ ਕੌਫੀ ਠੰਢੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੋ ਸਕਦੇ ਹਨ। ਫਿੱਰ ਇਹ ਹੈ ਕਿ ਗਤੀ ਖਤਰੇ ਦੀ ਸ਼ਕਲ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਜਦੋਂ ਕੋਡ ਉਤਪਾਦਿਤ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਗਲਤੀਆਂ ਭੇਜਣਾ ਵੀ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ—ਕਈ ਵਾਰੀ ਬਹੁਤ ਹੀ ਸੁਖਾਵਾਂ।
AI ਸਹਾਇਕ “ਉਚਿਤ” ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਬਣਾਉਣ ਵਿੱਚ ਚੰਗੇ ਹਨ, ਪਰ ਉਚਿਤ ਦਾ ਮਤਲਬ ਹੈ ਤੁਹਾਡੇ ਖ਼ਾਸ ਡੋਮੇਨ ਲਈ ਸਹੀ ਨਾਂ।
ਏਡਜ ਕੇਸ ਪਹਿਲੇ ਨੁਕਸਾਨ ਹੋਂਦੇ ਹਨ। AI-ਜਨਰੇਟ ਲੌਜਿਕ ਅਕਸਰ ਹੈਪੀ ਪਾਥ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਭਾਲਦੀ ਹੈ, ਪਰ ਬਾਊਂਡਰੀ ਸ਼ਰਤਾਂ 'ਤੇ ਝਟਕਦਾ ਹੈ: ਖਾਲੀ ਇਨਪੁਟ, ਟਾਈਮਜ਼ੋਨ ਸਮੱਸਿਆਵਾਂ, ਗੋਲ-ਮੈਚਿੰਗ, ਨੱਲ ਵੈਲਿਊਜ਼, ਰੀਟ੍ਰਾਈ ਵਿਹਾਰ, ਜਾਂ "ਇਹ ਕਦੇ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ" ਸਥਿਤੀਆਂ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ।
ਗਲਤ ਅਨੁਮਾਨ ਇੱਕ ਹੋਰ ਮਾਮੂਲੀ ਮੁੱਦਾ ਹੈ। ਇੱਕ ਸਹਾਇਕ ਉਹ ਜ਼ਰੂਰਤਾਂ ਅਨੁਮਾਨ ਲੈ ਸਕਦਾ ਹੈ ਜੋ ਸਪੱਸ਼ਟ ਨਹੀਂ ਕਹੀਆਂ ਗਈਆਂ ("ਉਪਭੋਗਤਾ ਹਮੇਸ਼ਾ authenticate ਹੋੰਦੇ ਹਨ", "IDs ਨੰਬਰਿਕ ਹਨ", "ਇਹ ਫੀਲਡ ਹਮੇਸ਼ਾ ਮੌਜੂਦ ਹੈ"), ਜਾਂ ਇਹ ਮੌਜੂਦਾ ਪੈਟਰਨ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਿਸਟਮ ਦੇ ਨਿਯਮਾਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਚੁੱਪ ਰਿਗਰੈਸ਼ਨ ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਹੋ ਸਕਦੇ ਹਨ। ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਮੰਗਦੇ ਹੋ, ਸਹਾਇਕ ਲੌਜਿਕ ਦਾ ਇੱਕ ਹਿੱਸਾ ਦੁਬਾਰਾ ਲਿਖ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਅਨਲੱਗੜੀ ਚੀਜ਼ ਟੁੱਟ ਜਾਂਦੀ ਹੈ—ਬਿਨਾਂ ਸਪਸ਼ਟ ਐਰਰ ਦੇ। ਕੋਡ ਅਜੇ ਵੀ ਕੰਪਾਇਲ ਹੁੰਦਾ ਹੈ, UI ਲੋਡ ਹੁੰਦਾ ਹੈ, ਪਰ ਇੱਕ ਪ੍ਰਾਇਸਿੰਗ ਨਿਯਮ, ਪਰਮਿਸ਼ਨ ਚੈਕ, ਜਾਂ ਡੇਟਾ ਕਨਵਰਜ਼ਨ ਹੁਣ ਕੁਝ ਹੱਦ ਤੱਕ ਗਲਤ ਹੈ।
ਜਦੋਂ ਕੋਡ ਬਦਲਾਅ ਤੇਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ, ਮੈਨੂਅਲ ਟੈਸਟ ਇੱਕ ਬੋਤਲ-ਨੈਕ ਬਣ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇੱਕ ਦਾਅਵ ਤੇ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਜਾ ਤਾਂ ਹੋਰ ਸਮਾਂ ਕਲਿੱਕ ਕਰਨ 'ਚ ਲਗੇਗਾ (ਜੋ ਡਿਲਿਵਰੀ ਨੂੰ ਧੀਮੀ ਕਰੇਗਾ) ਜਾਂ ਤੁਸੀਂ ਘੱਟ ਟੈਸਟ ਕਰੋਗੇ (ਜਿਹੜਾ escapes ਵਧਾਉਂਦਾ ਹੈ)। ਡਿਸਿਪਲਿੰਨ ਵਾਲੀਆਂ QA ਟੀਮਾਂ ਵੀ ਹਰ ਵਰਾਇਅਂਟ ਨੂੰ ਮੈਨੂਅਲ ਤਰੀਕੇ ਨਾਲ ਕਵਰ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ ਜਦੋਂ ਬਦਲਾਅ ਤੇਜ਼ ਅਤੇ ਵਿਸ਼ਾਲ ਹਨ।
ਵਧੇਰੇ, ਮੈਨੂਅਲ ਚੈੱਕ ਸਥਿਰ ਤਰੀਕੇ ਨਾਲ ਦੁਹਰਾਏ ਨਹੀਂ ਜਾ ਸਕਦੇ। ਉਹ ਕਿਸੇ ਦੀ ਯਾਦ ਜਾਂ ਚੈਕਲਿਸਟ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਡੈਡਲਾਈਨਾਂ ਤੰਗ ਹੋਣ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਛੱਡ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ—ਉਹੀ ਸਮਾਂ ਜਦੋਂ ਖ਼ਤਰਾ ਸਭ ਤੋਂ ਵੱਧ ਹੁੰਦਾ ਹੈ।
ਆਟੋਮੇਟਿਕ ਟੈਸਟ ਇੱਕ ਟਿਕਾਉ ਸੇਫਟੀ ਨੈਟ ਬਣਾਉਂਦੇ ਹਨ: ਉਹ ਉਮੀਦਾਂ ਨੂੰ ਐਗਜ਼ੀਕਿuble ਬਣਾਉਂਦੇ ਹਨ। ਇੱਕ ਚੰਗਾ ਟੈਸਟ ਕਹਿੰਦਾ ਹੈ, “ਇਹਨਾਂ ਇਨਪੁੱਟਾਂ ਅਤੇ ਇਸ ਸੰਦਰਭ ਦੇ ਨਾਲ, ਅਸੀਂ ਇਸ ਨਤੀਜੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਾਂ।” ਇਹ ਸਿਰਫ਼ ਵੈਰੀਫਿਕੇਸ਼ਨ ਨਹੀਂ; ਇਹ ਭਵਿੱਖ ਦੇ ਤੁਸੀਂ, ਟੀਮਮੈਟਾਂ, ਅਤੇ ਇੱਥੇ ਤੱਕ ਕਿ AI ਸਹਾਇਕ ਲਈ ਵੀ ਸੰਚਾਰ ਹੈ।
ਜਦੋਂ ਟੈਸਟ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ, ਬਦਲਾਅ ਘੱਟ ਡਰਾਉਣੇ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਫੀਡਬੈਕ ਤੁਰੰਤ ਮਿਲਦਾ ਹੈ। ਕੋਡ ਰਿਵਿਊ, ਸਟੇਜਿੰਗ, ਜਾਂ ਗਾਹਕਾਂ ਤੋਂ ਸਮੱਸਿਆ ਪਾਉਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਮਿੰਟਾਂ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਲੱਭ ਲੈਂਦੇ ਹੋ।
ਜਿਤਨੀ ਜਲਦੀ ਕੋਈ ਬੱਗ ਫੜੀ ਜਾਂਦੀ ਹੈ, ਉਸਦੀ ਮੁਰੰਮਤ ਸਸਤੀ ਹੁੰਦੀ ਹੈ। ਟੈਸਟ feedback ਲੂਪ ਛੋਟਾ ਕਰਦੇ ਹਨ: ਉਹ ਓਹੇ ਵੇਲੇ ਵਿਵਹਾਰ-ਅਸਮੰਜਸ ਅਤੇ ਛੁੱਟੇ ਹੋਏ ਏਡਜ ਕੇਸ ਨੂੰ ਉਭਾਰਦੇ ਹਨ ਜਦੋਂ ਇਰਾਦਾ ਹਾਲੇ ਤਾਜ਼ਾ ਹੁੰਦਾ ਹੈ। ਇਸ ਨਾਲ ਮੁੜਕੰਮ ਘਟਦਾ ਹੈ, "ਫਿਕਸ-ਫੋਰਵਰਡ" ਪੈਚ੍ਹਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ, ਅਤੇ AI ਦੀ ਤੇਜ਼ੀ ਨੂੰ AI-ਚਲਿਤ ਚੱਕਰ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
AI-ਲਿਖਿਆ ਕੋਡ ਸਭ ਤੋਂ ਤੇਜ਼ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਗੱਲਬਾਤ ਵਾਂਗ ਸਲੋਚਦੇ ਹੋ, ਇਕ-ਵਾਰ ਦੀ ਡਿਲਿਵਰੇਬਲ ਵਾਂਗ ਨਹੀਂ। ਟੈਸਟ ਉਹ ਹਨ ਜੋ ਉਸ ਗੱਲਬਾਤ ਨੂੰ ਮਾਪਣਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
Spec: ਤੁਸੀਂ ਵੇਰਵਾ ਦਿੰਦੇ ਹੋ ਕਿ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ (ਇਨਪੁੱਟ, ਆਉਟਪੁੱਟ, ਏਡਜ ਕੇਸ)।
Code: AI ਉਹ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਲਿਖਦਾ ਹੈ ਜੋ ਦਾਅਵਾ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਉਸ ਵਰਣਨ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ।
Tests: ਤੁਸੀਂ (ਜਾਂ AI) ਉਹ ਚੈੱਕ ਜਨਰੇਟ ਕਰਦੇ ਹੋ ਜੋ ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਪ੍ਰਮਾਣਤ ਕਰਦੇ ਹਨ।
ਇਸ ਲੂਪ ਨੂੰ ਦੁਹਰਾਓ ਅਤੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਵੱਧ ਕੋਡ ਨਹੀਂ ਬਣਾ ਰਹੇ—ਤੁਸੀਂ “ਡਨ” ਦੀ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਲਗਾਤਾਰ ਤਿੱਖੀ ਕਰ ਰਹੇ ਹੋ।
“ਅਵੈਧ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਨਰਮੀ ਨਾਲ ਸੰਭਾਲੋ” ਵਰਗਾ ਧੁੰਦਲਾ ਨਿਯਮ ਕੋਡ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਟੈਸਟ ਅਸਪਸ਼ਟ ਹੋ ਨਹੀਂ ਸਕਦਾ। ਇਹ ਤੁਰੰਤ ਵਿਸਥਾਰ ਮੰਗਦਾ ਹੈ:
ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ ਉਹ ਵੇਰਵਿਆਂ ਨੂੰ ਟੈਸਟ ਵਿੱਚ ਪ੍ਰਗਟਾਉਂਦੇ ਹੋ, ਅਸਪਸ਼ਟ ਭਾਗ ਤੁਰੰਤ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ। ਇਹ ਸਪਸ਼ਟਤਾ AI ਨੂੰ ਦਿੱਤੇ ਗਏ ਪ੍ਰਾਂਪਟ ਨੂੰ ਸੁਧਾਰਦੀ ਹੈ ਅਤੇ ਅਕਸਰ ਸਧਾਰਨ, ਇਸਥਿਰ ਇੰਟਰਫੇਸ ਦੀ ਲੋੜ ਪੈਦਾ ਕਰਦੀ ਹੈ।
AI ਕੋਡ ਠੀਕ ਦਿਸ ਸਕਦਾ ਹੈ ਪਰ ਆਪਣੀਆਂ ਅਨੁਮਾਨਾਂ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ। ਜਨਰੇਟ ਕੀਤੇ ਟੈਸਟ ਇੱਕ ਪ੍ਰਯੋਗੀ ਤਰੀਕਾ ਹਨ ਦਿਖਾਉਣ ਲਈ ਕਿ ਕੋਡ ਜੋ ਦਾਅਵਾ ਕਰ ਰਿਹਾ ਹੈ ਉਹ ਸਚ ਹੈ:
ਲਕੜੀ ਇਹ ਨਹੀਂ ਕਿ ਜਨਰੇਟ ਟੈਸਟਾਂ 'ਤੇ ਅੰਧ ਧਰੋ; ਉਨ੍ਹਾਂ ਨੂੰ ਤੇਜ਼, ਸੰਰਚਿਤ ਸ਼ਕ ਵਜੋਂ ਵਰਤੋ।
ਇੱਕ ਫੇਲ ਟੈਸਟ ਕਾਰਵਾਈਯੋਗ ਫੀਡਬੈਕ ਹੈ: ਇਹ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਇਕ ਅਸਮੰਜਸ ਦਿਖਾਉਂਦਾ ਹੈ ਸਪੈਸ ਅਤੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵਿਚਕਾਰ। AI ਨੂੰ ਕਹਿਣ ਦੀ ਬਜਾਏ "ਫਿਕਸ ਕਰੋ", ਤੁਸੀਂ ਫੇਲ ਦਿੱਤਾ ਟੈਸਟ ਪੇਸਟ ਕਰ ਸਕਦੇ ਹੋ ਤੇ ਕਹਿ ਸਕਦੇ ਹੋ: “ਇੰਪਰਮਿਟ ਬਦਲਾਅ ਤੋਂ ਬਿਨਾਂ ਕੋਡ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਟੈਸਟ ਪਾਸ ਹੋ ਜਾਵੇ।” ਇਸ ਨਾਲ ਡਿਬੱਗਿੰਗ ਇੱਕ ਕੇਂਦਰਤ ਇਟਰੈਸ਼ਨ ਬਣ ਜਾਂਦੀ ਹੈ, ਅਨੁਮਾਨ ਨਹੀਂ।
ਆਟੋ-ਜਨਰੇਟ ਟੈਸਟ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਟੈਸਟ ਰਣਨੀਤੀ ਨੂੰ ਸਹਾਇਤਾ ਦਿੰਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਕਲਾਸਿਕ "ਟੈਸਟ ਪਾਈਰਾਮਿਡ" ਨੂੰ। ਪਾਈਰਾਮਿਡ ਆਪਣੇ ਆਪ ਦੇ ਲਈ ਕੋਈ ਨਿਯਮ ਨਹੀਂ; ਇਹ ਫੀਡਬੈਕ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਰੱਖਣ ਦੀ ਵਿਧੀ ਹੈ ਜਦੋਂ ਕਿ ਹਕੀਕਤੀ ਦੁਨੀਆ ਦੀਆਂ ਫੇਲੀਆਂ ਨੂੰ ਵੀ ਫੜਨਾ ਹੈ।
AI ਹਰ ਲੇਅਰ ਲਈ ਟੈਸਟ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਸਭ ਤੋਂ ਵਧੀਆ ਨਤੀਜੇ ਤਦ ਆਉਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਸਸਤੇ ਟੈਸਟ (ਪਾਈਰਾਮਿਡ ਦੇ ਤਲ) ਵੱਧ ਜਨਰੇਟ ਕਰੋ ਅਤੇ ਮਹਿੰਗੇ (ਉੱਪਰ) ਘੱਟ। ਇਹ ਸੰਤੁਲਨ ਤੁਹਾਡੀ CI ਪਾਈਪਲਾਈਨ ਨੂੰ ਤੇਜ਼ ਰੱਖਦਾ ਹੈ ਪਰ ਯੂਜ਼ਰ ਅਨੁਭਵ ਦੀ ਰੱਖਿਆ ਵੀ ਕਰਦਾ ਹੈ।
ਯੂਨਿਟ ਟੈਸਟ ਛੋਟੇ ਚੈੱਕ ਹਨ ਫਰੰਕਸ਼ਨਾਂ, ਮੇਥਡਾਂ, ਜਾਂ ਮਾਡਿਊਲਾਂ ਲਈ। ਉਹ ਤੇਜ਼ ਚਲਦੇ ਹਨ, ਬਾਹਰੀ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਲੋੜ ਨਹੀਂ, ਅਤੇ AI-ਜਨਰੇਟ ਕੀਤੇ ਏਡਜ ਕੇਸਾਂ ਲਈ ਆਦਰਸ਼ ਹਨ।
ਆਟੋ-ਜਨਰੇਟ ਟੈਸਟਾਂ ਨੂੰ ਇਹ ਕੰਮ ਕਰਨ ਲਈ ਵਰਤੋਂ:
ਕਿਉਂਕਿ ਯੂਨਿਟ ਟੈਸਟ ਸੰਕੁਚਿਤ ਹਨ, ਉਹ ਸਮੀਖਿਆ ਲਈ ਅਸਾਨ ਹਨ ਅਤੇ ਫਲੇਕੀ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੁੰਦੀ ਹੈ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਦੇਖਦੇ ਹਨ ਕਿ ਹਿੱਸੇ ਕਿਵੇਂ ਇਕੱਠੇ ਕੰਮ ਕਰਦੇ ਹਨ: ਤੁਹਾਡਾ API ਡੀਬੀ ਨਾਲ, ਇੱਕ ਸਰਵਿਸ ਹੋਰ ਸਰਵਿਸ ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ, ਕਿਊ ਪ੍ਰੋਸੈਸਿੰਗ, authentication ਆਦਿ।
AI-ਜਨਰੇਟ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਕੀਮਤੀ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਵੱਧ ਡਿਸੀਪਲਿਨ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ:
ਇਨ੍ਹਾਂ ਨੂੰ "ਕਾਂਟ੍ਰੈਕਟ ਚੈਕ" ਸੋਚੋ ਜੋ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਕੰਪੋਨੈਂਟਾਂ ਦੇ ਦਰਮਿਆਨ ਦੀ ਸੀਮਾਂ ਅਜੇ ਵੀ ਮਜ਼ਬੂਤ ਹਨ।
E2E ਟੈਸਟ ਮੁੱਖ ਯੂਜ਼ਰ ਫਲੋਜ਼ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ। ਉਹ ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਹਨ: ਡੂੰਘੇ, ਫਲੇਕੀ, ਅਤੇ ਡਿਬੱਗ ਕਰਨ ਵਿੱਚ ਔਖੇ।
ਆਟੋ-ਜਨਰੇਟ ਕੀਤੇ E2E ਸੇਨੇਰੀਓਜ਼ ਨੂੰ ਡ੍ਰਾਫਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਤੁਹਾਨੂੰ ਉਨ੍ਹਾਂ ਨੂੰ ਬਹੁਤ ਸਖ਼ਤੀ ਨਾਲ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੁੱਝ ਅਹੰਕਾਰਪੂਰਨ ਪਾਥ ਰੱਖੋ (ਸਾਈਨਅਪ, ਚੈਕਆਊਟ, ਕੋਰ ਵਰਕਫਲੋ) ਅਤੇ ਹਰ ਫੀਚਰ ਲਈ E2E ਟੈਸਟ ਜਨਰੇਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ।
ਸਭ ਕੁਝ ਜਨਰੇਟ ਕਰਨ ਦਾ ਉਦੇਸ਼ ਨਾ ਰੱਖੋ। ਬਦਲੇ ਵਿੱਚ:
ਇਹ ਦ੍ਰਿਸ਼ਟੀ ਪਾਈਰਾਮਿਡ ਨੂੰ ਕਾਇਮ ਰੱਖਦੀ ਹੈ—ਅਤੇ ਆਟੋ-ਜਨਰੇਟ ਟੈਸਟਿੰਗ ਨੂੰ ਇੱਕ ਫੋਰਸ ਮਲਟੀਪਲਾਇਰ ਬਣਾ ਦਿੰਦੀ ਹੈ, ਸ਼ੋਰ ਨਹੀਂ।
ਆਟੋ-ਜਨਰੇਟ ਟੈਸਟ ਸਿਰਫ਼ "ਇਸ ਫੰਕਸ਼ਨ ਲਈ ਯੂਨਿਟ ਟੈਸਟ ਲਿਖੋ" ਤਕ ਸੀਮਤ ਨਹੀਂ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਜਨਰੇਟਰ ਤਿੰਨ ਸਰੋਤੋਂ ਤੋਂ ਖਿੱਚਦੇ ਹਨ: ਤੁਹਾਡਾ ਮੌਜੂਦਾ ਕੋਡ, ਉਸ ਦੇ ਪਿਛੇ ਦਾ ਇਰਾਦਾ, ਅਤੇ ਉਹ ਫੇਲਿਯਾਂ ਜੋ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਮਿਲ ਚੁੱਕੀਆਂ ਹਨ।
ਕਿਸੇ ਫੰਕਸ਼ਨ ਜਾਂ ਮਾਡਿਊਲ ਦੇ ਦਿੱਤੇ ਜਾਣ 'ਤੇ, ਟੂਲ ਇਨਪੁੱਟ/ਆਉਟਪੁੱਟ, 브랜ਚਾਂ ਅਤੇ exception ਪਾਥਾਂ ਤੋਂ ਟੈਸਟ ਕੇਸ ਨਿਕਾਲ ਸਕਦੇ ਹਨ। ਇਸ ਦਾ ਅਰਥ ਆਮ ਤੌਰ 'ਤੇ:
ਇਹ ਢਾਂਚਾ AI-ਲਿਖੀ ਲੌਜਿਕ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਤੇਜ਼ੀ ਨਾਲ ਚੈੱਕ ਨਿਰਮਾਣ ਲਈ ਵਧੀਆ ਹੈ ਜੋ ਅੱਜ ਇਹ ਕਰ ਰਿਹਾ ਹੈ ਉਸਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ acceptance criteria, ਯੂਜ਼ਰ ਸਟੋਰੀਜ਼, ਜਾਂ ਉਦਾਹਰਣ ਟੇਬਲਾਂ ਹਨ, ਜਨਰੇਟਰ ਉਹਨਾਂ ਨੂੰ ਟੈਸਟਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ ਜੋ ਸਪੈਸ ਵਰਗੇ ਪੜ੍ਹਨ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਕੋਡ-ਉਤਪੱਨ ਟੈਸਟਾਂ ਨਾਲੋਂ ਵੱਧ ਮੁੱਲ ਰੱਖਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ "ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ" ਨੂੰ ਬੰਦ ਕਰਦੇ ਹਨ, ਨਾ ਕਿ "ਅੱਜ ਕੀ ਹੋ ਰਿਹਾ ਹੈ"।
ਇੱਕ ਪ੍ਰਾਇਆਤਮਿਕ ਨਮੂਨਾ: ਕੁਝ ਮੋਹਤਾਜ਼ ਉਦਾਹਰਣ (ਇਨਪੁੱਟ + ਉਮੀਦ ਕੀਤਾ ਨਤੀਜਾ) ਦਿਉ ਅਤੇ ਜਨਰੇਟਰ ਨੂੰ ਕਹੋ ਕਿ ਉਹਨਾਂ ਨਿਯਮਾਂ ਦੇ ਨਾਲ ਸੰਕਲਪਤ ਐਡਜ ਕੇਸ ਜੋੜੇ।
ਬੱਗ-ਅਧਾਰਤ ਜਨਰੇਸ਼ਨ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਅਰਥਪੂਰਣ ਰਿਗਰੈਸ਼ਨ ਸੂਟ ਬਣਾਉਣ ਦੀ। ਰੀਪ੍ਰੋ ਡਿਟੇਲ, ਲੌਗ, ਜਾਂ ਘੱਟੋ-ਘੱਟ ਪੇਲੋਡ ਦੇ ਕੇ ਜਨਰੇਟ ਕਰੋ:
ਸਨੈਪਸ਼ਾਟ ਟੈਸਟ (ਗੋਲਡਨ) ਸਥਿਰ ਆਉਟਪੁੱਟ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦੇ ਹਨ (ਰੇਂਡਰ ਕੀਤੀ UI, ਸੀਰਿਆਲਾਈਜ਼ਡ ਰਿਸਪਾਂਸ). ਪਰ ਉਹਾਂ ਨੂੰ ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤੋ: ਵੱਡੇ ਸਨੈਪਸ਼ਾਟ ਨਾਜੁਕ ਗਲਤੀਆਂ ਨੂੰ "ਸਵੀਕਾਰ" ਕਰ ਸਕਦੇ ਹਨ। ਛੋਟੇ, ਕੇਂਦਰਤ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਅਤੇ ਪ੍ਰਮੁੱਖ ਖੇਤਰਾਂ 'ਤੇ assertions ਜੋ ਜ਼ਰੂਰੀ ਹਨ ਉਨ੍ਹਾਂ ਨਾਲ ਜੋੜੋ।
ਆਟੋ-ਜਨਰੇਟ ਟੈਸਟ ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਉਸਨੂੰ ਸਪਸ਼ਟ ਤਰਜੀਹ ਦਿੰਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਪੂਰੇ ਕੋਡਬੇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹੋ ਅਤੇ ਕਹਿੰਦੇ ਹੋ “ਸਾਰੇ ਟੈਸਟ ਬਣਾਓ”, ਤਾਂ ਤੁਹਾਨੂੰ ਸ਼ੋਰ ਮਿਲੇਗਾ: ਘਣੀ-ਮੂਲ ਦੇ ਖ਼ਤਰਨਾਕ ਚੈੱਕ, ਦੁਹਰਾਈ ਗਈ ਕਵਰੇਜ, ਅਤੇ ਫਲੇਕੀ ਟੈਸਟ ਜੋ ਡਿਲਿਵਰੀ ਨੂੰ ਧੀਮਾ ਕਰਦੇ ਹਨ।
ਉਹਨਾਂ ਫਲੋਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੇ ਟੁੱਟਣ ਨਾਲ ਵਿੱਤੀ, ਕਾਨੂੰਨੀ ਜਾਂ ਖ਼ਿਆਤੀ ਰੂਪ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਡਾ ਨੁਕਸਾਨ ਹੋਵੇ। ਇੱਕ ਸਧਾਰਨ ਖਤਰੇ-ਆਧਾਰਿਤ ਫਿਲਟਰ ਸਕੋਪ ਨੂੰ ਹਕੀਕਤ ਵਿੱਚ ਯਥਾਰਥ ਬਨਾਓ ਅਤੇ ਗੁਣਵੱਤਾ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸੁਧਾਰੋ।
ਪਹਿਲਾਂ ਧਿਆਨ ਦਿਓ:
ਹਰ ਚੁਣੇ ਹੋਏ ਫਲੋ ਲਈ, ਲੇਅਰਾਂ ਵਿੱਚ ਟੈਸਟ ਜਨਰੇਟ ਕਰੋ: ਕੱਛੇ ਲੌਜਿਕ ਲਈ ਕੁਝ ਤੇਜ਼ ਯੂਨਿਟ ਟੈਸਟ, ਅਤੇ ਇੱਕ ਜਾਂ ਦੋ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਜੋ ਪੂਰਾ ਪਾਥ ਚੈੱਕ ਕਰਦੇ ਹਨ।
ਜਨਰੇਟਰ ਨੂੰ ਅਸਲ ਫੇਲ੍ਹਾਂ ਨਾਲ ਮੇਲ ਖਾਣ ਵਾਲੀ ਕਵਰੇਜ ਪਵਿੱਤਰ ਕਰੋ, ਨਾ ਕਿ ਸਿਧਾਂਤੀ ਸੰਯੋਜਨਾਂ ਨਾਲ। ਇੱਕ ਚੰਗਾ ਸ਼ੁਰੂਆਤੀ ਸੈੱਟ ਹੈ:
ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਬੱਗ, ਇੰਸੀਡੈਂਟ ਰਿਪੋਰਟ, ਜਾਂ ਯੂਜ਼ਰ ਫੀਡਬੈਕ ਅਧਾਰ 'ਤੇ ਵੀ ਵਾਧਾ ਕਰ ਸਕਦੇ ਹੋ।
ਇਕ ਨਿਯਮ ਸਪੱਸ਼ਟ ਬਣਾਓ: ਇੱਕ ਫੀਚਰ ਤਦ ਤੱਕ ਪੂਰਾ ਨਹੀਂ ਮੰਨਿਆ ਜਾਵੇਗਾ ਜਦ ਤੱਕ ਟੈਸਟ ਮੌਜੂਦ ਨਹੀਂ। AI-ਲਿਖੇ ਕੋਡ ਦੇ ਨਾਲ ਇਹ ਪਰਿਭਾਸ਼ਾ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਬਣ ਜਾਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ "ਤੇਜ਼ ਸ਼ਿਪਿੰਗ" ਨੂੰ ਚੁਪਕੇ-ਚੁਪਕੇ "ਤੇਜ਼ ਰਿਗਰੈਸ਼ਨ" ਬਣਨ ਤੋਂ ਰੋਕਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇਹ ਅਮਲ ਬਣੇ, ਤਾਂ ਇਸਨੂੰ ਆਪਣੇ ਵਰਕਫਲੋ ਵਿੱਚ ਵੀ ਜੋੜੋ (ਉਦਾਹਰਨ ਲਈ, ਮਰਜ ਤੋਂ ਪਹਿਲਾਂ ਸਬੰਧਤ ਟੈਸਟ ਲਾਜ਼ਮੀ ਕਰੋ) ਅਤੇ ਟੀਮ ਡੌਕਸ ਵਿੱਚ ਉਮੀਦ ਲਿੰਕ ਕਰੋ (ਉਦਾਹਰਨ: /engineering/definition-of-done)।
AI ਤੇਜ਼ੀ ਨਾਲ ਟੈਸਟ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਕੁਆਲਟੀ ਬਹੁਤ ਹੱਦ ਤੱਕ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਪੁੱਛਦੇ ਹੋ। مقصد ਹੈ ਮਾਡਲ ਨੂੰ ਟੈਸਟਾਂ ਦੀ ਓਰ ਗਾਈਡ ਕਰਨਾ ਜੋ ਵਿਹਾਰ ਦੀ ਰੱਖਿਆ ਕਰਨ—ਨਾ ਕਿ ਸਿਰਫ ਕੋਡ ਚਲਾਉਣ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਟੈਸਟਾਂ ਦੀ "ਅਕਾਰ" ਤੈਅ ਕਰ ਦਿਓ ਤਾਂ ਜੋ ਨਿਕਾਸ ਤੁਹਾਡੀ ਰੀਪੋ ਦੇ ਨਾਲ ਮਿਲੇ।
ਸ਼ਾਮਿਲ ਕਰੋ:
should_<behavior>_when_<condition>)src/ ਅਤੇ tests/, ਜਾਂ __tests__/)ਇਸ ਨਾਲ ਮਾਡਲ ਨੂੰ ਉਹ ਰਵਾਇਤ ਬਣਾਉਣ ਤੋਂ ਰੋਕਿਆ ਜਾਵੇਗਾ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਵਰਤਦੀ ਨਹੀਂ।
ਇੱਕ ਮੌਜੂਦਾ ਟੈਸਟ ਫਾਈਲ (ਜਾਂ ਛੋਟਾ ਨਮੂਨਾ) ਪੇਸਟ ਕਰੋ ਅਤੇ ਸਪਸ਼ਟ ਕਹੋ: "ਇਸ ਸ਼ੈਲੀ ਨੂੰ ਮਿਲਾਓ।" ਇਹ ਫੈਸਲੇ ਨਾਂ, ਟੈਸਟ ਡੇਟਾ ਕਿਵੇਂ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਟੇਸਟ ਡਿਜ਼ਾਈਨ (ਟੇਬਲ-ਚਲਿਤ ਜਾਂ ਨਹੀਂ) ਨੂੰ ਲੈਂਡਿੰਗ ਐਂਕਰ ਕਰਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੀ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਹੈਲਪਰ ਹਨ (ਉਦਾਹਰਨ: buildUser() ਜਾਂ makeRequest()), ਉਹਨਾਂ ਸਨਿੱਪੇਟਾਂ ਨੂੰ ਵੀ ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਕਿ ਜਨਰੇਟ ਕੀਤੇ ਟੈਸਟ ਉਨ੍ਹਾਂ ਨੂੰ ਮੁੜ-ਵਰਤਣ ਕਰਨ ਅਤੇ ਖੁਦ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਬਜਾਏ ਉਪਯੋਗ ਕਰਨ।
ਇਹ ਸਪਸ਼ਟ ਕਰੋ ਕਿ "ਚੰਗਾ" ਕੀ ਹੈ:
ਇੱਕ ਉਪਯੋਗੀ ਪ੍ਰਾਂਪਟ ਲਾਈਨ: “ਹਰੇਕ ਟੈਸਟ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਕਾਰੋਬਾਰੀ ਵਿਹਾਰ ਬਾਰੇ assertion ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (ਸਿਰਫ 'ਕੋਈ exception ਨਹੀਂ ਆਇਆ' ਨਹੀਂ)।”
ਜ਼ਿਆਦਾਤਰ AI-ਜਨਰੇਟ ਕੀਤੀ ਸੁੱਟੀ "ਹੈਪੀ ਪਾਥ" ਵੱਲ ਝੁਕਦੀ ਹੈ। ਇਸ ਦਾ ਬਿਰੋਧ ਕਰਨ ਲਈ ਮੰਗੋ:
Generate unit tests for <function/module>.
Standards: <language>, <framework>, name tests like <pattern>, place in <path>.
Use these existing patterns: <paste 1 short test example>.
Coverage requirements:
- Happy path
- Boundary cases
- Negative/error cases
Assertions must verify business behavior (outputs, state changes, side effects).
Return only the test file content.
(ਕੋਡ ਫੈਂਸਾਂ ਅੰਦਰ ਦਰਸਾਇਆ ਸਮੱਗਰੀ ਬਦਲੀ ਨਹੀਂ ਜਾਵੇਗੀ।)
AI ਤੇਜ਼ੀ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਟੈਸਟ ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਫੈਸਲਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਉਹ ਟੈਸਟ ਤੁਹਾਡੇ "ਇਰਾਦੇ" ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਨਹੀਂ। ਮਨੁੱਖੀ ਪਾਸ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ "ਚੱਲਣ ਵਾਲੇ" ਟੈਸਟਾਂ ਨੂੰ "ਸਾਡੇ ਲਈ ਸੁਰੱਖਿਆ" ਬਣਾਉਂਦਾ ਹੈ। ਮਕਸਦ ਸ਼ੈਲੀ ਨੂੰ ਨਕਾਟਣਾ ਨਹੀਂ—ਇਹ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਹੈ ਕਿ ਟੈਸਟ ਸੂਟ ਮੈਨਟੇਨਬਲ ਟੈਕਸ ਬਣਨ ਬਿਨਾਂ ਅਰਥਪੂਰਣ ਰਿਗਰੈਸ਼ਨਾਂ ਨੂੰ ਫੜੇਗਾ।
ਦੋ ਸਵਾਲ ਪਹਿਲਾਂ ਪੁੱਛੋ:
ਜਨਰੇਟ ਕੀਤੇ ਟੈਸਟ ਕਈ ਵਾਰੀ ਅਕਸਮਾਤਿਕ ਵਿਵਹਾਰ (ਮੌਜੂਦਾ ਇਮਪਲਮੈਂਟੇਸ਼ਨ ਵੇਰਿਆਂ) ਨੂੰ ਲਾਕ ਕਰ ਲੈਂਦੇ ਹਨ। ਜੇ ਇੱਕ ਟੈਸਟ ਕੋਡ ਦੀ ਨਕਲ ਵਾਂਗ ਪੜ੍ਹਦਾ ਹੈ ਨਾ ਕਿ ਉਮੀਦ ਕੀਤੀ ਨਤੀਜੇ ਦੀ ਵਿਆਖਿਆ, ਤਾਂ ਉਸਨੂੰ ਉੱਚ-ਸਤਹ assertions ਵੱਲ ਧਕੋ।
ਫਲੇਕੀ ਜਾਂ ਨਾਜੁਕ ਟੈਸਟ ਆਮ ਸਤਰਾਂ ਤੇ ਆਉਂਦੇ ਹਨ: ਓਵਰ-ਮੌਕਿੰਗ, ਹਾਰਡ-ਕੋਡਡ ਸਮਾਂ, ਰੈਂਡਮ ਵੈਲਿਊਜ਼। ਡਿਟਰਮੀਨਿਸਟਿਕ ਇਨਪੁੱਟ ਅਤੇ ਸਥਿਰ assertions ਨੂੰ ਤਰਜੀਹ ਦਿਓ (ਉਦਾਹਰਨ ਲਈ, parsed date ਜਾਂ ਇੱਕ ਰੇਂਜ 'ਤੇ assertion ਕਰੋ ਨਾ ਕਿ raw Date.now() ਸਟਰਿੰਗ)। ਜੇ ਇੱਕ ਟੈਸਟ ਪਾਸ ਹੋਣ ਲਈ ਬੇਸ਼ੱਕ ਜ਼ਿਆਦਾ ਮੌਕਿੰਗ ਮੰਗਦਾ ਹੈ, ਤਾਂ ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਵਾਇਰਨਿੰਗ ਨਾ ਕਰਦਾ, ਬਲਕਿ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵਾਇਰਿੰਗ ਨੂੰ ਟੈਸਟ ਕਰ ਰਿਹਾ ਹੈ।
ਇੱਕ "ਪਾਸ" ਟੈਸਟ ਫਿਰ ਵੀ ਬੇਕਾਰ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਉਹ ਫੇਲ ਹੋਣ 'ਤੇ ਵੀ feature ਟੁੱਟਣ 'ਤੇ ਪਾਸ ਹੋਵੇ (false positive)। ਕਮਜ਼ੋਰ assertions ਜਿਵੇਂ "throws ਨਹੀਂ" ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਫੰਕਸ਼ਨ ਦੇ ਕਾਲ ਹੋਣ ਦੀ ਜਾਂਚ ਦੇਖੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰੋ ਉੱਤੇ ਆਉਟਪੁੱਟ, ਸਟੇਟ ਬਦਲਾਅ, ਵਾਪਸ ਕੀਤੇ ਗਲਤੀਆਂ, ਜਾਂ ਪERSIST ਕੀਤੇ ਡੇਟਾ ਦੀ assertions ਰਾਹੀਂ।
ਇੱਕ ਸਧਾਰਨ ਚੈਕਲਿਸਟ ਸਮੀਖਿਆ ਨੂੰ ਸਥਿਰ ਰੱਖਦੀ ਹੈ:
ਜਨਰੇਟ ਕੀਤੇ ਟੈਸਟ ਨੂੰ ਵੀ ਕਿਸੇ ਹੋਰ ਕੋਡ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ: ਸਿਰਫ ਉਹੀ ਚੀਜ਼ ਮਰਜ ਕਰੋ ਜੋ ਤੁਸੀਂ ਛੇ ਮਹੀਨੇ ਵਿੱਚ ਵੀ ਮਾਲਿਕ ਹੋਣ ਲਈ ਤਿਆਰ ਹੋਵੋਗੇ।
AI ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੋਡ ਲਿਖਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਅਸਲ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਕੋਡ ਸਮੇਂ ਦੇ ਨਾਲ ਸਹੀ ਰਹੇ। ਗੁਣਵੱਤਾ "ਲਾਕ ਇਨ" ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਸਰਲ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਹਰ ਬਦਲਾਅ 'ਤੇ ਟੈਸਟ ਅਤੇ ਚੈਕ ਆਟੋਮੈਟਿਕ ਚਲਣ—ਤਾਂ ਜੋ ਰਿਗਰੈਸ਼ਨ ਲਿਜ਼ਰ ਤੋਂ ਪਹਿਲਾਂ ਫੜੀ ਜਾਵੇ।
ਕਈ ਟੀਮਾਂ ਇਹ ਹਲਕਾ ਵਰਕਫਲੋ ਅਪਨਾਉਂਦੀਆਂ ਹਨ:
ਆਖਰੀ ਕਦਮ ਮਹੱਤਵਪੂਰਨ ਹੈ: AI-ਲਿਖੀ ਲੌਜਿਕ ਬਿਨਾਂ ਸਬੰਧਤ ਟੈਸਟ ਦੇ ਅਕਸਰ ਡ੍ਰਿਫਟ ਕਰ ਜਾਂਦੀ ਹੈ। ਟੈਸਟਾਂ ਨਾਲ, ਤੁਸੀਂ ਇਰਾਦੇ ਨੂੰ ਰਿਕਾਰਡ ਕਰ ਰਹੇ ਹੋ ਇੱਕ ਐਸੇ ਢੰਗ ਵਿੱਚ ਜਿਹੜਾ CI ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ।
ਆਪਣੀ CI ਪਾਈਪਲਾਈਨ ਨੂੰ ਹਰ ਪُل ਰਿਕਵੇਸਟ 'ਤੇ (ਅਤੇ ਸੰਭਵ ਤੌਰ 'ਤੇ main 'ਤੇ ਮਰਜ ਉੱਤੇ) ਚਲਾਉਣ ਲਈ ਕਨਫਿਗਰ ਕਰੋ। ਘੱਟੋ-ਘੱਟ, ਇਹਨੂੰ ਚਾਹੀਦਾ ਹੈ:
ਇਸ ਨਾਲ “ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਿਆ” ਸੀਨਾਰਿਓ ਰੁਕਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਕਿਸੇ ਸਾਥੀ (ਜਾਂ ਬਾਅਦ ਵਿੱਚ AI ਪ੍ਰਾਂਪਟ) ਨੇ ਕੋਡ ਬਦਲਿਆ ਤਾਂ ਦੂਜੇ ਪਾਸੇ ਦੀ ਭੁੱਲ ਫੜੀ ਜਾਂਦੀ ਹੈ।
ਟੈਸਟ ਜ਼ਰੂਰੀ ਹਨ, ਪਰ ਉਹ ਸਾਰਾ ਕੁਝ ਨਹੀਂ ਫੜਦੇ। ਛੋਟੇ, ਤੇਜ਼ ਗੇਟ ਜੋ ਟੈਸਟ ਜਨਰੇਸ਼ਨ ਨੂੰ ਪੂਰਕ ਬਣਾਉਂਦੇ:
ਇਹ ਚੈੱਕ ਤੇਜ਼ ਰੱਖੋ—ਜੇ CI ਧੀਮਾ ਜਾਂ ਸ਼ੋਰ ਕਰਦਾ ਹੈ, ਲੋਕ ਉਨ੍ਹਾਂ ਨੂੰ ਗੋਲ ਕਰਨ ਦੇ ਤਰੀਕੇ ਲੱਭ ਲੈਂਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਟੈਸਟ ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ ਅਤੇ CI ਚਲਾਅ ਵਧਾ ਰਹੇ ਹੋ, ਆਪਣੀ ਬਜਟ ਅਤੇ ਸਮਰੱਥਾ ਨੂੰ ਅਣਗੌਰ ਕਰੋ। ਜੇ ਤੁਸੀਂ CI ਮਿੰਟ ਟਰੈਕ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਵਿੱਤੀ ਸੀਮਾਵਾਂ ਅਤੇ ਵਰਕਰ ਵਿਕਲਪਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਯੋਗ ਹੈ (ਦੇਖੋ /pricing)।
ਇੱਕ ਹੈਰਾਨ ਕਰਨ ਵਾਲੀ ਤਰੀਕ ਇਹ ਹੈ ਕਿ AI-ਲਿਖੇ ਕੋਡ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹੋਏ ਫੇਲ ਟੈਸਟਾਂ ਨੂੰ ਤੁਹਾਡਾ "ਅਗਲਾ ਪ੍ਰਾਂਪਟ" ਮੰਨੋ। ਵਿਅੰਗਾਤਮਕ ਤੌਰ 'ਤੇ ਤੁਹਾਡਾ ਪ੍ਰਾਂਪਟ ਜਦੋਂ ਫੇਲ ਟੈਸਟ ਦੀ ਨੀਮ ਤੇ ਆਧਾਰਿਤ ਹੁੰਦਾ ਹੈ, ਤਦ ਇਸ ਨਾਲ ਬਹਿਸ ਘੱਟ ਹੁੰਦੀ ਹੈ।
ਬਦਲੇ ਵਿੱਚ:
ਵਰਤੋ:
shouldRejectExpiredToken. Here's the failure output and relevant code. Update the implementation so this test passes without changing the public API. If needed, add a regression test that captures the bug."ਫੇਲ ਟੈਸਟ ਅਣਇਧਾਰ ਚੋਣ ਖਤਮ ਕਰ ਦਿੰਦੇ ਹਨ। ਉਹ ਐਗਜ਼ੀਕਿuble ਰੂਪ 'ਚ "ਸਹੀ" ਕੀ ਹੈ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਗੱਲਬਾਤ ਵਿੱਚ ਝਗੜਾ ਨਹੀਂ ਕਰ ਰਹੇ। ਇਹ ਵੀ ਸਹਾਇਕ ਹੈ ਕਿ ਹਰ ਪ੍ਰਾਂਪਟ ਇੱਕ ਨਾਪ ਕੇ ਦਿਓ: ਇੱਕ ਨਾਪੇ-ਜਾਣ ਵਾਲੇ ਨਤੀਜੇ ਲਈ। ਇਸ ਨਾਲ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ ਅਤੇ ਪਤਾ ਲੱਗਦਾ ਹੈ ਜਦੋਂ AI ਨੇ "ਰੋਗ" ਠੀਕ ਕੀਤਾ ਪਰ ਕਿਸੇ ਹੋਰ ਨੂੰ ਤੋੜ ਦਿੱਤਾ।
ਇਹ ਉਹੀ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਏਜੰਟ-ਸ਼ੈਲੀ ਵਰਕਫਲੋ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੀ ਹੈ: ਇੱਕ ਏਜੰਟ ਨਿਊਨਤਮ ਕੋਡ ਬਦਲਾਅ 'ਤੇ ਧਿਆਨ ਦੇਵੇ, ਦੂਜਾ ਛੋਟਾ ਟੈਸਟ ਸੁਧਾਰ ਸੁਝਾਵੇ, ਅਤੇ ਤੁਸੀਂ diff ਦੀ ਸਮੀਖਿਆ ਕਰੋ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਇਸ ਕਿਸਮ ਦੇ ਇੱਟਰੇਟਿਵ, ਚੈਟ-ਪਹਿਲੇ ਵਿਕਾਸ ਵਰਕਫਲੋ 'ਤੇ ਬਣੇ ਹਨ—ਜੋ “ਟੈਸਟਾਂ ਨੂੰ ਅਗਲੇ ਪ੍ਰਾਂਪਟ” ਬਣਾਉਂਦੇ ਹਨ।
ਆਟੋ-ਜਨਰੇਟ ਟੈਸਟ ਤੁਹਾਡੇ ਟੈਸਟ ਸੂਟ ਨੂੰ ਇੱਕ ਰਾਤ ਵਿਚ ਵੱਡਾ ਕਰ ਸਕਦੇ ਹਨ—ਪਰ "ਵੱਡਾ" ਹੀ "ਵਧੀਆ" ਨਹੀਂ। ਮਕਸਦ ਭਰੋਸਾ ਹੈ: ਰਿਗਰੈਸ਼ਨ ਜਲਦੀ ਫੜਨਾ, ਪ੍ਰੋਡਕਸ਼ਨ ਤਰੁਟੀਆਂ ਘਟਾਉਣਾ, ਅਤੇ ਟੀਮ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣਾ।
ਉਹ ਸਿਗਨਲ ਚੁਣੋ ਜੋ ਨਤੀਜਿਆਂ ਨਾਲ ਜੁੜੇ ਹਨ:
ਕਵਰੇਜ ਇਕ ਵਧੀਆ smoke alarm ਹੋ ਸਕਦਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਅਣਟੈਸਟ ਕੀਤੇ ਮਾਹਰ ਰਾਹਾਂ ਨੂੰ ਲੱਭਣ ਲਈ—ਪਰ ਇਸ ਨੂੰ ਗੇਮ ਨਹੀਂ ਬਣਾਓ। ਜਨਰੇਟ ਟੈਸਟ ਕਵਰੇਜ ਨੂੰ ਵਧਾ ਸਕਦੇ ਹਨ ਪਰ assertions ਘੱਟ ਹੋ ਸਕਦੇ ਹਨ। ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ:
ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਟੈਸਟ ਗਿਣਤੀ ਜਾਂ ਕਵਰੇਜ਼ ਟੈਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਵਾਲੀਅਮ ਲਈ optimize ਕਰੋਗੇ। ਟਰੈਕ ਕਰੋ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਫੜੇ ਗਏ ਡਿਫੈਕਟ: CI, QA, ਜਾਂ ਸਟੇਜਿੰਗ ਵਿੱਚ ਮਿਲੇ ਬੱਗ ਜੋ ਯੂਜ਼ਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੇ। ਜਦੋਂ ਆਟੋ-ਜਨਰੇਟ ਟੈਸਟ ਕੰਮ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ, ਇਹ ਗਿਣਤੀ ਵਧੇਗੀ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਇੰਸੀਡੈਂਟ ਘਟਣਗੇ।
ਜਨਰੇਟ ਕੀਤੇ ਸੂਟ ਨੂੰ ਮੁਰੰਮਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਰਿਕਰਿੰਗ ਟਾਸਕ ਰੱਖੋ:
ਸਫਲਤਾ ਇੱਕ ਸ਼ਾਂਤ CI, ਤੇਜ਼ ਫੀਡਬੈਕ, ਅਤੇ ਘਟੇ ਹੋਏ ਆਚਾਨਕੀ ਨਤੀਜਿਆਂ ਨਾਲ ਨਾਪੋ—ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਡੈਸ਼ਬੋਰਡ।
ਆਟੋ-ਜਨਰੇਟ ਟੈਸਟ ਤੇਜ਼ੀ ਨਾਲ ਗੁਣਵੱਤਾ ਵਧਾ ਸਕਦੇ ਹਨ—ਪਰ ਸਿਰਫ਼ ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਸਹਾਇਕ ਸਮਝੋ, ਨਾ ਕਿ ਅਥਾਰਟੀ। ਸਭ ਤੋਂ ਵੱਡੇ ਨਾਕਾਮੀਆਂ ਇੱਕੋ ਜਿਹੇ ਹੁੰਦੇ ਹਨ across teams ਅਤੇ ਉਹ ਟਾਲੇ ਜਾ ਸਕਦੇ ਹਨ।
ਓਵਰ-ਰਿਲਾਇੰਸ ਸਭ ਤੋਂ ਆਮ ਫ਼ੰਦ ਹੈ: ਜਨਰੇਟ ਟੈਸਟ ਇੱਕ ਸੁਰੱਖਿਆ ਦੀ ਭ੍ਰਮ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ ਜੇ ਲੋਕ ਸੋਚਣਾ ਛੱਡ ਦਿੰਦੇ ਹਨ ("ਟੂਲ ਨੇ ਟੈਸਟ ਲਿਖ ਦਿੱਤੇ, ਸਾਨੂੰ ਕਵਰੇਡ ਹੈ"), ਤਾਂ ਤੁਸੀਂ ਗੱਲਤੀਆਂ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜੋਗੇ—ਸਿਰਫ਼ ਵੱਧ ਗ्रीन ਚੈੱਕਮਾਰਕਸ ਨਾਲ।
ਇੱਕ ਹੋਰ ਆਮ ਮੁੱਦਾ implementation details ਦੀ ਟੈਸਟਿੰਗ ਹੈ ਨਾ ਕਿ ਵਿਹਾਰ ਦੀ। AI ਟੂਲ ਅਕਸਰ ਮੌਜੂਦਾ ਮੇਥਡ ਨਾਮ, ਅੰਦਰੂਨੀ ਹੈਲਪਰ, ਜਾਂ ਸਹੀ ਐਰਰ ਸੁਨੇਹਿਆਂ 'ਤੇ ਟਿਕ ਜਾਂਦੇ ਹਨ। ਉਹ ਟੈਸਟ brittle ਬਣ ਜਾਂਦੇ ਹਨ: ਰਿਫੈਕਟਰ ਉਹਨਾਂ ਨੂੰ ਤੋੜ ਦੇਂਦਾ ਹੈ ਜਦੋਂ ਕਿ feature ਅਜੇ ਵੀ ਠੀਕ ਕੰਮ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਐਸਾ ਕਰੋ ਕਿ ਟੈਸਟ ਬਿਆਨ ਕਰੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਵੇਂ ਨਹੀਂ।
ਟੈਸਟ ਜਨਰੇਸ਼ਨ ਅਕਸਰ ਕੋਡ, ਸਟੈਕ ਟਰੇਸ, ਲੌਗ, ਜਾਂ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਪੇਸਟ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਗੁਪਤ ਚੀਜ਼ਾਂ (API ਕੁੰਜੀਆਂ), ਗਾਹਕ ਡੇਟਾ, ਜਾਂ ਮਲਕੀਅਤ ਲਾਜਿਕ ਲੀਕ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਪ੍ਰਾਂਪਟ ਅਤੇ ਟੈਸਟ ਫਿਕਸਚਰਾਂ ਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਤੋਂ ਮੁਕਤ ਰੱਖੋ:
ਜੇ ਤੁਸੀਂ ਹੋਸਟਡ AI ਡਿਵ ਪਲੇਟਫਾਰਮ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਵੀ ਇਹ ਹੀ ਅਨੁਸ਼ਾਸਨ ਲਾਗੂ ਕਰੋ। ਭਾਵੇਂ ਪਲੇਟਫਾਰਮ ਆਧੁਨਿਕ ਤਰਕੀਬਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੋਵੇ, ਤੁਹਾਡੇ ਪ੍ਰਾਂਪਟ ਅਤੇ ਫਿਕਸਚਰਾਂ ਨੂੰ ਤੁਹਾਡੇ ਸੁਰੱਖਿਆ ਦ੍ਰਿਸ਼ਟਿਕੋਣ ਦਾ ਹਿੱਸਾ ਮੰਨੋ।
ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ routine ਬਣਾਓ:
ਮਕਸਦ ਵੱਧ ਤੋਂ ਵੱਧ ਟੈਸਟ ਨਹੀਂ—ਇੱਕ ਭਰੋਸੇਯੋਗ ਫੀਡਬੈਕ ਜੋ AI-ਲਿਖੀ ਲੌਜਿਕ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖੇ।
ਕਿਉਂਕਿ AI ਤੇਜ਼ੀ ਨਾਲ ਐਪਲਿਕੇਸ਼ਨ ਲੌਜਿਕ ਵਿੱਚ ਸੁਧਾਰ ਲਿਆ ਸਕਦਾ ਹੈ, ਇਹ ਗਲਤ ਫਰਜ਼ਾਂ ਅਤੇ ਨਾਜੁਕ ਰਿਗਰੈਸ਼ਨਾਂ ਨੂੰ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਲਿਆ ਸਕਦਾ ਹੈ। ਜਨਰੇਟ ਕੀਤੇ ਟੈਸਟ ਤੇਜ਼, ਐਗਜ਼ੀਕਿuble (ਕ੍ਰਿਆਸ਼ੀਲ) ਤਰੀਕੇ ਨਾਲ ਮਨਜ਼ੂਰ ਕੀਤੀ ਹੋਈ ਵਿਵਹਾਰ ਨੂੰ ਬੰਦ ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ ਭਵਿੱਖ ਵਿੱਚ ਹੋਣ ਵਾਲੇ ਬਦਲਾਅ (ਮਨੁੱਖੀ ਜਾਂ AI ਦੁਆਰਾ) ਨੂੰ ਤੁਰੰਤ ਫੀਡਬੈਕ ਮਿਲੇ।
ਨਹੀਂ। ਇੱਕ ਜਨਰੇਟ ਕੀਤਾ ਟੈਸਟ ਗਲਤੀ ਨਾਲ ਮੌਜੂਦਾ ਵਿਵਹਾਰ ਨੂੰ “ਬਰਕਰਾਰ” ਕਰ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਉਹ ਵਿਵਹਾਰ ਗਲਤ ਹੋਵੇ, ਜਾਂ ਇਹ ਉਹ ਬਿਜ਼ਨਸ ਨਿਯਮ ਛੱਡ ਸਕਦਾ ਹੈ ਜੋ ਕੋਡ ਵਿੱਚ ਸਪਸ਼ਟ ਨਹੀਂ ਹਨ। ਜਨਰੇਟ ਕੀਤੇ ਟੈਸਟਾਂ ਨੂੰ ਡਰਾਫਟ ਸਮਝੋ ਅਤੇ ਨਾਮ, ਸੈੱਟਅਪ ਅਤੇ assertions ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਤਾ ਕਿ ਇਹ ਪ੍ਰੋਡਕਟ ਦੇ ਮਨੋਰਥ ਨੂੰ ਦਰਸਾਉਣ।
ਉਸ ਵੇਲੇ ਵਰਤੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਨਵੀਂ ਜਾਂ ਬਦਲੀ ਹੋਈ ਲੌਜਿਕ ਆਲੇ-ਦੁਆਲੇ ਤੇਜ਼, ਗਠਿਤ ਕਵਰੇਜ ਚਾਹੀਦੀ ਹੋਵੇ—ਖ਼ਾਸ ਕਰਕੇ AI-ਸਹਾਇਤ ਰਿਫੈਕਟਰਾਂ ਤੋਂ ਬਾਅਦ। ਇਹ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ:
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਘੱਟ-ਲਾਗਤ ਤੇ ਸਭ ਤੋਂ ਵੱਧ ਸਿਗਨਲ ਲੇਅਰ: ਯੂਨਿਟ ਟੈਸਟਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ।
ਵਿਹਾਰ-ਕੇਂਦਰਿਤ ਟੈਸਟ ਜੋ “ਸਹੀ ਕਾਰਨ” ਲਈ fail ਹੋਣਗੇ। ਕਮਜ਼ੋਰ ਚੈੱਕ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰੋ:
ਆਮ ਸੋਤਰਾਂ ਵਿੱਚ ਓਵਰ-ਮੌਕਿੰਗ, ਹਾਰਡ‑ਕੋਡਡ ਟਾਈਮਸਟੈਂਪ, ਰੈਂਡਮ ਡੇਟਾ ਅਤੇ ਅੰਦਰੂਨੀ ਮੇਥਡ ਕਾਲਾਂ 'ਤੇ assertions ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ। ਨਿਰਧਾਰਤ ਇਨਪੁੱਟ ਤੇ ਸਥਿਰ assertions ਵਰਤੋ ਅਤੇ ਲੋਕ-ਸਰਵਜਨੀਕ ਵਿਹਾਰ ਨੂੰ ਟੈਸਟ ਕਰੋ ਤਾਂ ਕਿ ਸਧਾਰਨ ਰਿਫੈਕਟਰ ਵੀ ਸੁਟੇ ਨਾਂ ਫੇਲ ਹੋਣ।
ਇੱਕ ਤੰਗ ਲੂਪ ਵਰਤੋਂ:
ਇਸ ਤਰ੍ਹਾਂ “ਪੂਰਾ ਹੋਇਆ” ਟੈਸਟਯੋਗ ਉਮੀਦਾਂ ਨਾਲ ਜੋੜਿਆ ਰਹਿੰਦਾ ਹੈ, ਸਿਰਫ਼ ਮੈਨੂਅਲ ਚੈੱਕਾਂ ਨਾਲ ਨਹੀਂ।
ਸੀਮਾਵਾਂ ਅਤੇ ਅਸਲ ਰਿਪੋ ਸੰਦਰਭ ਸ਼ਾਮਲ ਕਰੋ:
ਇਸ ਨਾਲ ਜਨਰੇਟ ਕੀਤੇ ਨਮੂਨੇ ਤੇਜ਼ੀ ਨਾਲ ਰਿਵਿਊਯੋਗ ਅਤੇ ਵਰਤਣਯੋਗ ਬਣਦੇ ਹਨ।
ਟੈਸਟ ਜਨਰੇਸ਼ਨ ਵਿੱਚ ਅਕਸਰ ਕੋਡ, ਲੌਗ ਜਾਂ ਸਟੈਕ ਟਰੇਸ ਪੇਸਟ ਕਰਨ ਨਾਲ ਖ਼ਤਰਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਚੀਜ਼ਾਂ ਲੀਕ ਹੋ ਸਕਦੀਆਂ ਹਨ:
ਸੋ, ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਗੁਪਤ ਜਾਣਕਾਰੀ ਨਾ ਸ਼ਾਮਲ ਕਰੋ: ਸਿੰਥੇਟਿਕ ਫਿਕਸਚਰ ਵਰਤੋ, ਤਿਆਰ ਕਰਨ ਸਮੇਂ ਬਹੁਤ ਸਖਤ ਰੀਡੈਕਸ਼ਨ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਸਾਂਝਾ ਕਰੋ।
ਵਾਸਤਵਿਕ ਨਤੀਜੇ ਜੋ ਭਰੋਸਾ ਦਰਸਾਉਂਦੇ ਹਨ, ਉਨਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ, ਨਾ ਕਿ ਸਿਰਫ਼ ਟੈਸਟ ਗਿਣਤੀ:
ਕਵਰੇਜ ਨੂੰ ਇੱਕ ਸੂਚਕ ਸਮਝੋ, ਨਾ ਕਿ ਅੰਤਿਮ ਮਾਪਦੰਡ; ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਘੱਟ-ਸਿਗਨਲ ਟੈਸਟ ਹਟਾਉ।