Cypress ਨੇ tap ਨਾਮ ਦਾ ਇੱਕ ਬੀਟਾ ਫੀਚਰ ਰਿਲੀਜ਼ ਕੀਤਾ ਹੈ ਜੋ AI-ਡਰਾਈਵਨ ਕੋਡਿੰਗ ਏਜੰਟਾਂ ਨੂੰ ਲਾਈਵ Cypress ਟੈਸਟ ਸੈਸ਼ਨ ਨਾਲ ਜੁੜਨ, DOM ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਕਮਾਂਡ ਲੌਗ ਪ੍ਰਾਪਤ ਕਰਨ, ਅਤੇ ਅਸਫਲਤਾਵਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਉਸ ਵਿਜ਼ੂਅਲ ਜਾਣਕਾਰੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਹ ਟੂਲ ਸਿਰਫ਼ Cypress 15.21.0 ਜਾਂ ਨਵੇਂ, Chromium-ਅਧਾਰਤ ਬ੍ਰਾਊਜ਼ਰ, ਅਤੇ “cypress open” UI ਦੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ; ਇਹ headless ਮੋਡ ਵਿੱਚ ਨਹੀਂ ਚੱਲਦਾ।
AI ਏਜੰਟਾਂ ਨੂੰ exit code ਤੋਂ ਵੱਧ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ
ਜ਼ਿਆਦਾਤਰ AI ਕੋਡਿੰਗ ਸਹਾਇਕ (assistants) Cypress ਰਨ ਨੂੰ ਕਿਸੇ ਹੋਰ ਕਮਾਂਡ-ਲਾਈਨ ਟੂਲ ਵਾਂਗ ਮੰਨਦੇ ਹਨ: ਉਹ npx cypress run ਚਲਾਉਂਦੇ ਹਨ, ਪ੍ਰੋਸੈਸ ਦੇ exit status ਨੂੰ ਪੜ੍ਹਦੇ ਹਨ, ਅਤੇ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਟੈਸਟ ਪਾਸ ਹੋਇਆ ਜਾਂ ਨਹੀਂ। ਇੱਕ exit code ਏਜੰਟ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੁਝ ਗਲਤ ਹੋਇਆ ਹੈ, ਪਰ ਇਹ ਕੋਈ ਇਸ਼ਾਰਾ ਨਹੀਂ ਦਿੰਦਾ ਕਿ ਕੀ ਕੋਈ selector ਗਲਤ ਟਾਈਪ ਹੋ ਗਿਆ ਸੀ, ਕੋਈ ਪੇਜ ਲੋਡ ਹੋਣ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ ਸੀ, ਜਾਂ ਕਿਸੇ overlay ਨੇ ਬਟਨ ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਸੀ। ਇਸਦੇ ਉਲਟ, ਇਨਸਾਨ Cypress UI ਖੋਲ੍ਹਦੇ ਹਨ, ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਦੇਖਦੇ ਹਨ, DOM tree ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕਮਾਂਡ ਲੌਗ ਪੜ੍ਹਦੇ ਹਨ।
ਉਹ ਖਾਲੀਪਣ (gap) ਆਟੋਮੇਟਡ ਡੀਬੱਗਿੰਗ ਨੂੰ ਅਸਥਿਰ ਬਣਾਉਂਦਾ ਹੈ। “Element not found” ਦੇ ਦਰਜਨਾਂ ਮੂਲ ਕਾਰਨ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਵਿਜ਼ੂਅਲ ਸਬੂਤ ਤੋਂ ਬਿਨਾਂ ਇੱਕ AI ਉਹੀ ਫਿਕਸ (fix) ਵਾਰ-ਵਾਰ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਉਹ ਲਗਾਤਾਰ ਲੂਪ ਵਿੱਚ ਫਸ ਸਕਦਾ ਹੈ।
tap ਇਸ ਖਾਲੀਪਣ ਨੂੰ ਕਿਵੇਂ ਭਰਦਾ ਹੈ
Tap ਚੱਲ ਰਹੇ Cypress instance ਲਈ ਇੱਕ terminal-ਅਧਾਰਤ ਇੰਟਰਫੇਸ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਡਿਵੈਲਪਰ Cypress ਨੂੰ open mode ਵਿੱਚ ਲਾਂਚ ਕਰਦਾ ਹੈ:
npx cypress open --e2e --browser=chrome
ਏਜੰਟ ਇੱਕ ਵੱਖਰੇ shell ਤੋਂ JSON-output ਕਮਾਂਡਾਂ ਦੀ ਇੱਕ ਲੜੀ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ:
npx cypress tap specs --json– ਉਪਲਬਧ spec ਫਾਈਲਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ।npx cypress tap run <spec> --json– ਇੱਕ ਸਿੰਗਲ spec ਰਨ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।npx cypress tap status --json– timestamps ਸਮੇਤ ਮੌਜੂਦਾ ਰਨ ਦਾ ਸਟੇਟਸ ਦੱਸਦਾ ਹੈ।
ਕਿਉਂਕਿ status payload ਵਿੱਚ ਇੱਕ startedAt timestamp ਹੁੰਦਾ ਹੈ, ਏਜੰਟ ਇਹ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਪੁਰਾਣੇ ਰਨ ਦੀ ਬਜਾਏ ਤਾਜ਼ਾ ਨਤੀਜਿਆਂ ਨੂੰ ਦੇਖ ਰਿਹਾ ਹੈ। ਸਿਰਫ਼ raw exit code 'ਤੇ ਨਿਰਭਰ ਰਹਿਣਾ ਹੁਣ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ।
ਜਦੋਂ ਕੋਈ ਟੈਸਟ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਏਜੰਟ ਹੋਰ ਡੂੰਘਾਈ ਨਾਲ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ:
npx cypress tap reporter --json– ਸਮੁੱਚੀ ਟੈਸਟ ਰਿਪੋਰਟ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।npx cypress tap command --test-id <ID> --command-id <ID> --json– ਉਸ ਸਹੀ ਕਮਾਂਡ ਨੂੰ ਕੱਢਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਗਲਤੀ ਆਈ ਸੀ, ਨਾਲ ਹੀ ਉਸ ਸਮੇਂ ਐਪ ਦੇ DOM, ARIA tree ਅਤੇ ਕਿਸੇ ਵੀ ਸਬੰਧਤ element attributes ਦਾ ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।
ਉਸ ਸਨੈਪਸ਼ਾਟ ਦੀ ਮਦਦ ਨਾਲ, AI ਇਹ ਸਮਝ ਸਕਦਾ ਹੈ ਕਿ selector ਕਿਉਂ ਫੇਲ ਹੋਇਆ, ਕੀ ਪੇਜ ਅਜੇ ਵੀ ਲੋਡ ਹੋ ਰਿਹਾ ਸੀ, ਜਾਂ ਕੀ ਕਿਸੇ modal ਨੇ ਟਾਰਗੇਟ ਨੂੰ ਢੱਕ ਦਿੱਤਾ ਸੀ। ਫਿਰ ਇਹ ਕੋਡ ਵਿੱਚ ਬਦਲਾਅ ਦਾ ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹੈ, ਉਸਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਕਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਉਸੇ spec ਨੂੰ ਦੁਬਾਰਾ ਚਲਾ ਸਕਦਾ ਹੈ।
ਖੁਦਮੁਖਤਿਆਰ (autonomous) ਏਜੰਟਾਂ ਲਈ ਇੱਕ ਸੁਰੱਖਿਆ ਨੀਤੀ
ਲੂਪ ਨੂੰ ਹਮੇਸ਼ਾ ਲਈ ਚੱਲਣ ਤੋਂ ਰੋਕਣ ਲਈ, Cypress ਟੀਮ ਇੱਕ ਅਨੁਸ਼ਾਸਿਤ ਵਰਕਫਲੋ (workflow) ਦਾ ਸੁਝਾਅ ਦਿੰਦੀ ਹੈ:
- ਸਿਰਫ਼ ਇੱਕ ਖਾਸ spec ਫਾਈਲ ਚਲਾਓ।
- ਇੱਕ ਸਖ਼ਤ ਸਮੇਂ ਸੀਮਾ (deadline) ਦੇ ਨਾਲ
tap statusਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਨਤੀਜੇ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ ਜਿਸਦਾstartedAtਪਿਛਲੀ ਜਾਂਚ ਨਾਲੋਂ ਪੁਰਾਣਾ ਹੋਵੇ। - ਸਿਰਫ਼ ਫੇਲ ਹੋਣ ਵਾਲੇ ਟੈਸਟ ਅਤੇ ਗਲਤ ਕਮਾਂਡ ਦੀ ਜਾਂਚ ਕਰੋ।
- ਅਗਲੇ ਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਿਰਫ਼ ਇੱਕ ਕੋਡ ਸੋਧ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ।
- spec ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਓ।
- ਜੇਕਰ ਨਤੀਜਾ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਰੁਕ ਜਾਓ ਅਤੇ ਸਮੀਖਿਆ ਲਈ ਇਨਸਾਨ ਨੂੰ ਦੱਸੋ।
ਏਜੰਟ ਨੂੰ ਇਸ ਬਾਰੇ ਕੁਦਰਤੀ ਭਾਸ਼ਾ (natural-language) ਵਿੱਚ ਵਿਆਖਿਆ ਵੀ ਤਿਆਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਉਸਨੇ ਕੀ ਦੇਖਿਆ ਅਤੇ ਸੁਝਾਇਆ ਗਿਆ ਫਿਕਸ ਕਿਉਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਟੈਸਟ ਪਾਸ ਹੋਣਾ ਹੀ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ; AI ਨੂੰ ਇਹ ਸਾਬਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਸਨੇ ਵਿਜ਼ੂਅਲ ਸਬੂਤਾਂ ਨੂੰ ਸਮਝ ਲਿਆ ਹੈ।
ਕਿਸ ਨੂੰ ਫਾਇਦਾ ਹੋਵੇਗਾ
ਡਿਵੈਲਪਰ ਜੋ ਪਹਿਲਾਂ ਹੀ ਕੋਡ ਜਨਰੇਸ਼ਨ ਲਈ AI ਸਹਾਇਕਾਂ 'ਤੇ ਨਿਰਭਰ ਹਨ, ਉਹ ਹੁਣ ਉਹਨਾਂ ਸਹਾਇਕਾਂ ਨੂੰ ਡੀਬੱਗਿੰਗ ਲਈ ਵਧੇਰੇ ਸਮਰੱਥਤਾਵਾਂ ਦੇ ਸਕਦੇ ਹਨ। ਇਸਦਾ ਉਮੀਦ ਕੀਤੀ ਫਾਇਦਾ ਫਲੈਕੀ (flaky) ਟੈਸਟਾਂ ਦੇ ਪਿੱਛੇ ਖਰਚੇ ਜਾਣ ਵਾਲੇ ਸਮੇਂ ਵਿੱਚ ਕਮੀ ਹੈ, ਖਾਸ ਕਰਕੇ ਵੱਡੇ end-to-end ਸੂਟਾਂ ਵਿੱਚ ਜਿੱਥੇ ਕਿਸੇ ਅਸਫਲਤਾ ਨੂੰ ਮੈਨੂਅਲੀ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨ ਵਿੱਚ ਮਿੰਟ ਲੱਗ ਸਕਦੇ ਹਨ। ਜੋ ਟੀਮਾਂ tap ਨੂੰ ਅਪਣਾਉਂਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਨੂੰ UI ਕੰਪੋਨੈਂਟਸ ਨਾਲ ਸੰਬੰਧਿਤ pull requests 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਹੋਣ ਦੀ ਉਮੀਦ ਹੈ, ਅਤੇ ਡੀਬੱਗਿੰਗ ਸੈਸ਼ਨਾਂ ਦੀ ਲੋੜ ਵੀ ਘੱਟ ਹੋਵੇਗੀ।
ਜੋਖਮ ਅਤੇ ਸੀਮਾਵਾਂ
Tap ਅਜੇ ਵੀ ਬੀਟਾ ਵਿੱਚ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸ ਵਿੱਚ ਬੱਗ ਹੋ ਸਕਦੇ ਹਨ, ਇਸਦੀ ਕਮਾਂਡ ਸਿੰਟੈਕਸ ਬਦਲ ਸਕਦੀ ਹੈ, ਜਾਂ ਬਿਨਾਂ ਕਿਸੇ ਸੂਚਨਾ ਦੇ ਕੁਝ ਕੌਂਫਿਗਰੇਸ਼ਨਾਂ ਲਈ ਸਪੋਰਟ ਖਤਮ ਹੋ ਸਕਦੀ ਹੈ। ਇਸਦਾ open UI 'ਤੇ ਨਿਰਭਰ ਹੋਣਾ headless CI ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਟੀਮਾਂ ਨੂੰ ਆਟੋਮੇਟਡ ਬਿਲਡਾਂ ਲਈ ਇੱਕ ਵੱਖਰੀ ਰਣਨੀਤੀ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਕਿਉਂਕਿ ਇਹ ਫੀਚਰ ਲਾਈਵ DOM ਡੇਟਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਦਰਸ਼ਨ (performance) 'ਤੇ ਥੋੜ੍ਹਾ ਪ੍ਰਭਾਵ ਪੈ ਸਕਦਾ ਹੈ ਜੋ ਵੱਡੇ spec ਨੂੰ ਹੌਲੀ ਕਰ ਸਕਦਾ ਹੈ। ਅੰਤ ਵਿੱਚ, ਸੁਰੱਖਿਆ ਨੀਤੀ ਇਹ ਮੰਨ ਕੇ ਚੱਲਦੀ ਹੈ ਕਿ AI ਸਮੇਂ ਦੀ ਸੀਮਾ ਦਾ ਪਾਲਣ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇੱਕ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਰੁਕ ਸਕਦਾ ਹੈ; ਇੱਕ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਏਜੰਟ ਅਜੇ
- ਬੀਟਾ ਫੀਡਬੈਕ ਚੱਕਰ – Cypress ਸ਼ਾਇਦ JSON schema ਨੂੰ ਹੋਰ ਬਿਹਤਰ ਬਣਾਏਗਾ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਅਪਣਾਉਣ ਵਾਲਿਆਂ ਦੇ ਇਨਪੁਟ ਦੇ ਅਧਾਰ 'ਤੇ ਵਧੇਰੇ ਵਿਸਤ੍ਰਿਤ ਕਮਾਂਡਾਂ ਜੋੜੇਗਾ।
- CI ਨਾਲ ਇੰਟੀਗ੍ਰੇਸ਼ਨ – ਕਮਿਊਨਿਟੀ ਸਕ੍ਰਿਪਟਾਂ ਦੀ ਉਮੀਦ ਰੱਖੋ ਜੋ tap ਦੀ open-mode ਦੀ ਲੋੜ ਨੂੰ headless runners ਨਾਲ ਜੋੜਨਗੀਆਂ, ਸ਼ਾਇਦ ਇੱਕ ਵਰਚੁਅਲ ਡਿਸਪਲੇਅ ਬਣਾ ਕੇ।
- AI-agent ਟੂਲਿੰਗ – ਕੋਡਿੰਗ ਅਸਿਸਟੈਂਟ ਬਣਾਉਣ ਵਾਲੇ ਵੈਂਡਰ tap ਸਪੋਰਟ ਨੂੰ ਇੱਕ ਡਿਫੌਲਟ ਡੀਬੱਗਿੰਗ ਮੋਡੀਊਲ ਵਜੋਂ ਬੰਡਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਇਹ ਫੀਚਰ ਮੁੱਖਧਾਰਾ IDE extensions ਵਿੱਚ ਵਧੇਰੇ ਦਿਖਾਈ ਦੇਵੇਗਾ।
ਜੇਕਰ ਤੁਸੀਂ AI-driven ਟੈਸਟ ਮੇਨਟੇਨੈਂਸ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਿੰਗਲ flaky spec 'ਤੇ tap ਨੂੰ ਅਜ਼ਮਾ ਕੇ ਦੇਖੋ ਅਤੇ ਦੇਖੋ ਕਿ ਕੀ ਵਿਜ਼ੂਅਲ ਕੰਟੈਕਸਟ ਡੀਬੱਗਿੰਗ ਚੱਕਰ ਨੂੰ ਛੋਟਾ ਕਰਦਾ ਹੈ। ਇਹ ਟੂਲ ਇਨਸਾਨੀ ਫੈਸਲੇ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲਵੇਗਾ, ਪਰ ਇਹ ਤੁਹਾਡੇ ਕੋਡਿੰਗ ਏਜੰਟ ਨੂੰ ਅਜਿਹੀਆਂ ਅੱਖਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਪਹਿਲਾਂ ਕਮੀ ਸੀ।