ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਕਿਵੇਂ ਇੰਜੀਨੀਅਰਿੰਗ ਸੰਸਕ੍ਰਿਤੀ ਅਤੇ ਗੁਣਵੱਤਾ ਨੂੰ ਆਕਾਰ ਦਿੰਦੇ ਹਨ

ਅਸੀਂ “ਸੰਸਕ੍ਰਿਤੀ” ਨਾਲ ਕੀ ਮਤਲਬ ਲੈਂਦੇ ਹਾਂ ਅਤੇ ਟੂਲ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ

“ਇੰਜੀਨੀਅਰਿੰਗ ਸੰਸਕ੍ਰਿਤੀ” ਸੁਣਨ ਵਿੱਚ ਅਬਸਟਰੈਕਟ ਲੱਗਦੀ ਹੈ, ਪਰ ਇਹ ਬਹੁਤ ਹੀ ਪ੍ਰਾਇਕਟਿਕ ਤਰੀਕੇ ਨਾਲ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ: ਰੁਜ਼ਾਨਾ ਜਦੋਂ ਲੋਕ ਵਿਆਸਤ ਹੁੰਦੇ ਹਨ ਤਾਂ ਉਹ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਕੀ ਕਰਦੇ ਹਨ, ਦਬਾਅ ਹੇਠਾਂ ਉਹ ਕਿਹੜੀਆਂ ਤਰਜੀحات ਲੈਂਦੇ ਹਨ, ਅਤੇ ਕੀ ਚੀਜ਼ਾਂ “ਆਮ” ਜਾਂ “ਖਤਰਨਾਕ” ਮੰਨੀ ਜਾਂਦੀਆਂ ਹਨ। ਇਹ ਉਹ ਰੋਜ਼ਾਨਾ ਆਦਤਾਂ ਹਨ—ਕੋਡ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਲਿਖਣਾ, ਲੋਕਲ ਚੈੱਕ ਚਲਾਉਣਾ, ਰਿਵਿਊ ਮੰਗਣਾ, ਅਨੁਮਾਨ ਦਸਤਾਵੇਜ਼ ਕਰਨਾ—ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਗੁਣਵੱਤਾ ਨੂੰ ਤਿਆਰ ਕਰਦੀਆਂ ਹਨ।

ਸੰਸਕ੍ਰਿਤੀ ਇੱਕ ਡਿਫ਼ਾਲਟ ਸੈੱਟ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਸੰਸਕ੍ਰਿਤੀ ਬਾਰੇ ਮੀਟਿੰਗਾਂ ਵਿੱਚ ਗੱਲ ਨਹੀਂ ਕਰਦੀਆਂ। ਸੰਸਕ੍ਰਿਤੀ ਇਹਨਾਂ ਵਿੱਚ ਦਰਸਦੀ ਹੈ:

• ਮਿਆਰ: “ਚੰਗਾ” ਕਿੰਝ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ (ਅਤੇ ਕੀ ਫਿਰ ਵੀ ਮਰਜ ਹੋ ਜਾਂਦਾ ਹੈ)।
• ਫੈਸਲੇ ਲੈਣਾ: ਲੋਕ ਸੁਰੱਖਿਅਤ ਰਾਹ ਜਾਂ ਤੁਰੰਤ ਤੇਜ਼ ਰਾਹ ਚੁਣਦੇ ਹਨ।
• ਫੀਡਬੈਕ ਲੂਪ: ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕੁਝ ਟੁੱਟਿਆ ਕਿਵੇਂ ਤੇਜ਼ੀ ਨਾਲ।
• ਜਵਾਬਦੇਹੀ: ਕੀ ਸਮੱਸਿਆਵਾਂ ਫਿਕਸ ਹੁੰਦੀਆਂ ਹਨ ਜਾਂ ਉਠ ਬੈਠਣੇ (finger-pointing) ਹੁੰਦੇ ਹਨ।

ਇਹ ਪੈਟਰਨ ਰੋਜ਼ਾਨਾ ਤਜਰਬੇ ਨਾਲ ਮਜ਼ਬੂਤ ਹੁੰਦੇ ਹਨ। ਜੇ ਗੁਣਵੱਤਾ ਚੈੱਕ ਸਾਰੇ ਲਈ ਧੀਮੇ, ਉਝਲੇ ਜਾਂ ਦਰਦਨਾਕ ਹਨ, ਤਾਂ ਲੋਕ ਉਹਨਾਂ ਤੋਂ ਪਰਹੇਜ਼ ਕਰਨਾ ਸਿੱਖ ਲੈਂਦੇ ਹਨ। ਜੇ ਉਹ ਤੇਜ਼ ਅਤੇ ਜਾਣਕਾਰੀਆਂ ਭਰੇ ਹਨ, ਤਾਂ ਲੋਕ ਅਹਿਸਾਸਾਤਮਕ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।

ਇੱਕ ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਸਿਰਫ਼ ਇਕ ਟੂਲ ਨਹੀਂ

ਜਦੋਂ ਅਸੀਂ “ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ” ਕਹਿੰਦੇ ਹਾਂ, ਅਸੀਂ ਸਿਰਫ਼ ਅਸਰਸ਼ਨ APIs ਦੀ ਗੱਲ ਨਹੀਂ ਕਰ ਰਹੇ। ਇੱਕ ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:

• ਟੂਲਿੰਗ: ਰਨਰ, ਅਸਰਸ਼ਨ, ਫਿਕਸਚਰ/ਮੌਕ, ਰਿਪੋਰਟਰ, ਵਾਚ ਮੋਡ।
• ਰਿਵਾਜ: ਟੈਸਟਾਂ ਦੀ ਬਣਤਰ, ਨਾਮਕਰਨ ਅਤੇ ਆਯੋਜਨ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ।
• ਵਰਕਫਲੋਜ਼: ਟੈਸਟ ਲੋਕਲ ਅਤੇ CI ਵਿੱਚ ਕਿਵੇਂ ਚੱਲਦੇ ਹਨ, ਫੇਲੀਆ ਹੁੰਦਿਆਂ ਦਿਖਾਈ ਦੇਣ ਦਾ ਢੰਗ, ਕੀ “ਕਾਫ਼ੀ” ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।

ਇਹ ਸਾਰਾ ਬੰਡਲ ਡਿਵੈਲਪਰ ਅਨੁਭਵ ਨੂੰ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ: ਟੈਸਟ ਲਿਖਣਾ ਕੋਡਿੰਗ ਦਾ ਸੁਭਾਵਿਕ ਹਿੱਸਾ ਹੈ ਜਾਂ ਇੱਕ ਵਾਧੂ ਕੰਮ ਜੋ ਮੁਲਤਵੀ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇਹ ਲੇਖ ਟੂਲ-ਜੰਗ ਨਹੀਂ, ਬਿਹੇਵਿਯਰ ਚੇੰਜ ਦੀ ਗੱਲ ਹੈ

ਵੱਖ-ਵੱਖ ਫਰੇਮਵਰਕ ਚੰਗੇ ਨਤੀਜੇ ਦੇ ਸਕਦੇ ਹਨ। ਜ਼ਿਆਦਾ ਜ਼ਰੂਰੀ ਸਵਾਲ ਇਹ ਹੈ: ਇਹ ਫਰੇਮਵਰਕ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਕਿਹੜੇ ਵਿਹਵਾਰ ਨੂੰ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦਾ ਹੈ? ਕੀ ਇਹ ਰੱਖ-ਰਖਾਅ ਯੋਗ ਟੈਸਟ ਲਿਖਣਾ ਅਸਾਨ ਬਣਾਉਂਦਾ ਹੈ? ਕੀ ਇਹ ਸਪਸ਼ਟ ਫੇਲ੍ਹ ਸੁਨੇਹਿਆਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ? ਕੀ ਇਹ ਤੁਹਾਡੇ CI ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਸੁਚੱਜੇ ਤਰੀਕੇ ਨਾਲ ਇਕੱਠਾ ਹੁੰਦਾ ਹੈ?

ਇਹ ਵੇਰਵੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਡੀ ਟੀਮ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ—ਅਤੇ ਅਮਲ ਵਿੱਚ ਗੁਣਵੱਤਾ ਦਾ ਕੀ ਮਤਲਬ ਹੈ।

ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਟੀਮਾਂ ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕਾਂ ਨੂੰ ਐਸਾ ਚੁਣਨ ਅਤੇ ਵਰਤਨ ਜੋ ਚੰਗੀਆਂ ਆਦਤਾਂ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰੇ: ਤੇਜ਼ ਫੀਡਬੈਕ, ਸਪਸ਼ਟ ਉਮੀਦਾਂ, ਅਤੇ ਰਿਲੀਜ਼ਾਂ ਵਿੱਚ ਭਰੋਸਾ।

ਫਰੇਮਵਰਕ ਡੇਫੌਲਟ ਰੋਜ਼ਾਨਾ ਆਦਤਾਂ ਨੂੰ ਬਣਾਉਂਦੇ ਹਨ

ਇੱਕ ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਤਟਪੂਰਕ ਨਹੀਂ ਹੁੰਦਾ। ਇਸ ਦੀ “ਹੈਪੀ ਪਾਥ” ਚੁਪਚਾਪ ਇਹ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਪਹਿਲਾਂ ਕੀ ਟੈਸਟ ਕਰਨਾ ਸਹਿਜ ਮਹਿਸੂਸ ਹੋਵੇਗਾ—ਅਤੇ ਕੀ ਵਿਕਲਪਤ ਮਹਿਸੂਸ ਹੋਵੇਗਾ।

ਪਹਿਲਾਂ ਕਿਹੜੀ ਚੀਜ਼ ਟੈਸਟ ਹੁੰਦੀ ਹੈ: ਯੂਨਿਟ vs E2E

ਜਦੋਂ ਕੋਈ ਫਰੇਮਵਰਕ ਛੋਟੇ, ਅਲੱਗ-ਥਲੱਗ ਟੈਸਟ ਸ਼ੁਰੂ ਕਰਨ ਨੂੰ ਬੇਹੱਦ ਆਸਾਨ ਬਣਾ ਦਿੰਦਾ ਹੈ (ਤੇਜ਼ ਰਨਰ, ਘੱਟ ਬੂਇਲਰਪਲੇਟ, ਸਾਦਾ ਪੈਰਾਮੀਟਰਾਈਜੇਸ਼ਨ), ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਯੂਨਿਟ ਟੈਸਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਫੀਡਬੈਕ ਤੁਰੰਤ ਹੁੰਦਾ ਹੈ। ਦੂਜੇ ਪਾਸੇ, ਜੇ ਆਸਾਨ ਸੈਟਅੱਪ ਬ੍ਰਾਉਜ਼ਰ ਰਨਰ ਜਾਂ ਪੂਰੇ ਐਪ ਹਾਰਨੈੱਸ ਦੇ ਰਾਹੀਂ ਹੈ, ਲੋਕ ਅਕਸਰ E2E ਚੈੱਕਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ—ਭਾਵੇਂ ਉਹ ਧੀਮੇ ਅਤੇ ਨਿਰਧਾਰਿਤ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਹੋਣ।

ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਡਿਫ਼ਾਲਟ ਸੰਸਕ੍ਰਿਤੀ ਬਣ ਜਾਂਦਾ ਹੈ: “ਅਸੀਂ ਕਲਿੱਕ ਕਰਕੇ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਾਂ” ਬਨਾਮ “ਅਸੀਂ ਲਾਜ਼ਮੀ ਤਰੱਕੀ ਦੀ ਜਾਂਚ ਕਰਕੇ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਾਂ।”

ਅਜਿਹੇ ਡਿਫ਼ਾਲਟ ਜੋ ਵਿਹਵਾਰ ਨੂੰ ਧਕੇਲਦੇ ਹਨ

ਫਰੇਮਵਰਕ ਰਾਏਆਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ:

• ਅਸਰਸ਼ਨ: ਪੜਹਣਯੋਗ ਅਤੇ ਨਿਰਦਿਸ਼ਟ ਅਸਰਸ਼ਨ ਸਪਸ਼ਟ ਉਮੀਦਾਂ ਨੂੰ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦੇ ਹਨ; ਝੁਟੇ ਮੈਚਰ “ਕਾਫ਼ੀ ਨੇੜੇ” ਜਾਂਚਾਂ ਨੂੰ ਬੁਲਾਉਂਦੇ ਹਨ।
• ਫਿਕਸਚਰ: ਚੰਗੇ ਫਿਕਸਚਰ ਪੈਟਰਨ ਦੁਬਾਰਾ ਵਰਤੋਂ ਅਤੇ ਸਪਸ਼ਟਤਾ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੇ ਹਨ; ਅਸੁਖਦ ਫਿਕਸਚਰ ਨਕਲ-ਪੇਸਟ ਕੀਤੇ ਸੈਟਅੱਪ ਅਤੇ ਛੁਪੇ ਨਿਰਭਰਤਾਵਾਂ ਦੀ ਉਸਾਰੀ ਕਰਦੇ ਹਨ।
• ਮੌਕਿੰਗ: ਹਲਕੇ-ਫulka ਮੌਕਿੰਗ ਅਲੱਗ-ਥਲੱਗ ਜਾਣ ਨੂੰ ਆਮ ਬਣਾਉਂਦੀ ਹੈ; ਭਾਰੀਆ ਮੌਕਿੰਗ APIs ਟੀਮਾਂ ਨੂੰ ਓਵਰ-ਮੌਕ ਕਰਨ ਦੀ ਝੁਕਾਅ ਦੇ ਸਕਦੇ ਹਨ ਅਤੇ ਟੈਸਟ ਨਾਜ਼ੁਕ ਬਣਨ ਲੱਗਦੇ ਹਨ।

ਇਹ ਚੋਣਾਂ ਅਬਸਟਰੈਕਟ ਨਹੀਂ—ਉਹ ਰੋਜ਼ਾਨਾ ਆਦਤਾਂ ਨੂੰ ਆਕਾਰ ਦਿੰਦੀਆਂ ਹਨ ਜਿਵੇਂ ਕਿ ਟੈਸਟਾਂ ਦਾ ਨਾਮਕਰਨ, ਮੌਡੀਊਲਾਂ ਦੀ ਬਣਤਰ, ਅਤੇ ਡਿਵੈਲਪਰ ਕਿੰਨੀ ਵਾਰ ਟੈਸਟ ਕੋਡ ਰੀਫੈਕਟਰ ਕਰਦਾ ਹੈ।

“ਆਸਾਨ” vs “ਦੁੱਖਦਾਇਕ” ਟੈਸਟ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਉਹ ਲਿਖੇ ਜਾਣਗੇ ਕਿ ਨਹੀਂ

ਜੇ ਟੈਸਟ ਲਿਖਨਾ ਇੱਕ ਛੋਟੀ ਫੰਕਸ਼ਨ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਜਿਹਾ ਮਹਿਸੂਸ ਹੋਵੇ, ਤਾਂ ਉਹ ਆਮ ਵਿਕਾਸ ਦੌਰਾਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਜੇ ਇਸ ਲਈ ਕਨਫਿਗ, ਗਲੋਬਲ, ਜਾਂ ਧੀਮੀ ਸਟਾਰਟਅੱਪ ਨਾਲ ਜੂਝਣਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਟੈਸਟ कुछ ਬਾਅਦ ਦਾ ਕੰਮ ਬਣ ਜਾਂਦੇ ਹਨ। ਟੂਲਿੰਗ friction ਫਿਰ ਮਾਮੂਲੀ ਝਲਕੇ ਬਣਾਉਂਦੀ ਹੈ:

• ਲੋਕ ਲੋਕਲ ਤੇ ਟੈਸਟ ਸਕਿਪ ਕਰਦੇ ਹਨ ਅਤੇ CI 'ਤੇ ਨਿਰਭਰ ਹੋ ਜਾਂਦੇ ਹਨ
• ਫਲੇਕਨੈਸੀ ਲੁਕਾਉਣ ਲਈ sleeps/retries ਜੋੜਦੇ ਹਨ
• ਮਸ਼ਕਲ-ਟੈਸਟ ਹੋਣ ਵਾਲੀਆਂ ਕਾਂਪੋਨੈਂਟਾਂ ਤੋਂ ਬਚਣ ਲਈ ਵਿਆਪਕ E2E ਟੈਸਟ ਬਣਾਉਂਦੇ ਹਨ

ਇਹ ਸ਼ੌਰਟਕਟ ਘਟਦੇ-ਘਟਦਿਆਂ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਫਰੇਮਵਰਕ ਦੇ ਡਿਫ਼ਾਲਟ ਟੀਮ ਦੀ ਮਨਜ਼ੂਰੀ ਯੋਗ ਗੁਣਵੱਤਾ ਬਣ ਜਾਂਦੇ ਹਨ।

ਫੀਡਬੈਕ ਗਤੀ ਟੀਮ ਦੀ ਰਿਧਮ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ

ਇੱਕ ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਸਿਰਫ ਚੈੱਕ ਚਲਾਉਂਦਾ ਨਹੀਂ—ਇਹ ਲੋਕਾਂ ਨੂੰ ਟਰੇਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਫੀਡਬੈਕ ਤੇਜ਼ ਅਤੇ ਸਮਝਣਯੋਗ ਹੁੰਦਾ ਹੈ, ਡਿਵੈਲਪਰ ਅਕਸਰ ਵੱਧ ਕਮਿਟ ਕਰਦੇ ਹਨ, ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਰੀਫੈਕਟਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਟੈਸਟ ਨੂੰ ਵੱਖਰਾ ਕੰਮ ਨਹੀਂ ਪਰ ਕੰਮ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਮੰਨਦੇ ਹਨ।

ਤੇਜ਼ ਫੀਡਬੈਕ "ਛੋਟੇ ਅਤੇ ਸਥਿਰ" ਨੂੰ ਡਿਫਾਲਟ ਬਣਾਉਂਦਾ ਹੈ

ਜੇਕਰ ਇੱਕ ਬਦਲਾਵ ਦੀ ਪੁਸ਼ਟੀ ਸਕਿੰਟਾਂ ਵਿੱਚ ਹੋ ਸਕਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਸੰਭਾਲ ਕੇ:

• ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਕਮਿਟ ਕਰੋ
• ਕੋਡ ਦਾ ਨਾਮ ਬਦਲਣ ਅਤੇ ਮੁੜਸੰਰਚਨਾ ਨਾ ਡਰੋ
• ਵੱਖ-ਵੱਖ ਵਿਕਲਪ ਟੈਸਟ ਕਰੋ ਅਤੇ ਜਦੋਂ ਗਲਤ ਲੱਗੇ ਤਾਂ ਅਸਾਨੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰੋ

ਫਰੇਮਵਰਕ ਫੀਚਰਾਂ ਇਸ ਵਿਹਵਾਰ ਨੂੰ ਸਿੱਧਾ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। ਵਾਚ ਮੋਡ ਤਿੱਖੇ ਲੂਪਾਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ (“ਸੇਵ → ਨਤੀਜੇ ਵੇਖੋ”), ਜੋ ਪਰਯੋਗ ਨੂੰ ਆਮ ਬਣਾਉਂਦਾ ਹੈ। ਨਿਸ਼ਾਨਾਬੰਦੀ ਟੈਸਟ ਚੋਣ (ਸਿਰਫ ਪ੍ਰਭਾਵਿਤ ਟੈਸਟ ਚਲਾਉਣਾ, ਟੈਸਟ ਫਾਇਲ ਪੈਟਰਨ, ਜਾਂ ਆਖਰੀ ਫ਼ੇਲ ਹੋਏ ਟੈਸਟ) ਅਨੁਮਾਨ ਜਾਂਚਣ ਦੀ ਲਾਗਤ ਘਟਾਉਂਦਾ ਹੈ। ਪੈਰਲੈਲ ਰਨ ਉਡੀਕ ਸਮਾਂ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਬਦਲੇ ਵਿੱਚ “ਕਈ ਬਦਲਾਵਾਂ ਇਕੱਠੇ ਟੈਸਟ ਕਰਨ” ਦਾ ਦਬਾਅ ਹਟਾਉਂਦੇ ਹਨ।

ਧੀਮੇ ਸੂਟ ਡਰ ਬਣਾਉਂਦੇ ਹਨ—ਅਤੇ ਵੱਡੇ, ਜੋਖਮ ਭਰੇ ਬੈਚ

ਜਦੋਂ ਪੂਰਾ ਸੂਟ 20–60 ਮਿੰਟ ਲੈਂਦਾ ਹੈ, ਟੀਮ ਅਣੁਮਾਨਿਤ ਤਰੀਕਿਆਂ ਨਾਲ ਅਡਾਪਟ ਕਰਦੀ ਹੈ: ਘੱਟ ਚਲਾਣ, ਘੱਟ ਕਮਿਟ, ਅਤੇ “ਮੈਂ ਕੁਝ ਹੋਰ ਕਰ ਲੈਂਦਾ ਹਾਂ ਫਿਰ ਟੈਸਟ ਕਰਾਂਗਾ” ਦਾ ਸੋਚ। ਇਹ ਵੱਡੇ ਬੈਚਾਂ, ਮੁਸ਼ਕਲ ਰਿਵਿਊ PRs, ਅਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਖੋਜਣ ਵਿੱਚ ਭਰ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਬਦਲਾਅ ਨੇ ਫੇਲ ਕੀਤਾ।

ਸਮੇਂ ਦੇ ਨਾਲ, ਧੀਮੀ ਫੀਡਬੈਕ ਰੀਫੈਕਟਰਿੰਗ ਨੂੰ ਹੌਂਸਲਾ ਨਹੀਂ ਦਿੰਦਾ। ਲੋਕ ਉਹ ਕੋਡ ਨਾ ਛੇੜਦੇ ਜੋ ਉਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸਮਝਦੇ ਕਿਉਂਕਿ ਵੈਲਿਡੇਸ਼ਨ ਦੀ ਲਾਗਤ ਬਹੁਤ ਵੱਡੀ ਹੈ।

ਰਿਧਮ ਦੀ ਰੱਖਿਆ ਲਈ ਸਮਾਂ ਬਜਟ ਤੈਅ ਕਰੋ

ਟੀਮਾਂ ਤੇਜ਼ੀ ਨੂੰ ਇੱਕ ਲੋੜ ਦੇ ਤੌਰ 'ਤੇ ਰੱਖ ਸਕਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਕੇਵਲ ਚੰਗੀ ਗੱਲ। ਇੱਕ ਸਧਾਰਨ ਨੀਤੀ ਮਦਦ ਕਰਦੀ ਹੈ:

• ਯੂਨਿਟ ਟੈਸਟ: ਲੋਕਲ ਤੇ 2–5 ਮਿੰਟ ਤੋਂ ਘੱਟ
• PR-ਪੱਧਰ ਸੂਟ: CI ਵਿੱਚ 10–15 ਮਿੰਟ ਤੋਂ ਘੱਟ
• ਲੰਮੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਰਨ: ਉੱਚ-ਜੋਖਮ ਬਦਲਾਵਾਂ ਲਈ ਨਿਯਤ ਜਾਂ gated ਰੱਖੋ

ਜਦੋਂ ਤੁਸੀਂ ਬਜਟ ਤੈਅ ਕਰ ਲੈਂਦੇ ਹੋ, ਤੁਸੀਂ ਫਰੇਮਵਰਕ ਸੈਟਿੰਗਾਂ (ਪੈਰਲੈਲਾਈਜ਼ੇਸ਼ਨ, ਸ਼ਾਰਡਿੰਗ, ਚੁਣਿੰਦੇ ਰਨ) ਚੁਣ ਸਕਦੇ ਹੋ ਜੋ ਰਿਧਮ—ਅਤੇ ਸੰਸਕ੍ਰਿਤੀ—ਨੂੰ ਸਿਹਤਮੰਦ ਰੱਖਦੇ ਹਨ।

ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਸਪਸ਼ਟਤਾ ਭਰੋਸਾ ਬਣਾਉਂਦੀ ਹੈ—ਜਾਂ ਘੱਟ ਕਰ ਦਿੰਦੀ ਹੈ

ਜਦੋਂ ਇੱਕ ਟੈਸਟ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਟੀਮ ਤੁਰੰਤ ਦੋ ਸਵਾਲ ਪੁੱਛਦੀ ਹੈ: “ਕੀ ਟੁੱਟਿਆ?” ਅਤੇ “ਕੀ ਮੈਂ ਇਸ ਸਿਗਨਲ ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦਾ/ਸੱਕਦੀ ਹਾਂ?” ਤੁਹਾਡਾ ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਇਹ ਨਿਰਣੇ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਜਵਾਬ ਸਕਿੰਟਾਂ ਵਿੱਚ ਮਿਲਦੇ ਹਨ ਜਾਂ ਲੰਮੇ ਸ਼ੋਰ ਭਰੇ ਲੌਗ ਵਿੱਚ ਖੋ ਜਾਦੇ ਹਨ।

ਪੜਹਣਯੋਗ ਆਉਟਪੁੱਟ ਡੀਬੱਗਿੰਗ ਘਟਾਉਂਦਾ ਹੈ (ਅਤੇ ਤੇਜ਼ ਸਿੱਖਾਉਂਦਾ ਹੈ)

ਸਪਸ਼ਟ ਫੇਲ੍ਹ ਆਉਟਪੁੱਟ ਖਾਮੋਸ਼ ਪ੍ਰੋਡਕਟਿਵਿਟੀ ਬਹੁਗੁਣਾ ਵਧਾਉਂਦਾ ਹੈ। ਇਕ ਡਿਫ਼ ਜੋ ਠੀਕ ਉਹੀ ਤਬਦੀਲੀ ਰੋਸ਼ਨ ਕਰਦਾ ਹੈ, ਇੱਕ ਸਟੈਕ ਟ੍ਰੇਸ ਜੋ ਤੁਹਾਡੇ ਕੋਡ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ (ਫਰੇਮਵਰਕ ਇੰਟਰਨਲ ਨਹੀਂ), ਅਤੇ ਇੱਕ ਸੁਨੇਹਾ ਜੋ ਅਸਲ ਇਨਪੁੱਟ ਦਿਖਾਊਂਦਾ ਹੈ—ਇਹ ਸਭ ਫੇਲ੍ਹ ਨੂੰ ਇੱਕ ਤੇਜ਼ ਫਿਕਸ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ।

ਉਲਟ, ਅਜਿਹੇ ਕ੍ਰਿਪਟਿਕ ਅਸਰਸ਼ਨ, ਘੱਟ ਸੰਦਰਭ, ਜਾਂ ਲੌਗ ਜੋ ਜ਼ਰੂਰੀ ਲਾਈਨ ਨੂੰ ਤਹਿਤ ਛੱਡਦੇ ਹਨ ਡੀਬੱਗਿੰਗ ਸਮਾਂ ਵਧਾਉਂਦੇ ਹਨ ਅਤੇ ਨਵੇਂ ਸਾਥੀਆਂ ਲਈ ਸਿੱਖਣ ਨੂੰ ਧੀਰ ਕਰ ਦਿੰਦੇ ਹਨ। ਸਮੇਂ ਦੇ ਨਾਲ, ਲੋਕ ਟੈਸਟ ਫੇਲੀਆਂ ਨੂੰ “ਕਿਸੇ ਹੋਰ ਦੀ ਸਮੱਸਿਆ” ਸਮਝਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਸਮਝਣਾ ਮਹਿੰਗਾ ਪੈਂਦਾ ਹੈ।

ਚੰਗੇ ਐਰਰ ਸੁਨੇਹੇ ਦੋਸ਼- ਲਗਾਉਣ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਸਹਯੋਗ ਤੇਜ਼ ਕਰਦੇ ਹਨ

ਜੋ ਫੇਲ੍ਹ ਇਹ ਦੱਸਦੇ ਹਨ कि ਕਿਉਂ ਕੁਝ ਗਲਤ ਹੈ, ਇੱਕ ਸ਼ਾਂਤ ਮਾਹੌਲ ਬਣਾਉਂਦੇ ਹਨ। “ਉਮੀਦ ਕੀਤੀ 200, ਮਿਲਿਆ 500” ਸ਼ੁਰੂਆਤ ਹੈ; “/checkout ਤੋਂ ਵਰਧਮਾਨ ਕਾਰਟ ਨਾਲ ਉਮੀਦ 200; 500 ਮਿਲਿਆ (NullReference in PaymentMapper)” ਕਾਰਵਾਈਯੋਗ ਹੈ।

ਜਦੋਂ ਸੁਨੇਹੇ ਵਿੱਚ ਇਰਾਦਾ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਸਥਿਤੀ (ਯੂਜ਼ਰ ਪ੍ਰਕਾਰ, ਫੀਚਰ ਫਲੈਗ, ਵਾਤਾਵਰਨ ਅਨੁਮਾਨ) ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਸਾਥੀ ਜੋੜ ਕੇ ਫਿਕਸ ਕਰ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਕਿਸੇ ਦੀ ਗਲਤੀ 'ਤੇ ਤਰਕ ਕਰਨ।

ਇੱਕ ਵਪਾਰਕ ਨਿਯਮ: ਜੇ ਕੋਈ ਫੇਲ੍ਹ ਸੁਨੇਹਾ ਉਸ ਵਿਅਕਤੀ ਦੁਆਰਾ ਸਮਝਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਜਿਸਨੇ ਟੈਸਟ ਨਹੀਂ ਲਿਖਿਆ, ਤਾਂ ਇਹ ਵਿਚੋਲਈ ਰੁਕਾਵਟਾਂ, ਰਖਿਆਰੂਪ, ਅਤੇ ਹੌਲੀ ਰਿਵਿਊ ਪੈਦਾ ਕਰੇਗਾ।

ਰਿਵਾਜ: ਨਾਮ, ਬਣਤਰ, ਰਿਪੋਰਟਿੰਗ

ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਪੈਟਰਨ ਉਤਸ਼ਾਹਿਤ ਕਰਦੇ ਹਨ—ਇਸਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਟੈਂਡਰਡ ਬਣਾਓ:

• ਨਾਮਕਰਨ: ਮਨਸੂਖ-ਪਹਿਲਾਂ ਨਾਮ ਪਸੰਦ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, checkout_returns_200_for_valid_card) ਬਨਾਮ ਅਸਪਸ਼ਟ (ਜਿਵੇਂ testCheckout)।
• ਬਣਤਰ: ਇੱਕ ਸਥਿਰ Arrange/Act/Assert ਲੇਆਊਟ ਵਰਤੋ ਤਾਂ ਕਿ ਕੋਈ ਵੀ ਟੈਸਟ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰ ਸਕੇ।
• ਰਿਪੋਰਟਿੰਗ: ਫੇਲ੍ਹ ਤੇ ਕੀ ਪ੍ਰਿੰਟ ਹੋਏ (ਮੁੱਖ IDs, URLs, ਪੇਲੋਡ ਸਨਿੱਪੇਟ, ਅਤੇ ਜ਼ਰੂਰੀ ਲੋਗ) 'ਤੇ ਰਾਜ਼ੀ ਹੋਵੋ। ਰਿਪੋਰਟਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖੋ ਤਾਂ ਕਿ CI ਫੇਲ੍ਹ ਜਾਣਲੇਖਗਤ ਹੋਣ।

ਫਲੇਕੀ ਟੈਸਟ ਭਰੋਸਾ ਘਟਾਉਂਦੇ ਹਨ

ਕੋਈ ਵੀ ਚੀਜ਼ ਭਰੋਸੇ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕਿਸੇ ਹੋਰ ਨਾਲ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀ ਨਹੀਂ ਜਿੰਨੀ ਕਿ “ਕਦੇ-ਕਦੇ” ਫੇਲ ਹੋਣ ਵਾਲੇ ਟੈਸਟ। ਫਲੇਕਨੈਸੀ ਟੀਮ ਨੂੰ ਲਾਲ ਬਿਲਡ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨ, ਨੌਕਰੀ ਰੀ-ਰਨ ਕਰਨ, ਅਤੇ ਸ਼ੰਕ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦੀ ਆਦਤ ਪਾ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਆਦਤ ਬਣ ਜਾਂਦੀ ਹੈ, ਅਸਲੀ ਫੇਲ੍ਹ ਵੀ ਵਿਕਲਪਕ ਸਮਝੇ ਜਾਂਦੇ ਹਨ।

ਫਲੇਕੀ ਟੈਸਟ ਨੂੰ ਸੱਭਿਆਚਾਰਕ ਕਰਜ਼ ਸਮਝੋ: ਉਨ੍ਹਾਂ ਨੂੰ ਜਲਦੀ ਕਰਾਂਟਾਈਨ ਕਰੋ, ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਟਰੈਕ ਕਰੋ, ਅਤੇ “ਠੀਕ ਕਰੋ ਜਾਂ ਹਟਾਓ” ਨੂੰ ਸਾਂਝਾ ਉਮੀਦ ਬਣਾਓ—ਕਿਉਂਕਿ ਭਰੋਸੇਯੋਗ ਸਿਗਨਲ ਭਰੋਸੇਯੋਗ ਸਹਿਯੋਗ ਦੀ ਬਨਿਆਦ ਹਨ।

ਓਨਬੋਰਡਿੰਗ: ਫਰੇਮਵਰਕ ਇੱਕ ਸਿੱਖਣ ਵਾਲਾ ਟੂਲ ਹੈ

ਨਵਾਂ ਇੰਜੀਨੀਅਰ ਤੁਹਾਡੀ ਟੀਮ ਦੀਆਂ ਮੁੱਲਾਂ ਨੂੰ ਪਹਿਲੀ ਗreeਨ ਬਿਲਡ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਦਾ ਹੈ, ਕਿਸੇ ਸਲਾਈਡ ਡੈੱਕ ਤੋਂ ਨਹੀਂ। ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਚੁਪਚਾਪ “ਅਸੀਂ ਇੱਥੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਾਂ” ਸਿਖਾਉਂਦਾ ਹੈ: ਟੈਸਟ ਕਿੱਥੇ ਰਹਿੰਦੇ ਹਨ, ਉਹਨਾਂ ਦਾ ਨਾਮ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ, ਫੇਲ੍ਹ ਕਿਵੇਂ ਪੜ੍ਹਨ, ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਅਸਰਸ਼ਨ ਲਿਖਣ ਲਈ ਕਿੰਨੀ ਰਸਮੀਤਾ ਲੋੜੀਦੀ ਹੈ।

ਰਿਵਾਜ ਜੋ ਸਿੱਖਣ ਬੋਝ ਨੂੰ ਘਟਾਉਂਦੇ ਜਾਂ ਵਧਾਉਂਦੇ ਹਨ

ਸਾਫ ਡਿਫ਼ਾਲਟ ਵਾਲੇ ਫਰੇਮਵਰਕ ਓਨਬੋਰਡਿੰਗ ਨੂੰ ਸਧਾਰਨ ਬਣਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਨਵੇਂ ਆਏ ਵਿਅਕਤੀਆਂ ਨੂੰ ਨਮੂਨੇ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਜਦੋਂ ਰਿਵਾਜ ਅਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ—ਜਾਂ ਟੀਮ ਫਰੇਮਵਰਕ ਨੂੰ ਖੰਡਨ ਕਰ ਰਹੀ ਹੁੰਦੀ ਹੈ—ਨਵੇਂ ਹਾਇਰ ਪਹਿਲੇ ਹਫ਼ਤੇ ਵਿੱਚ “ਇਸ ਨੂੰ ਕਿੱਥੇ ਰੱਖਾਂ?” ਪੁੱਛਦੇ ਰਹਿੰਦੇ ਹਨ, ਇਸ ਦੀ ਥਾਂ ਉਤਪਾਦ ਸਿੱਖਣ।

ਛੋਟੇ ਮਾਪਰੇ ਪੈਟਰਨ ਜਿਹੜੇ ਸ਼ੁਰੂ ਵਿੱਚ ਮਿਆਰੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ:

• ਸੈਟਅੱਪ/ਟਿਅਰਡਾਊਨ: ਟੈਸਟ ਡੇਟਾ ਬਣਾਉਣ ਅਤੇ ਸਾਈਡ-ਇਫੈਕਟਸ ਸਾਫ਼ ਕਰਨ ਲਈ ਇੱਕ ਥਾਂ।
• ਫਿਕਸਚਰ: ਰੀਯੂਜ਼ੇਬਲ "ਨੋਟ ਡੀ- ਗੁੱਡ" ਵਾਲੀ ਵਸਤੂਆਂ ਜੋ ਟੈਸਟਾਂ ਨੂੰ ਛੋਟਾ ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਰੱਖਦੀਆਂ ਹਨ।
• ਹੈਲਪਰ ਅਤੇ ਸ਼ੇਅਰਡ ਯੂਟਿਲਟੀਜ਼: ਲੋਗਿਨ, ਸਮੇਂ ਨਿਯੰਤਰਣ, ਫੈਕਟਰੀਜ਼, ਅਤੇ API ਸਟਬਜ਼ ਲਈ ਇਕ ਛੋਟਾ ਟੂਲਬਾਕਸ—ਇੰਟੈਂਸ਼ਨਲ ਰੱਖੋ ਤਾਂ ਕਿ "ਟੈਸਟ ਯੂਟਿਲਸ" ਦਾ ਡੰਬਲਰ ਨਾ ਬਣ ਜਾਵੇ।

ਸਟਾਰਟਰ ਟੈmplੇਟ ਰਿਪੋ + “ਪਹਿਲਾ ਟੈਸਟ” ਚੈਕਲਿਸਟ

ਓਨਬੋਰਡਿੰਗ ਨੂੰ ਕਾਂਕਰੀਟ ਬਣਾਓ ਇੱਕ ਸਟਾਰਟਰ ਟੈmplੇਟ ਰਿਪੋ (ਜਾਂ ਮੋਨੋਰੇਪੋ ਵਿੱਚ ਇੱਕ ਫੋਲਡਰ) ਦੇ ਨਾਲ ਜੋ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ:

• ਹਰ ਲੇਅਰ (ਯੂਨਿਟ/ਇੰਟੀਗ੍ਰੇਸ਼ਨ) ਲਈ ਇੱਕ ਨਿਊਨਤਮ ਉਦਾਹਰਨ ਟੈਸਟ।
• ਪਹਿਲ-ਤੈਅ ਕੀਤੇ ਕਮਾਂਡ: test, test:watch, test:ci।
• ਟੈਸਟ ਫਾਇਲਾਂ ਲਈ ਵਿਆਚਾਰਪ੍ਰਦ linting/formatting।
• ਇੱਕ ਛੋਟਾ README ਜੋ /engineering/testing-standards 'ਤੇ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

ਨਵੇਂ ਜੁੜਨ ਵਾਲੇ ਲਈ ਪਹਿਲਾ-ਟੈਸਟ ਚੈਕਲਿਸਟ:

1. ਟੈਸਟ ਲੋਕਲ ਤੇ ਅਤੇ ਵਾਚ ਮੋਡ ਵਿੱਚ ਚਲਾਓ।
2. ਇੱਕ ਛੋਟਾ ਯੂਨਿਟ ਟੈਸਟ ਜੋੜੋ ਜੋ ਹਾਲੀਆ ਬਦਲਾਵ ਦੇ ਨੇੜੇ ਹੋਵੇ।
3. ਜਾਣਬੂਝ ਕੇ ਉਸਨੂੰ ਟੁੱਟਣ ਦਿਓ ਤਾਂ ਕਿ ਫੇਲ੍ਹ ਆਉਟਪੁੱਟ ਵੇਖ ਸਕੋ।
4. ਠੀਕ ਕਰੋ, ਬ੍ਰਾਂਚ ਪుష ਕਰੋ, ਅਤੇ CI ਵੇਖੋ।
5. ਰਿਵਿਊ ਦੀ ਬੇਨਤੀ ਕਰੋ ਅਤੇ ਫੀਡਬੈਕ 'ਤੇ ਜਵਾਬ ਦਿਓ।

ਡੌਕਸ ਅਤੇ ਉਦਾਹਰਣ ਓਨਬੋਰਡਿੰਗ ਦੇ ਗੁਣਕ ਵਧਾਉਂਦੇ ਹਨ

ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲੇ ਫਰੇਮਵਰਕ ਡੌਕਸ ਅਤੇ ਕਮਿਊਨিটি ਉਦਾਹਰਣ ਟ੍ਰਾਇਬਲ ਨੌਲਿਜ਼ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। ਉਹਨਾਂ ਫਰੇਮਵਰਕਾਂ ਨੂੰ ਪਸੰਦ ਕਰੋ ਜਿਨ੍ਹਾਂ ਕੋਲ ਸਪਸ਼ਟ ਫੇਲ੍ਹ ਸੁਨੇਹੇ, ਰੱਖ-ਰਖਾਅ ਵਾਲੇ ਗਾਈਡ, ਅਤੇ ਇੱਕ ਮਜ਼ਬੂਤ ਇਕੋਸਿਸਟਮ ਹੈ—ਫਿਰ ਸਾਰੇ-ਵਧੀਆ "ਕਿਵੇਂ-ਕਰੋ" ਪੰਨੇ ਨੂੰ ਆਪਣੀ ਅੰਦਰੂਨੀ ਡੌਕਸ (/engineering/testing-standards) ਤੋਂ ਸੱਧਾ ਜੋੜ ਦਿਓ ਤਾਂ ਨਵੇਂ ਆਏ ਨੂੰ ਖੋਜਣਾ ਨਾ ਪਵੇ।

ਕੋਡ ਰਿਵਿਊ ਨਾਰਮਸ ਟੈਸਟ ਉਮੀਦਾਂ ਨਾਲ ਤੈਅ ਹੁੰਦੇ ਹਨ

ਕੋਡ ਰਿਵਿਊ ਸਿਰਫ਼ ਸਟਾਈਲ ਅਤੇ ਸਹੀਪਣ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਓਥੇ ਹੈ ਜਿੱਥੇ ਟੀਮ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ “ਚੰਗਾ” ਕੀ ਮਤਲਬ ਹੈ। ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਚੁਪਚਾਪ ਉਸ ਗੱਲਬਾਤ ਨੂੰ ਆਕਾਰ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਟੈਸਟ ਜੋੜਨਾ, ਚਲਾਉਣਾ, ਅਤੇ ਸਮਝਣਾ ਕਿੰਨਾ ਆਸਾਨ ਹੈ।

ਟੈਸਟ ਕਿਵੇਂ ਗੱਲਬਾਤ ਨੂੰ ਮੋੜਦੇ ਹਨ

ਜਦੋਂ ਰਿਵਿਊਅਰ ਇੱਕ ਟੈਸਟ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪੜ੍ਹ ਕੇ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ, ਤਾਂ ਰਿਵਿਊ ਟਿੱਪਣੀਆਂ debating ਤੋਂ ਬਦਲ ਕੇ ਸਬੂਤ-ਅਧਾਰਿਤ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਚੰਗੇ ਟੈਸਟ ਸਾਂਝੀ ਭਾਸ਼ਾ ਬਣ ਜਾਂਦੇ ਹਨ: ਉਹ ਐਡਜ ਕੇਸ ਦਸਤਾਵੇਜ਼ ਕਰਦੇ ਹਨ, ਮਨਸੂਖ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦੇ ਹਨ, ਅਤੇ ਜੋਖਮ ਨੂੰ ਵਿਖਾਉਂਦੇ ਹਨ।

ਸਮੇਂ ਦੇ ਨਾਲ, ਟੀਮ ਟੈਸਟਾਂ ਨੂੰ ਬਦਲਾਅ ਦਾ ਹਿੱਸਾ ਮੰਨਣ ਲੱਗਦੀ ਹੈ—ਨਾਕਿ ਇਕ ਵਿਕਲਪਿਕ ਜੁੜਤਾਰ। ਇੱਕ ਪੁਲ-ਰਿਕਵੇਸਟ ਬਿਨਾਂ ਟੈਸਟਾਂ ਦੇ ਹੋਣਾ ਹੋਰ ਵੱਧ ਵਾਰ ਬੈਚ-ਬੈਚ ਸਵਾਲ ਖੜੇ ਕਰਦਾ ਹੈ ਅਤੇ ਮਨਜ਼ੂਰੀ ਪ੍ਰਕਿਰਿਆ ਲੰਬੀ ਕਰਦਾ ਹੈ।

ਅਨੀਕ੍ਰਾਮਿਕਤਾ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਰਿਵਿਊਅਰ ਕਿੰਨੇ ਵਾਰ ਟੈਸਟ ਮੰਗਦੇ ਹਨ

ਜੇ ਫਰੇਮਵਰਕ ਸੈਟਅੱਪ ਨੂੰ ਦਰਦਨਾਕ ਬਣਾ ਦਿੰਦਾ—ਧੀਮੀ ਰਨ, ਉਲਝਣ ਭਰੇ ਮੌਕ, ਨਾਜ਼ੁਕ ਫਿਕਸਚਰ—ਤਾਂ ਰਿਵਿਊਅਰ ਟੈਸਟ ਮੰਗਣ ਵਿੱਚ ਹਿਚਕਿਚਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਜਾਣਦੇ ਹਨ ਇਹ PR ਨੂੰ ਰੁਕਾਵੇਗਾ। ਜੇ ਇਹ ਤੇਜ਼ ਅਤੇ ਸੌਖਾ ਹੈ, ਤਾਂ “ਕਿਰਪਾ ਕਰਕੇ ਇੱਕ ਟੈਸਟ ਜੋੜੋ” ਇੱਕ ਆਮ, ਘੱਟ ਰੁਕਾਵਟ ਵਾਲੀ ਟਿੱਪਣੀ ਬਣ ਜਾਂਦੀ ਹੈ।

ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਡਿਵੈਲਪਰ ਅਨੁਭਵ ਸੰਸਕ੍ਰਿਤੀਕ ਹੁੰਦਾ ਹੈ: ਜੋ ਚੀਜ਼ ਸਹੀ ਕਰਨ ਲਈ ਆਸਾਨ ਹੋਵੇ, ਟੀਮ ਉਹਦੇ ਉਮੀਦ ਵਜੋਂ ਵੱਧ ਲਗਾਤਾਰ ਮੰਗਦੀ ਹੈ।

ਪ੍ਰਾਇਕਟਿਕ ਰਿਵਿਊ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼

ਸਾਦਾ ਨਿਯਮ ਰਿਵਿਊਜ਼ ਨੂੰ ਕੇਂਦ੍ਰਿਤ ਰੱਖਦੇ ਹਨ:

• ਜੋ ਟੁੱਟ ਸਕਦਾ ਹੈ ਉਸਨੂੰ ਟੈਸਟ ਕਰੋ: ਬਿਜ਼ਨਸ ਨਿਯਮ, ਔਖੇ ਐਜ ਕੇਸ, ਅਤੇ ਬਗ ਫਿਕਸ (ਇੱਕ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟ ਜੋੜੋ)।
• ਸਪਸ਼ਟ ਚੀਜ਼ਾਂ ਨਾ ਟੈਸਟ ਕਰੋ: ਫਰੇਮਵਰਕ ਇੰਟਰਨਲ, ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ, ਜਾਂ ਸਰਲ ਗੇਟਰ/ਸੈਟਰ—ਇਹ ਸ਼ੋਰ ਵਧਾਉਂਦੇ ਹਨ।
• ਸਥਿਰ ਸਿਗਨਲ ਨੁੰ дӯст ਰੱਖੋ: ਨਤੀਜਿਆਂ ਅਤੇ ਯੂਜ਼ਰ-ਦਿੱਖਣ ਵਾਲੇ ਵਿਹਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਨਾ ਕਿ ਐਸੀ ਇਮਪ੍ਰੀਮੈਂਟੇਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜੋ ਬਦਲਣਗੀਆਂ।
• ਇਕ PR, ਇਕ ਕਹਾਣੀ: ਟੈਸਟਾਂ ਨੂੰ ਬਦਲਾਅ ਦੀ ਵਿਆਖਿਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਦੂਜਾ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਬਣ ਜਾਣਾ ਚਾਹੀਦਾ।

ਸਾਂਝੀ ਮਾਲਕੀ, ਇਕ ਵੱਖਰਾ ਲੇਨ ਨਹੀਂ

ਸਿਹਤਮੰਦ ਟੀਮਾਂ ਟੈਸਟਾਂ ਨੂੰ ਉਤਪਾਦ ਕੋਡ ਵਾਂਗ ਹੀ ਮੰਨਦੇ ਹਨ: ਹਰ ਕੋਈ ਉਹ ਲਿਖਦਾ, ਹਰ ਕੋਈ ਉਹ ਠੀਕ ਕਰਦਾ, ਅਤੇ ਫੇਲ੍ਹਟ ਟੈਸਟ ਮਰਜ ਨੂੰ ਰੋਕਦੇ ਹਨ ਚਾਹੇ ਕੌਣ ਵੀ “ਮਾਲਕ” ਹੋਵੇ। ਇਹ ਸਾਂਝੀ ਜਵਾਬਦੇਹੀ ਹੈ ਜੋ ਟੈਸਟ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਰੋਜ਼ਾਨਾ ਆਦਤ ਬਣਾਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਕੇਵਲ QA ਦੀ ਚੈਕਪੌਇੰਟ।

CI ਇੰਟੇਗਰੇਸ਼ਨ ਟੈਸਟਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝਾ ਸਮਝੌਤਾ ਬਣਾਦਿੰਦੀ ਹੈ

ਜਦੋਂ ਇੱਕ ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਤੁਹਾਡੇ CI ਪਾਈਪਲਾਈਨ ਨਾਲ ਜੁੜ ਜਾਂਦਾ ਹੈ, ਟੈਸਟ "ਮੇਰਾ ਲੋਕਲ ਰਾਏ" ਨਹੀਂ ਰਹਿੰਦੇ—ਉਹ ਟੀਮ ਦਾ ਸਾਂਝਾ ਸਮਝੌਤਾ ਬਣ ਜਾਂਦੇ ਹਨ। ਹਰ ਪੁਲ-ਰਿਕਵੇਸਟ ਤੇ ਉਹੀ ਚੈੱਕ ਇੱਕੋ ਮਾਹੌਲ ਵਿੱਚ ਚਲਦੇ ਹਨ, ਅਤੇ ਨਤੀਜਾ ਕੌਮਾਂ ਤੱਕ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਜਵਾਬਦੇਹੀ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ: ਫੇਲ੍ਹ ਸਥਾਨਕ ਪ੍ਰੇਸ਼ਾਨੀਆਂ ਨਹੀਂ—ਉਹ ਰੋਕ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਟੀਮ ਸਾਰੀਆਂ ਮਹਿਸੂਸ ਕਰਦੀ ਹੈ।

ਗੇਟਿੰਗ ਸਟੈਂਡਰਡ ਨੂੰ ਡਿਫ਼ਾਲਟ ਬਣਾਦਿੰਦੀ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਟੀਮ CI ਗੇਟਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਕਿ "ਕੀ ਹੋਇਆ" ਦਾ ਮਤਲਬ ਤੈਅ ਕੀਤਾ ਜਾ ਸਕੇ।

ਇੱਕ ਫਰੇਮਵਰਕ ਜੋ CI ਨਾਲ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਇਕੱਠਾ ਹੁੰਦਾ ਹੈ, ਜ਼ਰੂਰੀ ਚੈੱਕ ਬਥਾਂ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਂਦਾ ਹੈ (ਉਦਾਹਰਨ ਵਜੋਂ: ਯੂਨਿਟ ਟੈਸਟ, ਲਿੰਟਿੰਗ, ਅਤੇ ਇੱਕ ਨਿਯੂਨਤਮ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਸੂਟ)। ਕੁੱਲ ਲਾਈਨ-ਗੇਟ ਸ਼ਾਮਲ ਕਰੋ—ਜਿਵੇਂ ਕੋਵਰੇਜ ਜਾਂ ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ ਦਰਜਾ—ਤਾਂ ਤੁਸੀਂ ਵਰਕਫਲੋ ਵਿੱਚ ਮੱਲਾਂ ਐਨਕੋਡ ਕਰ ਰਹੇ ਹੋ: “ਅਸੀਂ ਉਹ ਕੋਡ ਮਰਜ ਨਹੀਂ ਕਰਦੇ ਜੋ ਭਰੋਸਾ ਘਟਾਉਂਦਾ ਹੈ।”

ਕਵਰੇਜ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ, ਇਹ ਇੱਕ ਰੁਝਾਨ ਜਾਂ ਗਾਰਡਰੇਲ ਵਜੋਂ ਵਰਤੋ, ਸਕੋਰਬੋਰਡ ਵਜੋਂ ਨਹੀਂ।

ਫਲੇਕੀ ਟੈਸਟ ਰਿਲੀਜ਼ ਵਿਹਾਰ ਨੂੰ ਤੁਰੰਤ ਬਦਲ ਦਿੰਦੇ ਹਨ

ਫਲੇਕੀ ਟੈਸਟ ਸਿਰਫ ਮਿੰਟਾਂ ਨੂੰ ਖਰਚ ਨਹੀਂ ਕਰਦੇ; ਉਹ ਪੂਰੇ ਪਾਈਪਲਾਈਨ 'ਤੇ ਭਰੋਸਾ ਘਟਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਲੋਕ ਸਿੱਖ ਲੈਂਦੇ ਹਨ ਕਿ ਲਾਲ ਬਿਲਡ "ਅਕਸਰ ਖ਼ੁਦ ਹੀ ਠੀਕ ਹੋ ਜਾਂਦੇ ਹਨ", ਤਾਂ ਉਹ ਫਿੰਗਰ-ਕ੍ਰਾਸਡ ਹੋ ਕੇ ਮਰਜ ਕਰਨ, ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਰੋਕਣ ਜਾਂ ਗੇਟ ਓਵਰਰਾਈਡ ਕਰਨ ਲੱਗਦੇ ਹਨ। ਸੰਘਰਸ਼ ਦੌਰਾਨ, ਫਲੇਕੀ ਸੂਟ ਸੂਚਨਾ ਗੜਬੜ ਕਰ ਦਿੰਦੇ ਹਨ: ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਦੱਸ ਸਕਦੀ ਕਿ ਕੋਈ ਬਦਲਾਵ ਸਹੀ ਤੌਰ ਤੇ ਅੱਗੇ ਵਧਣ ਯੋਗ ਹੈ ਜਾਂ ਰੋਲਬੈਕ ਦੀ ਲੋੜ ਹੈ।

ਜੇ ਤੁਹਾਡਾ ਫਰੇਮਵਰਕ ਫਲੇਕਨੈਸੀ ਦੀ ਨਿਰਣਾਇਕਤਾ ਨੂੰ ਮੁਸ਼ਕਲ ਦਿਵਾਂਦਾ ਹੈ (ਖराब ਰਿਪੋਰਟਿੰਗ, ਕੰਮ-ਨਕਲ-ਰਿੱਟ੍ਰਾਈਜ਼, ਅਸਪਸ਼ਟ ਲੋਗ), ਤਾਂ ਇਹ ਚੁਪਚਾਪ ਜੋਖਮ ਨੂੰ ਆਮ ਕਰ ਦਿੰਦਾ ਹੈ।

pipeline ਵੰਡੋ: ਤੇਜ਼ ਚੈੱਕ vs ਡੂੰਘਾ ਭਰੋਸਾ

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ pipeline ਨੀਅਤ ਵਾਰ ਵੰਡੋ:

• ਹਰ PR ਤੇ ਤੇਜ਼ ਚੈੱਕ: ਤੇਜ਼ ਯੂਨਿਟ ਟੈਸਟ ਅਤੇ ਉੱਚ-ਸਿਗਨਲ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟਾਂ ਦੀ ਇੱਕ ਛੋਟੀ ਸੈਟ
• ਰਾਤ-ਰਾਤ (ਜਾਂ ਨਿਯਤ) ਸੂਟ: ਵਿਆਪਕ ਇੰਟੀਗ੍ਰੇਸ਼ਨ/E2E ਕੋਵਰੇਜ, ਕ੍ਰਾਸ-ਬਰਾਊਜ਼ਰ/ਡਿਵਾਈਸ ਰਨ, ਲੰਮੇ ਸੀਨਾਰੀਓ

ਇਸ ਨਾਲ ਫੀਡਬੈਕ ਤਿੱਖਾ ਰਹਿੰਦਾ ਹੈ ਬਿਨਾਂ ਗਹਿਰਾਈ ਨੂੰ ਵਡਾਉਣ ਦੇ। ਸਭ ਤੋਂ ਵਧੀਆ ਫਰੇਮਵਰਕ-ਤੋਂ-CI ਇੰਟੇਗਰੇਸ਼ਨ ਉਹ ਹੈ ਜੋ “ਸਹੀ ਕੰਮ” ਕਰਨ ਨੂੰ ਸਭ ਤੋਂ ਆਸਾਨ ਬਣਾਦੇ।

ਟੈਸਟ ਰਣਨੀਤੀ: ਕਿਵੇਂ ਫਰੇਮਵਰਕ ਪਾਈਰਮਿਡ ਨੂੰ ਉੱਪਰ ਜਾਂ ਹੇਠਾਂ ਧਕੇਲਦੇ ਹਨ

"ਟੈਸਟ ਪਾਈਰਮਿਡ" ਸਿਰਫ਼ ਇੱਕ ਤਰੀਕਾ ਹੈ ਤੇਜ਼, ਕੇਂਦਰਿਤ ਟੈਸਟਾਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨ ਦਾ ਅਤੇ ਥੋੜੇ ਅਜ਼ੀਮਤੀ, ਧੀਮੇ ਟੈਸਟਾਂ ਦੇ ਨਾਲ। ਫਰੇਮਵਰਕ ਚੁਪਚਾਪ ਉਸ ਸਲੂਟ ਨੂੰ ਧਕੇਲਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਕੁਝ ਟੈਸਟ ਕਿਸਮਾਂ ਨੂੰ ਆਸਾਨ ਅਤੇ ਕੁਝ ਨੂੰ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ।

ਤਿੰਨ ਪੱਧਰ (ਸਧਾਰਨ ਭਾਸ਼ਾ)

ਯੂਨਿਟ ਟੈਸਟ ਇੱਕ ਛੋਟੇ ਕੋਡ ਹਿੱਸੇ (ਜਿਵੇਂ ਇਕ ਫੰਕਸ਼ਨ) ਨੂੰ ਅਲੱਗ ਤੌਰ ਤੇ ਜਾਂਚਦਾ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ ਅਤੇ ਅਕਸਰ ਚਲਾਉਣ ਲਈ ਆਸਾਨ।

ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਕਈ ਹਿੱਸਿਆਂ ਨੂੰ ਇਕੱਠੇ ਕੰਮ ਕਰਦੇ ਵੇਖਦੇ ਹਨ (ਜਿਵੇਂ ਤੁਹਾਡੀ API + ਡਾਟਾਬੇਸ, ਜਾਂ ਇੱਕ ਸਰਵਿਸ + ਕਿਊ)। ਇਹ ਯੂਨਿਟ ਟੈਸਟਾਂ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਧੀਮੇ ਹੁੰਦੇ ਹਨ ਪਰ "ਵਾਇਰਿੰਗ" ਸਮੱਸਿਆਵਾਂ ਫੜ ਲੈਂਦੇ ਹਨ।

End-to-end (E2E) ਟੈਸਟ ਸਿਸਟਮ ਰਾਹੀਂ ਅਸਲੀ ਯੂਜ਼ਰ ਫਲੋਜ਼ ਨੂੰ ਨਕਲ ਕਰਦੇ ਹਨ (ਅਕਸਰ ਬ੍ਰਾਉਜ਼ਰ ਰਾਹੀਂ)। ਇਹ ਉੱਚ ਭਰੋਸਾ ਦਿੰਦੇ ਹਨ ਪਰ ਸਭ ਤੋਂ ਧੀਮੇ ਅਤੇ ਨਾਜ਼ੁਕ ਹੁੰਦੇ ਹਨ।

ਫਰੇਮਵਰਕ ਤੁਹਾਡੀ ਪਾਈਰਮਿਡ ਨੂੰ ਕਿਵੇਂ ਝੁਕਾਉਂਦਾ ਹੈ

ਜੇ ਤੁਹਾਡਾ ਚੁਨਾ ਹੋਇਆ ਫਰੇਮਵਰਕ E2E ਟੈਸਟਾਂ ਨੂੰ ਮਨਪਸੰਦ ਬਣਾਂਦਾ ਹੈ—ਸ਼ਾਨਦਾਰ ਬ੍ਰਾਉਜ਼ਰ ਟੂਲਿੰਗ, ਆਟੋ-ਵੇਟਸ, ਵਿਜ਼ੂਅਲ ਰਨਰ, ਸਧਾਰਨ ਸੈਟਅੱਪ—ਤਾਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ E2E ਟੈਸਟਾਂ ਲਿਖਣ ਵੱਲ ਜਾ ਸਕਦੇ ਹੋ ਜਿਹੜੀਆਂ ਅਸਲ ਵਿੱਚ ਹੇਠਾਂ ਤੇਜ਼ੀ ਨਾਲ ਜਾਂਚ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹੁੰਦੀਆਂ। ਨਤੀਜਾ ਇੱਕ ਧੀਮਾ ਸੂਟ ਹੈ ਜਿਸਨੂੰ ਟੀਮ ਚਲਾਉਣ ਤੋਂ ਪਰਹੇਜ਼ ਕਰਦੀ ਹੈ, ਤੇ ਇੱਕ “ਟੈਸਟ ਫਲੇਕੀ ਹੈ” ਸੰਸਕ੍ਰਿਤੀ ਬਣ ਜਾਂਦੀ ਹੈ।

ਦੂਜੇ ਪਾਸੇ, ਇੱਕ ਯੂਨਿਟ-ਟੈਸਟ ਫਰੇਮਵਰਕ ਜਿਸ ਵਿੱਚ ਭਾਰੀ ਮੌਕਿੰਗ ਯੂਟਿਲਿਟੀਜ਼ ਹਨ, ਟੀਮ ਨੂੰ "ਸਭ ਕੁਝ ਮੌਕ ਕਰੋ" ਵੱਲ ਧਕੇਲ ਸਕਦਾ ਹੈ, ਜਿੱਥੇ ਟੈਸਟ ਗ੍ਰੀਨ ਹੁੰਦੇ ਹਨ ਪਰ ਅਸਲ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੁੱਟ ਸਕਦੀ ਹੈ।

ਇੱਕ ਸਧਾਰਨ ਵੰਡ ਰਹਿਤ ਸੂਤਰ

ਜ਼ਿਆਦातर ਟੀਮਾਂ ਲਈ ਪ੍ਰਾਇਕਟਿਕ ਸ਼ੁਰੂਆਤੀ ਨਿਯਮ:

• ~70% ਯੂਨਿਟ ਟੈਸਟ (ਲਾਜ਼ਮੀ ਲੌਜਿਕ ਲਈ ਸਸਤੀ ਕੋਵਰੇਜ)
• ~20% ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ (ਕਾਂਟ੍ਰੈਕਟ ਅਤੇ ਵਾਇਰਿੰਗ ਮੁੱਦਿਆਂ ਨੂੰ ਫੜਨ ਲਈ)
• ~10% E2E ਟੈਸਟ (ਮੁੱਖ ਯੂਜ਼ਰ ਯਾਤਰਾਵਾਂ ਦੀ ਰੱਖਿਆ ਲਈ)

ਜੋਖਮ ਦੇ ਆਧਾਰ 'ਤੇ ਅਨੁਕੂਲ ਕਰੋ, ਪਰ E2E ਨੂੰ ਇਕ "ਚੁਣਿੰਦਾ ਸੈੱਟ" ਸਮਝੋ ਨ ਕਿ ਡਿਫਾਲਟ।

ਚੇਤਾਵਨੀ ਨਿਸ਼ਾਨ ਜੇ ਤੁਹਾਡੀ ਪਾਈਰਮਿਡ ਉਲਟੀ ਹੈ

• "ਸਾਰੇ E2E": ਬਿਲਡਆਂ ਧੀਮੇ ਹਨ, ਟੈਸਟ ਟਾਈਮਿੰਗ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਛੋਟੇ UI ਬਦਲਾਅ ਅਨਜਾਣੀ ਤੌਰ 'ਤੇ ਅਣਗਿਣਤ ਟੈਸਟ ਨੂੰ ਠਹਿਰਾ ਦਿੰਦੇ ਹਨ।
• "ਸਭ ਕੁਝ ਮੌਕ": ਟੈਸਟ ਗ੍ਰੀਨ ਹਨ ਪਰ ਸਟੇਜਿੰਗ ਲਾਲ ਹੈ; ਬਗ ਅਚੰਭੇ ਵਾਲੇ ਨੇ ਕਿਉਂਕਿ ਟੈਸਟ ਕਦੇ ਅਸਲ ਬਾਊਂਡਰੀਆਂ ਨੂੰ ਨਹੀਂ ਪਰਖੇ।

ਰੱਖ-ਰਖਾਅ ਯੋਗ ਟੈਸਟ ਸਥਾਇਤ ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੇ ਹਨ

ਟੈਸਟ ਆਟੋਮੇਸ਼ਨ ਦੀ ਰੱਖ-ਰਖਾਅਯੋਗਤਾ ਤਿੰਨ ਚੀਜ਼ਾਂ ਬਾਰੇ ਹੈ: ਪੜ੍ਹਨੀਯੋਗਤਾ (ਕੋਈ ਭੀ ਸਮਝ ਸਕੇ ਕਿ ਟੈਸਟ ਕੀ ਸਾਬਿਤ ਕਰ ਰਿਹਾ ਹੈ), ਸਥਿਰਤਾ (ਟੈਸਟ ਅਸਲ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ ਹੋਵੇ, ਬੇਤਰਤੀਬੀ ਕਾਰਨਾਂ ਕਰਕੇ ਨਹੀਂ), ਅਤੇ ਬਦਲਣ ਦੀ ਸੌਖੀ (ਛੋਟੇ ਉਤਪਾਦੀ ਬਦਲਾਅ ਸੂਟ ਨੂੰ ਅੱਧਾ ਨਹੀਂ ਦੇਣੇ ਚਾਹੀਦੇ)।

ਜਦੋਂ ਕੋਈ ਫਰੇਮਵਰਕ ਇਹ ਗੁਣ ਆਸਾਨ ਕਰਦਾ ਹੈ, ਟੀਮਾਂ ਐਸੀਆਂ ਆਦਤਾਂ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਕੋਡ ਗੁਣਵੱਤਾ ਦੀ ਰੱਖਿਆ ਕਰਦੀਆਂ ਹਨ ਬਿਨਾਂ ਦਿਵਸ-ਕੁੱਟ ਹੁੰਦੇ।

ਉਹ ਪੈਟਰਨ ਜੋ ਟੈਸਟ ਸਧਾਰਨ ਰੱਖਦੇ ਹਨ

ਚੰਗੇ ਫਰੇਮਵਰਕ ਟੀਮਾਂ ਨੂੰ ਖੁਦ ਰੀਯੂਜ਼ ਕਰਨ ਵੱਲ ਧਕਾਉਂਦੇ ਹਨ ਬਿਨਾਂ ਮਨਸੂਖਤਾ ਲੁਕਾਉਂਦੇ ਹੋਏ। ਕੁਝ ਪੈਟਰਨ ਜੋ ਮੁੜ-ਵਰਤੋਂ ਘਟਾਉਂਦੇ ਹਨ:

• ਫਿਕਸਚਰ ਆਮ ਪ੍ਰੀਕੰਡਿਸ਼ਨ (ਯੂਜ਼ਰ, ਅਧਿਕਾਰ, ਸੀਡ ਕੀਤੀ ਡੇਟਾ) ਇੱਕ ਥਾਂ 'ਤੇ ਸੈਟ ਕਰਨ ਲਈ।
• ਫੈਕਟਰੀ/ਬਿਲਡਰ ਵਸਤੂਆਂ ਬਣਾਉਣ ਲਈ ਜੋ ਸਮਝਦਾਰ ਡਿਫ਼ਾਲਟ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਉੱਤੇਦਾ ਹੀ ਓਵਰਰਾਈਡ ਕਰਦੇ ਹਨ ਜੋ ਕਿਸੇ ਟੈਸਟ ਲਈ ਲੋੜੀਦਾ ਹੈ।
• ਹੈਲਪਰ ਦੁਬਾਰਾ ਕੀਤੇ ਕਦਮਾਂ ਲਈ (ਜਿਵੇਂ "ਆਰਡਰ ਬਣਾਉ", "ਲੌਗ ਇਨ", "ਆਰਟੀਕਲ ਪਬਲਿਸ਼"), ਜਿਹੜੇ ਕਾਰੋਬਾਰੀ ਕਦਮਾਂ ਦੀ ਤਰ੍ਹਾਂ ਨਾਮਿਤ ਕੀਤੇ ਜਾਂ।

ਸੰਸਕ੍ਰਿਤਿਕ ਪ੍ਰਭਾਵ ਸੁਖਾ ਅਤੇ ਤਾਕਤਵਰ ਹੈ: ਟੈਸਟ ਦਸਤਾਵੇਜ਼ ਵਾਂਗ ਪੜ੍ਹਦੇ ਹਨ, ਅਤੇ ਨਵੀਂ ਤਬਦੀਲੀ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਫਿਕਸਚਰ ਜਾਂ ਫੈਕਟਰੀ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਕਈ ਟੈਸਟਾਂ ਨੂੰ ਸਮੇਂ ਨਾਲ ਨਿਰੰਤਰ ਅਪਡੇਟ ਕਰ ਦਿੰਦਾ ਹੈ।

ਐਂਟੀ-ਪੈਟਰਨ ਜੋ ਟੀਮ ਦਾ ਭਾਰ ਵਧਾਉਂਦੇ ਹਨ

ਕੁੱਝ ਅਮਲ ਟੀਮ ਨੂੰ ਆਹਿਸਤਗੀ ਨਾਲ ਤੰਗ ਕਰ ਦਿੰਦੇ ਹਨ:

• ਸ਼ੇਅਰਡ ਮਿਊਟੇਬਲ ਸਟੇਟ (ਇੱਕ ਟੈਸਟ ਦੀ ਸੈਟਅੱਪ ਦੂਜੇ ਵਿੱਚ ਲੀਕ ਹੋ ਜਾਂਦੀ ਹੈ), ਜੋ ਅੰਤਰਵਿਰਤੀ ਫੇਲ ਹੌਦਾ ਹੈ।
• ਓਵਰ-ਮੌਕਿੰਗ ਜੋ ਮੌਕ ਸੈਟਅੱਪ ਨੂੰ ਅਸਲ ਵਿਹਾਰ ਤੋਂ ਵੱਧ ਟੈਸਟ ਕਰਵਾਉਂਦੀ ਹੈ, ਰਿਲੀਜ਼ ਵਿਸ਼ਵਾਸ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ।
• ਨਾਜ਼ੁਕ ਸੈਲੇਕਟਰ ਅਤੇ ਬਹੁਤ ਵਿਸ਼ੇਸ਼ ਅਸਰਸ਼ਨ ਜੋ ਨਿਰਦੋਕ UI ਜਾਂ ਸ਼ਬਦ-ਬਦਲਾਵਾਂ 'ਤੇ ਟੁੱਟ ਜਾਂਦੇ ਹਨ।

ਟੈਸਟਾਂ ਦੀ ਰੀਫੈਕਟਰਿੰਗ ਨੂੰ ਅਸਲ ਕੰਮ ਸਮਝੋ

ਸਥਿਰ ਇੰਜੀਨੀਅਰਿੰਗ ਟੈਸਟ ਰੀਫੈਕਟਰਾਂ ਨੂੰ ਉਤਪਾਦ ਰੀਫੈਕਟਰਾਂ ਵਾਂਗ ਹੀ ਗੰਭੀਰਤਾ ਨਾਲ ਮੰਨਦੀ ਹੈ: ਯੋਜਿਤ, ਸਮੀਖਿਆ ਅਤੇ ਲਗਾਤਾਰ—"ਬਾਅਦ ਵਿੱਚ ਸਾਫ਼ ਕਰਾਂਗੇ" ਨਹੀਂ। ਇਹ ਉਮੀਦ ਤੈਅ ਕਰੋ ਕਿ ਰੱਖ-ਰਖਾਅਯੋਗ ਟੈਸਟ ਬਿਹਤਰ ਬਣਾਉਣਾ ਫੀਚਰ ਦੀ ਡਿਲਿਵਰੀ ਦਾ ਹਿੱਸਾ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ CI ਸੂਟ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸਿਗਨਲ ਬਣ ਜਾਵੇਗਾ ਨਾ ਕਿ ਪਿਛੋਕੜ ਸ਼ੋਰ।

ਤੁਸੀਂ ਜੋ ਮਾਪਦੇ ਹੋ ਉਹ ਤੁਹਾਡੀ ਕੀਮત ਬਣ ਜਾਂਦਾ ਹੈ

ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਸਿਰਫ਼ ਚੈੱਕ ਨਹੀਂ ਚਲਾਉਂਦੇ—ਉਹ ਕੁਝ ਸਿਗਨਲਾਂ ਨੂੰ ਦੇਖਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਕੁਝ ਹੋਰਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਸੌਖਾ। ਜਿਵੇਂ ਹੀ ਇਹ ਸਿਗਨਲ ਪੁਲ-ਰਿਕਵੇਸਟ, CI ਸੰਖੇਪ, ਅਤੇ ਟੀਮ ਡੈਸ਼ਬੋਰਡਾਂ ਵਿੱਚ ਦਿੱਖਦੇ ਹਨ, ਉਹ ਆਹਿਸਤੈ ਉਹ ਪ੍ਰਭਾਰ ਬਣ ਜਾਂਦੇ ਹਨ। ਇਹ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਜੇ ਮੈਟ੍ਰਿਕਸ ਅਸਲ ਗੁਣਵੱਤਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ, ਅਤੇ ਨੁਕਸਾਨਦਾਇਕ ਜਦੋਂ ਉਹ ਗਲਤ ਵਿਹਵਾਰ ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ ਹਨ।

ਮੈਟ੍ਰਿਕਸ: ਲਾਭਦਾਇਕ ਪਰ ਆਸਾਨੀ ਨਾਲ ਗੇਂਡੇ ਜਾ ਸਕਦੇ ਹਨ

ਇੱਕ ਨੰਬਰ ਫੈਸਲੇ ਸੌਖੇ ਬਣਾਉਂਦਾ ਹੈ ("ਟੈਸਟ ਗ੍ਰੀਨ ਹਨ"), ਪਰ ਇਹ ਖਰਾਬ ਪ੍ਰੇਰਨਾ ਵੀ ਜਨਮ ਦੇ ਸਕਦਾ ਹੈ ("ਧੀਮੇ ਸੂਟ ਸਕਿਪ ਕਰਕੇ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰੋ" ਜਾਂ "ਫਰਮਾ-ਨੁਕਸਾਨ ਯੂਨਿਟ ਟੈਸਟਾਂ ਨਾਲ ਕੋਵਰੇਜ ਵਧਾਓ ਜੋ ਕੁਝ ਵੀ ਨਹੀਂ ਜਾਂਚਦੇ")। ਵਧੀਆ ਮੈਟ੍ਰਿਕਸ ਸਿਹਤ ਨੂੰ ਵਰਣਨ ਕਰਦੇ ਹਨ; ਬੁਰੇ ਮੈਟ੍ਰਿਕਸ ਟਾਰਗੇਟ ਬਣ ਜਾਂਦੇ ਹਨ।

ਵਿਹਾਰ ਸੁਧਾਰਨ ਵਾਲੇ ਪ੍ਰਾਇਕਟਿਕ ਮੈਟ੍ਰਿਕਸ

ਹਲਕੀ-ਫੁਲਕੀ ਸੈੱਟ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਵਧੀਆ ਹੁੰਦੀ ਹੈ:

• ਟੈਸਟ ਰਨਟਾਈਮ (ਕੁੱਲ ਅਤੇ ਪ੍ਰਤੀ-ਸੂਟ): ਉਹ ਜਗ੍ਹਾ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਫੀਡਬੈਕ ਤੇਜ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਫਲੇਕ ਦਰ (ਅੰਤਰਵਿਰਤੀ ਫੇਲ): ਭਰੋਸਾ ਮੁੱਦਿਆਂ ਨੂੰ ਉਜਾਗਰ ਕਰਦਾ ਹੈ। ਜੇ ਡਿਵੈਲਪਰ ਰੀ-ਰਨ ਉਮੀਦ ਕਰਦੇ ਹਨ, ਤਾਂ ਰਿਵਿਊਜ਼ ਅਤੇ ਰਿਲੀਜ਼ ਸਲੋ ਹੋ ਜਾਂਦੇ ਹਨ।
• ਬਾਹਰ ਨਿਕਲੀਆਂ ਖਾਮੀਆਂ (ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਮਿਲੀਆਂ): ਟੈਸਟ ਨਿਵੇਸ਼ ਨੂੰ ਗਾਹਕ ਪ੍ਰਭਾਵ ਨਾਲ ਜੋੜਦਾ ਹੈ ਬਿਨਾਂ ਵਿਅਕਤੀਆਂ ਨੂੰ ਦੋਸ਼ ਦਿਤੇ।
• ਟੈਸਟ ਫੇਲ੍ਹ ਲਈ MTTR (ਮੀਨ ਟਾਈਮ ਟੂ ਰਿਪੇਅਰ): ਮਾਪਦਾ ਹੈ ਕਿ ਟੀਮ CI ਟੁੱਟਣ 'ਤੇ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਭਰੋਸਾ بحਾਲ ਕਰਦੀ ਹੈ।

ਕੋਵਰੇਜ ਨੂੰ ਇਕ ਇਸ਼ਾਰਾ ਸਮਝੋ, ਸਾਬਿਤ ਨਹੀਂ

ਕੋਵਰੇਜ ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿੱਥੇ ਇੱਕੋ ਵੀ ਟੈਸਟ ਨਹੀਂ ਹਨ, ਜੋ ਕੀ ਕੀਮਤੀ ਹੈ। ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਟੈਸਟ ਮੈਨਿੰਗਫੁਲ ਹਨ ਜਾਂ ਮਹੱਤਵਪੂਰਨ ਵਿਹਾਰ ਸੁਰੱਖਿਅਤ ਹਨ। ਇੱਕ ਉੱਚ ਪ੍ਰਤੀਸ਼ਤ ਵੀ ਐਜ ਕੇਸ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਸੀਮਾਵਾਂ, ਅਤੇ ਅਸਲੀ ਯੂਜ਼ਰ ਫਲੋਜ਼ ਨੂੰ ਛੱਡ ਸਕਦੀ ਹੈ।

ਕੋਵਰੇਜ ਨੂੰ ਬਲਾਈਂਡ ਸਪਾਟ ਵਾਂਗ ਦੇਖੋ, ਫਿਰ ਸਮੀਖਿਆ ਕਰੋ ਕਿ ਟੈਸਟ ਨਤੀਜਿਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ—ਨ ਕਿ ਕਿਸੇ ਇੰਪਲਿਮੈਂਟੇਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ।

ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਮਾਲਕੀ "ਟੈਸਟ ਸਿਹਤ" ਨੂੰ ਜ਼ਿੰਦਾ ਰੱਖਦੇ ਹਨ

ਡੈਸ਼ਬੋਰਡ ਨੂੰ ਛੋਟਾ ਅਤੇ ਦਿਖਣਯੋਗ ਰੱਖੋ (CI ਸੰਖੇਪ + ਇੱਕ ਹਫਤਾਵਾਰ ਰੁਝਾਨ)। ਸਪਸ਼ਟ ਮਾਲਕੀ ਨਿਰਧਾਰਤ ਕਰੋ: ਘੁੰਮਣ ਵਾਲਾ "ਟੈਸਟ ਸਿਹਤ" ਸਟੀਵਰਡ ਜਾਂ ਖੇਤਰ/ਟੀਮ ਵੱਲੋਂ ਮਾਲਕੀ। ਮਕਸਦ ਤੇਜ਼ ਫੈਸਲੇ ਲੈਣਾ ਹੈ: ਫਲੇਕਨੈਸੀ ਠੀਕ ਕਰੋ, ਸੂਟ ਤੇਜ਼ ਕਰੋ, ਅਤੇ ਟੁੱਟੇ ਟੈਸਟਾਂ ਨੂੰ ਆਮ ਬਣਨ ਨਾਲ ਰੋਕੋ।

ਆਪਣੀ ਟੀਮ ਨਾਲ ਮਿਲਣ ਵਾਲਾ ਫਰੇਮਵਰਕ ਚੁਣੋ

ਇੱਕ ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਸਿਰਫ ਇੱਕ ਤਕਨੀਕੀ ਚੋਣ ਨਹੀਂ—ਇਹ ਇੱਕ ਉਮੀਦਾਂ ਦਾ ਨਿਰਧਾਰਕ ਹੈ ਕਿ ਲੋਕ ਕਿਵੇਂ ਲਿਖਦੇ, ਰਿਵਿਊ ਕਰਦੇ, ਅਤੇ ਕੋਡ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ। “ਸਾਰਥਕ” ਫਰੇਮਵਰਕ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਵਾਸਤੇ ਲਗਾਤਾਰ, ਹਕੀਕਤੀ ਡੇਡਲਾਈਨਾਂ ਹੇਠਾਂ, ਘੱਟ friction ਨਾਲ ਵਰਤੀ ਜਾ ਸਕੇ।

ਪ੍ਰਾਇਕਟਿਕ ਮਾਪਦੰਡ (ਜੋ ਡਿਵੈਲਪਰ ਹਰ ਦਿਨ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ)

ਫੀਚਰ ਲਿਸਟ ਤੋਂ ਅੱਗੇ ਦੇਖੋ ਅਤੇ ਫਿੱਟ 'ਤੇ ਧਿਆਨ ਦਿਓ:

• ਭਾਸ਼ਾ ਨਾਲ਼ ਮੇਲ: ਕੀ ਇਹ ਤੁਹਾਡੀ ਮੁੱਖ ਐਪਲੀਕੇਸ਼ਨ ਭਾਸ਼ਾ ਅਤੇ ਰUNTIME ਨਾਲ ਮਿਲਦਾ ਹੈ?
• ਇਕੋਸਿਸਟਮ ਸਹਾਇਤਾ: ਮੈਚਿਓਰ ਡੌਕਸ, ਕਮਿਊਨਿਟੀ ਉਦਾਹਰਣ, ਪਲੱਗਇਨ, ਰਿਪੋਰਟਰ, ਮੌਕਿੰਗ ਟੂਲ।
• IDE ਇੰਟਿਗ੍ਰੇਸ਼ਨ: ਟੈਸਟਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ, ਫੇਲ੍ਹ 'ਤੇ ਜੰਪ ਕਰਨਾ, ਅਤੇ ਇੱਕ ਟੈਸਟ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾਉਣਾ।
• ਸਿੱਖਣ ਵਕ਼ਤ: ਕੀ ਨਵੇਂ ਹਾਇਰ ਆਪਣੇ ਪਹਿਲੇ ਹਫ਼ਤੇ ਵਿੱਚ ਇੱਕ ਚੰਗਾ ਟੈਸਟ ਲਿਖ ਸਕਦਾ ਹੈ?

ਗੈਰ-ਤਕਨੀਕੀ ਮਾਪਦੰਡ (ਕੀ ਇਸਨੂੰ ਟਕਸਾਲੀ ਬਣਾ ਦਿੰਦੇ ਹਨ)

ਇਹ ਕਾਰਕ ਅਕਸਰ ਨਿਰਧਾਰਕ ਹੁੰਦੇ ਹਨ ਕਿ ਚੋਣ ਲੰਬੇ ਸਮੇਂ ਲਈ ਕਾਇਮ ਰਹੇਗੀ:

• ਟੀਮ ਅਨੁਭਵ: ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇਸ ਨਾਲ ਖੁਦ ਵਾਲੇ ਲੋਕ ਹਨ?
• ਹਾਇਰਿੰਗ ਪੁਲ: ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਕੀ ਇਸ ਦਾ ਗਿਆਨ ਮਿਲਦਾ ਹੈ, ਜਾਂ ਤੁਹਾਨੂੰ ਸਭ ਨੂੰ ਰੀ-ਟ੍ਰੇਨ ਕਰਨਾ ਪਵੇਗਾ?
• ਦੀਰਘਕਾਲੀ ਸਮਰਥਨ: ਰਿਲੀਜ਼ ਕੈਡੈਂਸ, ਮੇਂਟੇਨਰਜ਼, ਤੁਹਾਡੇ ਸਟੈਕ ਨਾਲ ਅਨੁਕੂਲਤਾ, ਅਤੇ ਇੱਕ ਸਾਫ ਅਪਗਰੇਡ ਰਸਤਾ।

ਫੈਸਲੇ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਪਾਇਲਟ ਚਲਾਓ

ਇੱਕ ਪ੍ਰਤੀਨਿਧੀ ਸਰਵਿਸ ਜਾਂ ਮੌਡੀਊਲ ਚੁਣੋ ਅਤੇ 2–3 ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਇੱਕ ਹਫ਼ਤਾ ਜਾਂ ਦੋ ਲਈ ਕਰੋ। ਮਾਪੋ:

• ਸੈਟਅੱਪ ਸਮਾਂ: ਜ਼ੀਰੋ ਤੋਂ ਪਹਿਲੇ ਮੀਨਿੰਗਫੁਲ ਟੈਸਟ ਤੱਕ।
• ਫਲੇਕਨੈਸੀ: ਕੀ ਟੈਸਟ ਉਤਪਾਦ ਬਦਲਾਵਾਂ ਤੋਂ ਬਿਨਾਂ ਫੇਲ ਹੁੰਦੇ ਹਨ?
• ਡਿਵੈਲਪਰ ਖੁਸ਼ੀ: ਇੱਕ ਛੋੱਟਾ ਸਰਵੇ: “ਕੀ ਇਹ ਲਿਖਣਾ, ਚਲਾਉਣਾ, ਅਤੇ ਡੀਬੱਗ ਕਰਨਾ ਆਸਾਨ ਸੀ?”

ਫੈਸਲਾ ਚੈੱਕਲਿਸਟ + "ਕੋਈ ਅਫਸੋਸ ਨਾ ਹੋਵੇ" ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾ

ਚੈੱਕਲਿਸਟ: ਤੇਜ਼ ਲੋਕਲ ਰਨ, ਸਪਸ਼ਟ ਫੇਲ੍ਹ ਆਉਟਪੁੱਟ, ਸਥਿਰ CI ਇੰਟੇਗਰੇਸ਼ਨ, ਵਧੀਆ ਮੌਕਿੰਗ/ਫਿਕਸਚਰ, ਪੈਰਲੈਲਾਈਜ਼ੇਸ਼ਨ ਸਹਾਇਤਾ, ਸਰਗਰਮ ਰੱਖ-ਰਖਾਅ, ਅਤੇ ਟੀਮ ਦੀ ਚਾਹ।

ਮਾਈਗਰੇਸ਼ਨ ਰੂਪਰੇਖਾ: ਨਵੇਂ ਕੋਡ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਪੁਰਾਣੇ ਟੈਸਟ CI ਵਿੱਚ ਚਲਾਉਂਦੇ ਰੱਖੋ, ਸ਼ੇਅਰਡ ਹੈਲਪਰ/ਅਡਾਪਟਰ ਜੋੜੋ, ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਬਦਲਦੀਆਂ ਖੇਤਰਾਂ ਨੂੰ ਪਹਿਲਾਂ ਮਾਈਗਰੇਟ ਕਰੋ, ਅਤੇ ਇੱਕ ਤਾਰੀਖ ਤੈਅ ਕਰੋ ਜਦ ਪੁਰਾਣਾ ਫਰੇਮਵਰਕ read-only ਹੋ ਜਾਵੇ।

ਅਪਣਾਉਣ ਯੋਜਨਾ: ਸੰਸਕ੍ਰਿਤੀ ਬਦਲਾਅ ਨੂੰ ਟਿਕਾੜਾ ਬਨਾਓ

ਨਵੇਂ ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਨੂੰ ਗ੍ਰਹਿਣ ਕਰਨਾ ਇੱਕ ਟੂਲ-ਸਵੈਪ ਤੋਂ ਵੱਧ ਹੈ—ਇਹ ਸਾਂਝੇ ਉਮੀਦਾਂ ਤੈਅ ਕਰਨ ਬਾਰੇ ਹੈ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ “ਸਹੀ ਕੰਮ” ਸੌਖਾ, ਡਿਫ਼ਾਲਟ ਕੰਮ ਬਣ ਜਾਵੇ।

ਇੱਕ ਰੋਲਆਉਟ ਯੋਜਨਾ ਜੋ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ

ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਸਟੈਂਡਰਡ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਇੱਕ ਪੰਨੇ 'ਤੇ ਫਿੱਟ ਹੋਵੇ: ਨਾਮਕਰਨ ਨਿਯਮ, ਟੈਸਟਾਂ ਦੀ ਬਣਤਰ, ਕਦੋਂ ਮੌਕ ਕਰਨਾ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਲਈ "ਚੰਗੀ ਕੋਵਰੇਜ" ਕੀ ਮਤਲਬ ਹੈ।

ਟੈmplੇਟ ਜੋ ਕਿਸੇ ਨੂੰ ਸਿਫ਼ਤ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪਾਉਂਦੇ ਜੋੜੋ: ਨਮੂਨਾ ਟੈਸਟ ਫਾਇਲ, ਕਾਮਨ ਫਿਕਸਚਰਾਂ ਲਈ ਹੈਲਪਰ, ਅਤੇ CI ਜੌਬ ਸਨਿੱਪੇਟ। ਫਿਰ ਛੋਟੇ ਟਰੇਨਿੰਗ ਸੈਸ਼ਨ (30–45 ਮਿੰਟ) ਚਲਾਓ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਇਸ ਨੂੰ ਕਿਵੇਂ ਵਰਤੇਗੀ ਤੇ ਕੇਂਦਰਿਤ ਹੋਣ, ਨਾ ਕਿ ਹਰ ਫੀਚਰ 'ਤੇ।

ਧੀਰੇ-ਧੀਰੇ ਅਪਣਾਓ:

• ਨਵੇਂ ਕੋਡ ਤੁਰੰਤ ਨਵੇਂ ਫਰੇਮਵਰਕ ਦਾ ਉਪਯੋਗ ਕਰੇ।
• ਪੁਰਾਣੇ ਕੋਡ 'ਤੇ ਛੇੜ-ਛਾੜ ਕਰਨ 'ਤੇ "ਉਹਨੂੰ ਬਿਹਤਰ ਛੱਡੋ" ਅਪਡੇਟ ਕਰੋ (ਇਕ-ਦੋ ਟੈਸਟ ਮਾਈਗਰੇਟ ਕਰੋ ਜਦ ਤੁਸੀਂ ਓਥੇ ਹੋ)।
• ਪੁਰਾਣੇ ਫਰੇਮਵਰਕ ਵਿੱਚ ਨਵੇਂ ਟੈਸਟ ਰਚਨਾ ਲਈ ਇੱਕ ਟਾਰਗੇਟ ਤਾਰੀਖ ਰੱਖੋ।

ਲੇਗੇਸੀ ਟੈਸਟ ਅਤੇ ਮਿਲੇ ਜੁਲੇ ਫਰੇਮਵਰਕ (ਬਿਨਾਂ ਉਪਦਾੜੇ)

ਮਿਕਸ-ਫਰੇਮਵਰਕ ਠੀਕ ਹਨ ਜੇ ਤੁਸੀਂ ਹੱਦਾਂ ਸਪਸ਼ਟ ਰੱਖੋ। CI ਵਿੱਚ ਰਨਰ ਅਲੱਗ ਰੱਖੋ, ਨਤੀਜੇ ਇਕੱਠੇ ਰਿਪੋਰਟ ਕਰੋ, ਅਤੇ ਦੱਸੋ ਕਿ ਕਿਹੜੇ ਖੇਤਰ "ਲੇਗੇਸੀ" ਹਨ। ਵੱਡੇ-ਬੈਂਗ ਰੀਰਾਈਟਜ਼ ਤੋਂ ਬਚੋ; ਬਦਲਾਅ ਲੈ ਕੇ ਜਦੋਂ ਉਹ ਭਰੋਸਾ/ਸਥਿਰਤਾ ਲਿਆਉਂਦੇ ਹਨ (ਫਲੇਕੀ ਸੂਟ, ਧੀਮੇ ਸੂਟ, ਮੁੱਖ ਰਾਹ)।

ਜੇ ਤੁਹਾਨੂੰ ਦੋਹਾਂ ਨੂੰ ਕੁਝ ਸਮੇਂ ਲਈ ਰੱਖਣਾ ਪਵੇ, ਤਾਂ ਇੱਕ ਸਾਂਝਾ ਨਿਯਮ ਤੈਅ ਕਰੋ: ਹਾਰੋਂ ਆਉਂਦੇ ਫੇਲ੍ਹ ਮਰਜ ਨੂੰ ਰੋਕਦੇ ਹਨ ਭਾਵੇਂ ਉਹ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਤੋਂ ਆਉਂਦੇ ਹੋਣ।

ਇੱਕ ਟੈਸਟਿੰਗ ਪਲੇਬੁੱਕ ਅਤੇ ਰੈਫਰੰਸ ਪ੍ਰੋਜੇਕਟ ਬਣਾਓ

ਇੱਕ ਸਧਾਰਨ ਪਲੇਬੁੱਕ ਪੰਨਾ ਪ੍ਰਕਾਸ਼ਤ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, /docs/testing-playbook) ਜਿਸ ਵਿੱਚ:

• ਲੋਕਲ ਤੇ ਟੈਸਟ ਕਿਵੇਂ ਲਿਖਣ ਤੇ ਚਲਾਉਣੇ ਹਨ
• ਯੂਨਿਟ vs ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟਾਂ ਦੇ ਉਦਾਹਰਣ
• ਆਮ ਟrouਬਲਸ਼ੂਟਿੰਗ ਅਤੇ ਟਾਈਮਆਉਟ

ਇੱਕ ਸਪਸ਼ਟ ਪ੍ਰੋਜੈਕਟ ਸਟ੍ਰੱਕਚਰ ਬਹਿਸ ਘਟਾਉਂਦਾ ਹੈ:

/tests
  /unit
  /integration
  /fixtures
/src
  ...

ਫਰੇਮਵਰਕ ਰਿਵਾਜਾਂ ਨੂੰ ਸਾਫ ਨਾਰੀਟਾਂ, ਆਸਾਨ ਟੈmplੇਟ, ਲਗਾਤਾਰ CI ਜ਼ੋਰ, ਅਤੇ ਇੱਕ ਮਾਈਗਰੇਸ਼ਨ ਰਸਤਾ ਜੋ ਪ੍ਰਗਤੀ ਨੂੰ ਪੂਰਨਤਾ ਦੇ ਉਪਰ ਅਹਿਮੀਅਤ ਦਿੰਦਾ ਹੈ ਜੋੜ ਕੇ ਹੀ ਸੰਸਕ੍ਰਿਤੀ ਮਜ਼ਬੂਤ ਹੁੰਦੀ ਹੈ।

Koder.ai ਕਿਵੇਂ “ਚੰਗੇ ਡਿਫਾਲਟ” ਹਕੀਕਤ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ

ਜੇ ਤੁਸੀਂ ਆਦਤਾਂ ਨੂੰ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ, ਸਭ ਤੋਂ ਤੇਜ਼ ਫਾਇਦਾ ਅਕਸਰ ਸੈਟਅੱਪ friction ਘਟਾਉਣਾ ਹੁੰਦਾ ਹੈ। Koder.ai ਵਰਤਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਛੋਟਾ “golden path” ਪ੍ਰੋਜੈਕਟ ਸਟਰੱਕਚਰ ਅਤੇ ਟੈਸਟ ਕਮਾਂਡਾਂ (ਜਿਵੇਂ test, test:watch, test:ci) ਚੈਟ ਵਿੱਚ ਤਿਆਰ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ, ਫਿਰ ਫਰੇਮਵਰਕ ਰਿਵਾਜਾਂ ਨੂੰ ਟੀਮ ਦੇ playbook ਨਾਲ ਮਿਲਾਉਂਦੀਆਂ ਹਨ।

Koder.ai ਚੈਟ-ਚਲਿਤ ਵਰਕਫਲੋ ਤੋਂ ਪੂਰੇ ਵੈੱਬ/ਸਰਵਰ/ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਅਤੇ ਸਰੋਤ ਕੋਡ ਰਿਪੋ ਤੋਂ ਐਕਸਪੋਰਟ ਕਰਨ ਦੇ ਯੋਗ ਹੈ—ਇਹ ਇੱਕ ਪ੍ਰਯੋਗਾਤਮਕ ਪਾਈਲਟ ਲਈ ਪ੍ਰਾਇਕਟਿਕ ਤਰੀਕਾ ਹੈ (CI ਵਾਇਰਿੰਗ ਸਮੇਤ) ਜਿਸ ਤੋਂ ਪਹਿਲਾਂ ਤੁਸੀਂ ਪੂਰੀ ਟੀਮ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਲਈ ਕਹੋ। ਟੂਲ ਦੀ ਚੋਣ ਅਹੰਕਾਰ ਧਾਰਕ ਹੈ, ਪਰ “ਸਹੀ ਕੰਮ” ਕਰਨ ਦੀ ਲਾਗਤ ਘਟਾਉਣਾ ਹੀ ਮਿਆਰ ਨੂੰ ਸੰਸਕ੍ਰਿਤੀ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।