ਜੇਕਰ ਤੁਹਾਡੇ ਈਮੇਲ ਟੈਸਟ ਤੁਹਾਡੇ ਲੈਪਟਾਪ 'ਤੇ ਬਿਲਕੁਲ ਠੀਕ ਚੱਲਦੇ ਹਨ ਪਰ CI 'ਤੇ ਆਉਂਦੇ ਹੀ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਇਕੱਲੇ ਨਹੀਂ ਹੋ। ਆਮ ਤੌਰ 'ਤੇ ਲੋਕ ਟੈਸਟ ਕੋਡ ਵਿੱਚ sleep ਕਾਲਸ ਪਾ ਦਿੰਦੇ ਹਨ ਜਾਂ ਰੀਟ੍ਰਾਈ (retry) ਕਾਊਂਟ ਵਧਾ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਬਿਲਡ ਪਾਸ ਨਹੀਂ ਹੋ ਜਾਂਦਾ। ਇਹ ਸ਼ਾਇਦ ਇੱਕ ਦਿਨ ਲਈ ਸ਼ੋਰ ਨੂੰ ਘੱਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਬੱਗ (bug) ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਸਿਰਫ਼ ਇਸਨੂੰ ਛੁਪਾਉਂਦਾ ਹੈ।
ਅਸਲ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡਾ ਟੈਸਟ ਇਹ ਕਿਵੇਂ ਪਛਾਣਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਈਮੇਲ ਖੋਲ੍ਹਣੀ ਹੈ।
ਸਾਂਝੇ ਇਨਬਾਕਸ ਦੀ ਸਮੱਸਿਆ (The Shared Inbox Problem)
ਤੁਹਾਡੀ ਲੋਕਲ ਮਸ਼ੀਨ 'ਤੇ, ਤੁਸੀਂ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਹੀ ਟੈਸਟ ਚਲਾਉਂਦੇ ਹੋ। ਇੱਕ ਈਮੇਲ ਆਉਂਦੀ ਹੈ। ਤੁਸੀਂ ਉਸਨੂੰ ਲੈ ਲੈਂਦੇ ਹੋ। ਬਹੁਤ ਸੌਖਾ ਹੈ।
CI ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰਾ ਮਾਹੌਲ ਹੈ। ਇੱਕ ਸਿੰਗਲ ਪੁੱਲ ਰਿਕਵੈਸਟ (pull request) ਚਾਰ, ਅੱਠ, ਜਾਂ ਸੋਲ਼ਹਾਂ ਪੈਰਲਲ (parallel) ਜੌਬਸ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਉਹ ਸਾਰੇ ਇੱਕ ਸਾਂਝੇ ਟੈਸਟ ਇਨਬਾਕਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ—ਚਾਹੇ ਉਹ Mailosaur ਸਰਵਰ ਹੋਵੇ, Mailtrap ਇਨਬਾਕਸ ਹੋਵੇ, ਜਾਂ ਸਟੇਜਿੰਗ ਡੋਮੇਨ 'ਤੇ ਕੋਈ ਅਸਲੀ ਖਾਤਾ ਹੋਵੇ—ਉਹ ਸਾਰੇ ਇੱਕੋ ਸਮੇਂ ਇੱਕੋ ਬੱਕੇਟ (bucket) ਵਿੱਚ ਲਿਖ ਰਹੇ ਹੁੰਦੇ ਹਨ। ਜੌਬ A ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਭੇਜਦੀ ਹੈ। ਜੌਬ B ਇੱਕ ਇਨਵਾਈਟ ਭੇਜਦੀ ਹੈ। ਜੌਬ C ਇੱਕ ਫੇਲ ਹੋਏ ਵੈਲਕਮ ਫਲੋਅ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ। ਇਸ ਦੌਰਾਨ, ਬੈਕਗ੍ਰਾਊਂਡ ਵਰਕਰ ਅਤੇ ਡਿਲੀਵਰੀ ਕਿਊਜ਼ (queues) ਅਜਿਹੀ ਅਨਿਸ਼ਚਿਤਤਾ (jitter) ਪੈਦਾ ਕਰਦੇ ਹਨ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਕੰਟਰੋਲ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਜਦੋਂ ਹਰ ਜੌਬ ਉਸ ਸਾਂਝੇ ਇਨਬਾਕਸ ਵਿੱਚੋਂ "Reset your password" ਵਿਸ਼ੇ (subject) ਵਾਲਾ ਸਭ ਤੋਂ ਨਵਾਂ ਸੁਨੇਹਾ ਮੰਗਦੀ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਦੌੜ (race) ਬਣ ਜਾਂਦੀ ਹੈ। ਜੋ ਟੈਸਟ ਜਿੱਤਦਾ ਹੈ, ਉਸਨੂੰ ਸਹੀ ਈਮੇਲ ਮਿਲਦੀ ਹੈ। ਜੋ ਟੈਸਟ ਹਾਰ ਜਾਂਦਾ ਹੈ, ਉਹ ਕਿਸੇ ਹੋਰ ਜੌਬ ਲਈ ਬਣਾਇਆ ਗਿਆ ਲਿੰਕ ਕਲਿੱਕ ਕਰਦਾ ਹੈ, ਗਲਤ ਸਮੱਗਰੀ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਅਜਿਹੀ ਗਲਤੀ (error) ਨਾਲ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ ਜੋ ਟਾਈਮਿੰਗ ਦੀ ਸਮੱਸਿਆ ਵਾਂਗ ਲੱਗਦੀ ਹੈ। ਇਹ ਟਾਈਮਿੰਗ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ। ਇਹ ਪਛਾਣ (identity) ਦੀ ਸਮੱਸਿਆ ਹੈ।
"ਨਵਾਂ ਸੁਨੇਹਾ" (Newest Message) ਕਿਉਂ ਫੇਲ ਹੁੰਦਾ ਹੈ
ਇਸ ਪੈਟਰਨ ਵਿੱਚ ਫਸਣਾ ਆਸਾਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਹਿਜ (intuitive) ਲੱਗਦਾ ਹੈ:
- ਯੂਜ਼ਰ ਫਲੋਅ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰੋ।
- ਹਰ ਕੁਝ ਸਕਿੰਟਾਂ ਬਾਅਦ ਇਨਬਾਕਸ ਦੀ ਜਾਂਚ (poll) ਕਰੋ।
- ਵਿਸ਼ੇ (subject line) ਨਾਲ ਮੇਲ ਖਾਣ ਵਾਲਾ ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਸੁਨੇਹਾ ਖੋਲ੍ਹੋ।
- ਪਹਿਲੇ ਲਿੰਕ 'ਤੇ ਕਲਿੱਕ ਕਰੋ ਅਤੇ ਐਸਰਸ਼ਨ (assertions) ਚਲਾਓ।
ਇਹ ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਪੈਰਲਲਿਜ਼ਮ (parallelism) ਤੋਂ ਇਲਾਵਾ ਹਨ। ਪਿਛਲੇ ਫੇਲ ਹੋਏ ਰਨ ਤੋਂ ਇੱਕ ਰੀਟ੍ਰਾਈ ਦੇਰੀ ਨਾਲ ਆ ਸਕਦੀ ਹੈ, ਜੋ ਅਚਾਨਕ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਟੈਸਟ ਦੇ ਪੋਲ (poll) ਕਰਨ ਦੇ ਸਮੇਂ ਸਭ ਤੋਂ ਨਵਾਂ ਸੁਨੇਹਾ ਬਣ ਸਕਦੀ ਹੈ। ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਬੈਕਗ੍ਰਾਊਂਡ ਵਰਕਰ ਦੋ ਈਮੇਲਾਂ ਨੂੰ ਕਿਊ ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹਨ ਅਤੇ ਪਹਿਲੀ ਤੋਂ ਪਹਿਲਾਂ ਦੂਜੀ ਈਮੇਲ ਡਿਲੀਵਰ ਕਰ ਸਕਦੇ ਹਨ। ਸਿਰਫ਼ ਵਿਸ਼ੇ (subject lines) ਕਮਜ਼ੋਰ ਪਛਾਣਕਰਤਾ ਹਨ; ਤੁਹਾਡੀ ਸਟੇਜਿੰਗ ਐਪਲੀਕੇਸ਼ਨ ਵੱਖ-ਵੱਖ ਰਸਤਿਆਂ ਤੋਂ ਸਮਾਨ ਈਮੇਲਾਂ ਭੇਜ ਸਕਦੀ ਹੈ। ਟਾਈਮਸਟੈਂਪ (timestamp) ਦੁਆਰਾ ਸੌਰਟ ਕਰਨਾ ਉਦੋਂ ਤੋਂ ਵੀ ਮਾੜਾ ਹੈ ਜਿੰਨਾ ਇਹ ਦਿਖਦਾ ਹੈ ਕਿਉਂਕਿ CI ਰਨਰ ਅਤੇ ਮੇਲ ਪ੍ਰੋਵਾਈਡਰ ਵਿਚਕਾਰ ਕਲਾਕ ਸਕਿਊ (clock skew) ਅਸਲੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਮੇਲ API ਅਕਸਰ ਆਪਣੇ ਇੰਡੈਕਸਾਂ ਨੂੰ ਕੈਸ਼ (cache) ਜਾਂ ਬੈਚ (batch) ਕਰਦੇ ਹਨ।
ਰੁਝੇਵੇਂ ਵਾਲੇ ਮਾਹੌਲ ਵਿੱਚ ਟਾਈਮਸਟੈਂਪ ਅਸਪਸ਼ਟ ਹੋ ਜਾਂਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਕੁਝ ਸਿੱਧਾ ਚਾਹੀਦਾ ਹੈ।
ਰਨ ਟੋਕਨ (Run Token) ਅਸਲ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ
ਰਨ ਟੋਕਨ ਤੁਹਾਡੇ ਟੈਸਟ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਤਿਆਰ ਕੀਤੀ ਗਈ ਇੱਕ ਵਿਲੱਖਣ ਸਟ੍ਰਿੰਗ (unique string) ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ ਹੈ ਜੋ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਭੇਜੀ ਗਈ ਈਮੇਲ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਨੂੰ ਯੂਜ਼ਰ ਨੂੰ ਦਿਖਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਸੁੰਦਰ ਦਿਖਣ ਦੀ ਵੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਸ ਨੂੰ ਸਿਰਫ਼ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਖਾਸ ਸੁਨੇਹਾ ਇਸ ਖਾਸ ਟੈਸਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ (execution) ਨਾਲ ਸਬੰਧਤ ਹੈ।
ਸਪਸ਼ਟ ਉਦਾਹਰਣਾਂ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਟੈਸਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਟੋਕਨ ਤਿਆਰ ਕਰੋ ਜਿਵੇਂ ਕਿ:
- ਇੱਕ UUID:
550e8400-e29b-41d4-a716-446655440001 - ਇੱਕ ਬਿਲਡ-ਸਕੋਪਡ ਰਿਕਵੈਸਟ ID:
req_ci_build_4821_a7f3 - ਇੱਕ ਇਨਵਾਈਟ ਸਲੱਗ (slug) ਜਾਂ ਮੈਟਾਡਾਟਾ ਸਫਿਕਸ:
signup-token-8k2m9n - ਟੈਸਟ ਰਨਰ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀ ਗਈ ਇੱਕ ਰੈਂਡਮ ਹੈਕਸ ਸਟ੍ਰਿੰਗ:
test-run-a4f9c2d1
ਜੇਕਰ ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਕੋਡ 'ਤੇ ਕੰਟਰੋਲ ਹੈ, ਤਾਂ ਟੋਕਨ ਨੂੰ ਈਮੇਲ ਕੰਟੈਕਸਟ ਵਿੱਚ ਪਾਸ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਬਾਡੀ ਵਿੱਚ ਕਿਤੇ ਰੈਂਡਰ ਕਰੋ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਬਲੈਕ-ਬਾਕਸ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਵਿਰੁੱਧ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਦੇਖੋ ਕਿ ਕੀ ਐਪ ਪਹਿਲਾਂ ਹੀ ਕੋਈ ਰੈਫਰੈਂਸ ਫੀਲਡ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਤੁਸੀਂ ਕਦੇ-ਕਦੇ ਪਲੱਸ ਐਡਰੈਸਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਾਪਤਕਰਤਾ ਦੇ ਲੋਕਲ-ਪਾਰਟ ਵਿੱਚ ਟੋਕਨ ਨੂੰ ਇਨਬੈਡ ਕਰ ਸਕਦੇ ਹੋ—testuser+a4f9c2d1@example.com—ਹਾਲਾਂਕਿ ਇਹ ਉਦੋਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਇਸਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੀ ਹੈ ਅਤੇ ਈਮੇਲ ਵਿੱਚ ਵਾਪਸ ਭੇਜਦੀ ਹੈ।
ਮਕਸਦ ਉਸ ਮੈਟਾਡਾਟਾ 'ਤੇ ਮੈਚ ਕਰਨਾ ਬੰਦ ਕਰਨਾ ਹੈ ਜਿਸਦਾ ਮੇਲ ਸਿਸਟਮ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਅਧਿਕਾਰ ਹੈ। ਉਸ ਡੇਟਾ 'ਤੇ ਮੈਚ ਕਰੋ ਜਿਸ 'ਤੇ ਤੁਹਾਡੇ ਟੈਸਟ ਦਾ ਅਧਿਕਾਰ ਹੈ।
ਭਰੋਸੇਯੋਗ ਪੈਟਰਨ (The Reliable Pattern)
"ਨਵੇਂ ਸੁਨੇਹੇ" ਵਾਲੇ ਐਲਗੋਰਿਦਮ ਨੂੰ ਇੱਕ ਤੰਗ, ਟੋਕਨ-ਡਰਿਵਨ ਸਰਚ ਨਾਲ ਬਦਲੋ:
- ਕਿਸੇ ਵੀ ਫਲੋਅ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰਨ ਟੋਕਨ ਤਿਆਰ ਕਰੋ।
- ਯੂਜ਼ਰ ਐਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰੋ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋਏ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਆਊਟਬਾਊਂਡ ਈਮੇਲ ਵਿੱਚ ਟੋਕਨ ਸ਼ਾਮਲ ਕਰੇਗੀ।
- ਉਸ ਟੋਕਨ ਤੱਕ ਸੀਮਤ ਫਿਲਟਰਾਂ ਨਾਲ ਮੇਲ ਪ੍ਰੋਵਾਈਡਰ ਨੂੰ ਪੋਲ (poll) ਕਰੋ। ਜੇਕਰ API ਬਾਡੀ ਸਰਚ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਉਮੀਦਵਾਰ ਸੁਨੇਹੇ ਪ੍ਰਾਪਤ ਕਰੋ ਅਤੇ ਕਲਾਇੰਟ-ਸਾਈਡ 'ਤੇ ਉਹਨਾਂ ਦੀਆਂ ਬਾਡੀਆਂ ਨੂੰ ਗ੍ਰੈਪ (grep) ਕਰੋ।
- ਕਿਸੇ ਵੀ ਲਿੰਕ, ਬਟਨ ਜਾਂ ਵੈਰੀਫਿਕੇਸ਼ਨ ਕੋਡ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਐਸਰਟ (assert) ਕਰੋ ਕਿ ਸੁਨੇਹਾ ਬਾਡੀ ਵਿੱਚ ਟੋਕਨ ਮੌਜੂਦ ਹੈ।
- ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਕਨਫਰਮੇਸ਼ਨ URL ਜਾਂ ਕੋਡ ਕੱਢੋ ਅਤੇ ਅੱਗੇ ਵਧੋ।
ਇਹ ਕ
ਵਿਵਹਾਰਕ ਤੌਰ 'ਤੇ, ਤੁਹਾਡੇ helper ਨੂੰ Subject:"Welcome to AppName" AND Body:"a4f9c2d1" ਦੀ ਭਾਲ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਨਾ ਕਿ Subject:"Welcome to AppName" sort:-received ਦੀ। ਬਹੁਤ ਸਾਰੀਆਂ ਮੇਲ ਟੈਸਟਿੰਗ ਸੇਵਾਵਾਂ ਅਜਿਹੀਆਂ search APIs ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ ਜੋ body content filters ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਸਰਲ ਪ੍ਰੋਵਾਈਡਰ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਆਪਣੇ polling logic ਨੂੰ ਇੱਕੋ ਜਗ੍ਹਾ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਹਰ ਟੈਸਟ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ client-side filtering ਜੋੜ ਸਕੋ।
ਸਿਸਟਮ ਨੂੰ ਸਹੀ ਰੱਖਣ ਲਈ ਤਿੰਨ ਨਿਯਮ
ਇੱਕ run token ਚੋਣ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਇਸ ਗੱਲ ਬਾਰੇ ਅਨੁਸ਼ਾਸਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ poll ਕਰਦੇ ਹੋ ਅਤੇ ਜਦੋਂ ਚੀਜ਼ਾਂ ਗਲਤ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ ਤੁਸੀਂ ਕੀ ਕਰਦੇ ਹੋ।
ਗਲਤੀ ਹੋਣ 'ਤੇ inbox ਦੀ ਸਥਿਤੀ ਨੂੰ log ਕਰੋ। ਜਦੋਂ ਕੋਈ ਟੈਸਟ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ inbox identifier, ਉਹ subject line ਜੋ ਤੁਸੀਂ queried ਕੀਤੀ ਸੀ, ਸਹੀ timestamp window, ਅਤੇ ਕਿੰਨੇ ਮੈਸੇਜ ਤੁਹਾਡੇ ਮਾਪਦੰਡਾਂ (criteria) ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ output ਕਰੋ। ਇਹ ਇੱਕ ਅਸਪਸ਼ਟ "email not found" ਗਲਤੀ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਕਹਾਣੀ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ job 7823 ਨੇ job 7821 ਤੋਂ ਇੱਕ retry message ਚੁੱਕ ਲਿਆ ਕਿਉਂਕਿ ਉਹ ਤਿੰਨ ਸਕਿੰਟ ਬਾਅਦ ਆਇਆ ਸੀ, ਤਾਂ ਤੁਹਾਡੇ logs ਨੂੰ ਇਹ ਸਪਸ਼ਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਸੰਦਰਭ (context) ਤੋਂ ਬਿਨਾਂ, ਤੁਸੀਂ ਸਮੇਂ (timing) ਨੂੰ ਦੋਸ਼ੀ ਮੰਨੋਗੇ ਅਤੇ ਇੱਕ ਹੋਰ sleep ਜੋੜ ਦਿਓਗੇ।
ਸਾਰੀ email polling ਨੂੰ ਇੱਕ ਹੀ helper ਫਾਈਲ ਵਿੱਚ ਰੱਖੋ। setTimeout ਅਤੇ cy.task calls ਨੂੰ ਵੀਹ ਟੈਸਟ ਫਾਈਲਾਂ ਵਿੱਚ ਨਾ ਖਿਲਾਰੋ। ਉਸ logic ਨੂੰ ਕੇਂਦਰਿਤ ਕਰੋ ਜੋ ਮੈਸੇਜਾਂ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, API call ਨੂੰ retry ਕਰਦਾ ਹੈ, ਅਤੇ backoff ਲਾਗੂ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਹਰ ਟੈਸਟ ਇੱਕੋ ਹੀ helper ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ filtering rules ਇੱਕੋ ਜਿਹੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ search logic ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਹਰ ਟੈਸਟ ਨੂੰ ਫਾਇਦਾ ਹੁੰਦਾ ਹੈ। ਇਹ token check ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਵੀ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ; ਜੇਕਰ helper ਨੂੰ token argument ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਕੋਈ ਵੀ ਗਲਤੀ ਨਾਲ "latest message" ਦੇ ਭਰੋਸੇ ਨਹੀਂ ਰਹਿ ਸਕਦਾ।
ਆਪਣੇ retries 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ। CI ਵਿੱਚ test retries ਆਮ ਹਨ, ਪਰ ਹਰ retry inbox ਵਿੱਚ ਇੱਕ ਹੋਰ email ਬਣਾਉਂਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਟੈਸਟ ਤੀਜੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜਸ਼ਨ ਮਨਾ ਸਕਦੇ ਹੋ ਅਤੇ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ। ਪਰ ਤੁਸੀਂ ਇਹ ਗੱਲ miss ਕਰ ਰਹੇ ਹੋ ਕਿ ਪਹਿਲੀਆਂ ਦੋ ਕੋਸ਼ਿਸ਼ਾਂ ਨੇ ਇੱਕ ਅਸਲੀ bug ਨੂੰ ਉਜਾਗਰ ਕੀਤਾ ਸੀ—ਜਿਵੇਂ ਕਿ race condition, duplicate send, ਜਾਂ missing index—ਜਿਸ ਨੂੰ ਵਾਧੂ ਮੈਸੇਜਾਂ ਨੇ ਛੁਪਾ ਦਿੱਤਾ ਸੀ। ਜੇਕਰ ਤੁਹਾਨੂੰ retries ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਹੀ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਚੈੱਕ ਕਰੋ ਕਿ ਕੀ ਗਲਤੀ ਤੋਂ ਬਾਅਦ inbox ਵਿੱਚ ਅਣਚਾਹੇ duplicates ਹਨ। ਇਸ ਤੋਂ ਵੀ ਬਿਹਤਰ ਹੈ, ਜੇਕਰ ਤੁਹਾਡਾ provider dynamic inboxes ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ inbox ਨੂੰ ਸਾਫ਼ ਕਰਨ ਜਾਂ ਹਰੇਕ job ਲਈ ਇੱਕ ਵਿਲੱਖਣ (unique) ਪਤਾ ਵਰਤਣ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ। Retries ਨੂੰ ਅਸਥਿਰ selection logic ਨੂੰ ਛੁਪਾਉਣ ਦੀ ਰਣਨੀਤੀ ਨਹੀਂ ਬਣਨਾ ਚਾਹੀਦਾ।
ਅਸਲ ਸਿੱਖਿਆ
Inbox ਨੂੰ ਮਿਤੀ (date) ਅਨੁਸਾਰ sort ਕਰਨਾ ਅਤੇ ਸਭ ਤੋਂ ਉੱਪਰਲਾ ਨਤੀਜਾ ਲੈਣਾ ਟੈਸਟਿੰਗ ਨਹੀਂ ਹੈ। ਇਹ ਕੋਡ ਵਿੱਚ ਲਿਖਿਆ ਇੱਕ ਅੰਦਾਜ਼ਾ ਹੈ। ਇੱਕ run token ਦੀ ਲਗਭਗ ਕੋਈ ਕੀਮਤ ਨਹੀਂ ਹੈ—ਇੱਕ string variable, ਇੱਕ ਵਾਧੂ filter parameter, ਸ਼ਾਇਦ ਇੱਕ ਛੋਟਾ template change—ਅਤੇ ਇਹ ਤੁਹਾਡੇ ਟੈਸਟ ਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ (deterministic) ਪਛਾਣ ਦਿੰਦਾ ਹੈ। ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਵਾਲਾ ਮੈਸੇਜ ਉਸੇ run ਨਾਲ ਸਬੰਧਤ ਹੈ ਜੋ ਤੁਸੀਂ ਇਸ ਸਮੇਂ ਚਲਾ ਰਹੇ ਹੋ।
Sleeps ਜੋੜਨਾ ਅਤੇ ਨੈੱਟਵਰਕ ਦੇ ਸਹੀ ਚੱਲਣ ਦੀ ਉਮੀਦ ਕਰਨਾ ਬੰਦ ਕਰੋ। ਇੱਕ token ਬਣਾਓ, ਇਸਨੂੰ email ਵਿੱਚ ਪਾਓ, ਅਤੇ ਸਿੱਧਾ ਇਸਦੀ ਭਾਲ ਕਰੋ। ਤੁਹਾਡੇ CI runs ਤੇਜ਼ ਹੋਣਗੇ, ਤੁਹਾਡੇ logs ਪੜ੍ਹਨਯੋਗ ਹੋਣਗੇ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਤੁਸੀਂ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੋਗੇ ਜੋ ਤੁਹਾਡਾ email suite ਤੁਹਾਨੂੰ ਦੱਸ ਰਿਹਾ ਹੈ।