01 ਦਸੰ 2025·8 ਮਿੰਟ
ਚੈਟ-ਜਨਰੇਟ ਕੀਤੀਆਂ ਐਪਾਂ ਦੀ ਟੈਸਟਿੰਗ: ਪਹਿਲਾਂ ਕੀ ਟੈਸਟ ਕਰਨਾ ਅਤੇ ਕੀ ਛੱਡਣਾ
React, Go API ਅਤੇ Flutter ਵਿੱਚ chat-ਜਨਰੇਟ ਕੀਤੀਆਂ ਐਪਾਂ ਲਈ ਪ੍ਰਾਥਮਿਕ ਟੈਸਟ ਯੋਜਨਾ: ਘੱਟੋ-ਘੱਟ ਯੂਨਿਟ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅਤੇ e2e ਚੈਕ ਜੋ ਬਹੁਤ ਸਾਰੇ ਰਿਗ੍ਰੈਸ਼ਨਾਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ।
React, Go API ਅਤੇ Flutter ਵਿੱਚ chat-ਜਨਰੇਟ ਕੀਤੀਆਂ ਐਪਾਂ ਲਈ ਪ੍ਰਾਥਮਿਕ ਟੈਸਟ ਯੋਜਨਾ: ਘੱਟੋ-ਘੱਟ ਯੂਨਿਟ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅਤੇ e2e ਚੈਕ ਜੋ ਬਹੁਤ ਸਾਰੇ ਰਿਗ੍ਰੈਸ਼ਨਾਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ।
ਚੈਟ ਦੁਆਰਾ ਬਣਾਈਆਂ ਕੋਡਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਇਕੋ ਥਾਵਾਂ 'ਤੇ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਕੋਡ ਅਕਸਰ ਇਕੱਤਰ ਕੀਤੇ ਹੋਏ ਸਹੀ-ਲੱਗਦੇ ਪਿੰਸਿਆਂ ਤੋਂ ਬਣਿਆ ਹੁੰਦਾ ਹੈ ਜੋ ਇਕ ਦੂਜੇ ਨਾਲ ਨੇੜੇ ਤੌਰ 'ਤੇ ਪਰਖੇ ਨਹੀਂ ਜਾਂਦੇ। ਜ਼ਿਆਦਾਤਰ ਫੀਚਰ ਸਫਲ ਰਸਤੇ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਪਰ ਅਸਲ ਯੂਜ਼ਰ ਜੇ ਤੇਜ਼ੀ ਨਾਲ ਕਲਿੱਕ ਕਰਨ, ਅਜੀਬ ਇਨਪੁਟ ਭੇਜਣ ਜਾਂ ਥੋੜ੍ਹਾ ਪੁਰਾਣਾ ਕਲਾਇੰਟ ਵਰਤਣ, ਤਾਂ ਇਹ ਟੁੱਟ ਜਾਂਦੇ ਹਨ।
ਖਤਰਾ ਬਹੁਤ ਹਿੱਸਾ glue code ਵਿੱਚ ਹੁੰਦਾ ਹੈ: ਉਹ ਛੋਟੇ ਹਿੱਸੇ ਜੋ ਸਕ੍ਰੀਨਾਂ ਨੂੰ API ਕਾਲਾਂ ਨਾਲ ਜੋੜਦੇ ਹਨ, API responses ਨੂੰ UI state ਵਿੱਚ ਮੈਪ ਕਰਦੇ ਹਨ, ਅਤੇ ਯੂਜ਼ਰ ਇਨਪੁੱਟ ਨੂੰ ਡੇਟਾਬੇਸ ਲਿਖਾਈ ਵਿੱਚ बदलਦੇ ਹਨ। ਇਹ ਹਿੱਸੇ ਬੋਰਿੰਗ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਘੱਟ ਧਿਆਨ ਮਿਲਦਾ ਹੈ, ਪਰ ਇਹ ਸਾਰੇ ਐਪ ਦੇ ਫਲੋ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੇ ਹਨ।
ਰਿਗ੍ਰੈਸ਼ਨ ਉਹਨਾਂ ਬਾਊਂਡਰੀਆਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਭੀ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਦੋ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਇੱਕ ਕਾਂਟਰੈਕਟ ਸਾਂਝਾ ਕਰਨਾ ਹੁੰਦਾ ਹੈ। UI ਇੱਕ ਆਕਾਰ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, API ਦੂਜਾ ਰੀਟਰਨ ਕਰਦਾ ਹੈ। API ਮੰਨਦਾ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਇੱਕ ਮੁੱਲ ਸਵੀਕਾਰ ਕਰੇਗਾ, ਫਿਰ ਕੋਈ constraint ਉਸਨੂੰ ਰੀਜੈਕਟ ਕਰਦਾ ਹੈ। ਜਾਂ ਇੱਕ ਲੇਅਰ ਨਾਮ, ਟਾਈਪ, ਜਾਂ ਡੀਫੌਲਟ ਬਦਲਦੀ ਹੈ ਅਤੇ ਹੋਰ ਲੇਅਰ ਉਸਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਦੀਆਂ।
ਉਹੀ ਫੇਲਿਅਰ ਪੁਆਇੰਟ بار-ਬਾਰ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:
ਤੇਜ਼ੀ ਨੇ ਇਹਨੂੰ ਹੋਰ ਨੁਕਸਾਨਕਾਰੀ ਬਣਾਇਆ ਹੈ। ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੇਜ਼ iteration ਨੂੰ ਉਤਸਾਹ ਦਿੰਦੇ ਹਨ: ਤੁਸੀਂ ਪ੍ਰੰਪਟ ਦਿੰਦੇ ਹੋ, ਦੁਬਾਰਾ ਜਨਰੇਟ ਕਰਦੇ ਹੋ, ਰੀਫੈਕਟਰ ਕਰਦੇ ਹੋ, ਅਤੇ ਅੱਗੇ ਵੱਧਦੇ ਹੋ। ਇਹ ਤਾਕਤ ਹੈ। ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਛੋਟੇ ਬਦਲਾਅ ਅਕਸਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਬਾਊਂਡਰੀ ਟੁੱਟਣ ਦੀ ਸੰਭਾਵਨਾ ਵਧ ਜਾਂਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਟੈਸਟ ਚਾਹੀਦੇ ਹਨ ਜੋ ਤੇਜ਼ ਚਲਨ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਫੇਲ ਹੋਣ।
ਮਕਸਦ ਭਰੋਸਾ ਹੈ, ਨ ਕਿ ਪਰਫੈਕਸ਼ਨ। ਤੁਸੀਂ ਹਰ ਲਾਈਨ ਸਹੀ ਸਾਬਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੇ। ਤੁਸੀਂ ਉਹਨਾਂ ਬਦਲਾਵਾਂ ਨੂੰ ਫੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ ਜੋ ਤੁਹਾਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਸ਼ਰਮਿੰਦਾ ਕਰ ਸਕਦੇ ਹਨ: ਫਾਰਮ ਜੋ ਹੁਣ ਸੇਵ ਨਹੀਂ ਹੁੰਦਾ, API ਜੋ ਸਹੀ ਰਿਕਵੇਸਟ ਰੀਜੈਕਟ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦੇਂਦਾ ਹੈ, ਜਾਂ ਡੇਟਾਬੇਸ ਅਪਡੇਟ ਜੋ ਖੁਮਾਰਾ ਤੌਰ ਤੇ ਕਿਸੇ ਫੀਲਡ ਨੂੰ ਲਿਖਣਾ ਬੰਦ ਕਰ ਦੇਂਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਣ ਉਮੀਦ ਮਦਦ ਕਰਦੀ ਹੈ: ਪਹਿਲਾਂ contracts ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਯੂਜ਼ਰ ਰਸਤੇ ਸੁਰੱਖਿਅਤ ਕਰੋ। ਬਾਕੀ ਸਮਾਂ ਬਾਅਦ ਇੰਝ ਨਾ ਕਰੋ—ਜਦੋਂ ਤਕ ਇਹ ਸਬੂਤ ਨਾ ਦੇਵੇ ਕਿ ਇਹ ਠੀਕ ਨਹੀਂ ਹੈ।
ਚੈਟ-ਜਨਰੇਟ ਕੀਤੇ ਕੋਡ ਵਿੱਚ, ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਆਮ ਤੌਰ 'ਤੇ ਕੰਪਾਇਲੇਸ਼ਨ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਹੈ ਕਿ ਛੋਟੇ ਬਦਲਾਅ ਉਸ ਵਿਹਾਰ ਨੂੰ ਤੋੜਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਸਪੱਅਸ਼ਟ ਮੰਨਦੇ ਸੀ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਸਿਖਰਲੇ ਖਤਰਿਆਂ ਨੂੰ ਸਾਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਨਾਮ ਦਿਓ। ਜੇ ਕੋਈ ਬੱਗ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਹਿੱਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਜਲਦੀ ਮਹਿੰਗਾ ਪੈ ਸਕਦਾ ਹੈ:
ਫਿਰ ਉਹ ਸਭ ਤੋਂ ਛੋਟੀ ਟੈਸਟ ਸੈਟ ਚੁਣੋ ਜੋ ਅਸਲ ਯੂਜ਼ਰ ਫਲੋਜ਼ ਅਤੇ ਹੇਠਾਂ ਵਾਲੇ API ਕਾਂਟਰੈਕਟ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ। ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਹਰ ਕੋਰ ਫਲੋ ਲਈ ਇੱਕ happy path ਅਤੇ ਇੱਕ “ਬੁਰਾ ਇਨਪੁਟ” ਕੇਸ। ਉਦਾਹਰਣ ਲਈ, “create item” ਨੂੰ success ਅਤੇ ਇੱਕ validation failure (required field missing) ਟੈਸਟ ਕਰੋ, ਕਿਉਂਕਿ ਦੋਹਾਂ ਆਮ ਤੌਰ 'ਤੇ prompts ਬਦਲਣ 'ਤੇ ਟੁੱਟਦੇ ਹਨ।
ਫਿਰ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ merge ਤੋਂ ਪਹਿਲਾਂ ਫੜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਤੇ release ਤੋਂ ਪਹਿਲਾਂ ਕੀ। Merge ਤੋਂ ਪਹਿਲਾਂ ਦੇ ਟੈਸਟ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। Release ਤੋਂ ਪਹਿਲਾਂ ਦੇ ਟੈਸਟ ਹੋ ਸਕਦੇ ਹਨ ਹੌਲੀ ਅਤੇ ਵਿਆਪਕ।
ਸਧਾਰਣ ਪ੍ਰਾਇਰਟੀ ਸਕੇਲ ਵਿਵਾਦ ਘਟਾਉਂਦੀ ਹੈ:
Concrete ਉਦਾਹਰਣ: React ਐਪ ਵਿੱਚ “Change password” ਫੀਚਰ ਜਿਸਦਾ Go API ਅਤੇ Flutter client ਵੀ ਹੈ।
P0: API ਕਮਜੋਰ passwords ਨੂੰ ਰੀਜੈਕਟ ਕਰੇ, API stored hash ਅਪਡੇਟ ਕਰੇ, ਅਤੇ ਦੋਵੇਂ clients failure 'ਤੇ error message ਦਿਖਾਉਣ।
P1: rate limiting ਅਤੇ session expiry।
P2: pixel-perfect UI states।
ਜੇ ਤੁਸੀਂ chat-generated apps (ਜਿਨ੍ਹਾਂ ਵਿੱਚ Koder.ai ਵਰਗੇ ਟੂਲ ਨਾਲ ਬਣੇ ਪ੍ਰੋਜੈਕਟ ਵੀ ਸ਼ਾਮਲ ਹਨ) ਨੂੰ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ 80/20 ਨਜ਼ਰੀਅਤ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਕਈ ਭੰਗੂਰ ਟੈਸਟਾਂ ਤੋਂ ਬਚਾਏਗੀ ਜੋ ਹਮੇਸ਼ਾ ਅਸਲ ਯੂਜ਼ਰ ਦੁਆਰਾ ਮਹਿਸੂਸ ਕੀਤੀਆਂ ਗਈਆਂ ਨੁਕਸਾਨੀਆਂ ਨੂੰ ਮਿਸ ਕਰਦੀਆਂ ਹਨ।
React ਰਿਗ੍ਰੈਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਥਾਵਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ: ਛੋਟੇ ਲਾਜਿਕ ਗਲਤੀਆਂ (ਡੇਟਾ shaping, validation) ਅਤੇ UI state ਜੋ ਹਕੀਕਤ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ (loading, errors, disabled buttons)। ਸ਼ੁਰੂਆਤ ਉਥੇ ਕਰੋ ਜਿੱਥੇ ਨੁਕਸਾਨ ਯੂਜ਼ਰਾਂ ਨੂੰ ਪਹੁੰਚਦਾ ਹੈ।
ਜੇ ਕਿਸੇ ਫੰਕਸ਼ਨ ਦੇ ਸਪਸ਼ਟ ਇਨਪੁਟ ਅਤੇ ਆਊਟਪੁੱਟ ਹਨ, ਤਾਂ ਕਿਸੇ ਵੀ UI ਦੇ ਮਥੇ 'ਤੇ ਟੈਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸਨੂੰ ਟੈਸਟ ਕਰੋ। ਇਹ ਟੈਸਟ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ, ਘੱਟ flaky ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਹ ਤੁਹਾਨੂੰ ਛੋਟੀ-ਛੋਟੀ ਲਾਈਨਾਂ ਵਾਲੀਆਂ ਤਬਦੀਲੀਆਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ ਜੋ ਬਹੁਤ ਕੁਝ ਤੋੜ ਸਕਦੀਆਂ ਹਨ।
ਚੰਗੇ ਪਹਿਲੇ ਟਾਰਗਟ: date ਅਤੇ currency formatters, field validators, API response → view model mapping, reducers ਜਾਂ state machines ਜੋ ਸਕ੍ਰੀਨਾਂ ਚਲਾਉਂਦੇ ਹਨ।
ਇਸ ਤੋਂ ਬਾਅਦ, ਕੁਝ component ਟੈਸਟ ਲਿਖੋ ਉਹਨਾਂ ਸਕ੍ਰੀਨਾਂ ਲਈ ਜੋ ਲੋਕ ਕੰਮ ਪੂਰਾ ਕਰਨ ਲਈ ਵਰਤਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ ਸਤਹੀ snapshots ਦੇ ਬਦਲੇ, ਇੱਕ ਛੋਟੀ ਗਿਣਤੀ ਵਾਲੇ ਟੈਸਟ ਵਰਤੋ ਜੋ ਯੂਜ਼ਰ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ: ਫਾਰਮ ਵਿੱਚ ਟਾਈਪ ਕਰੋ, ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰੋ, ਅਤੇ ਜੋ ਯੂਜ਼ਰ ਵੇਖਦਾ ਹੈ ਉਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਉਨ੍ਹਾਂ UI states 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਟੁੱਟਦੇ ਹਨ: ਫਾਰਮ validation ਅਤੇ submit ਵਿਹਾਰ, disabled states (double-submit ਬਚਾਓ ਸਮੇਤ), loading ਅਤੇ retry, error rendering, ਅਤੇ empty vs results states.
ਜਿਸ ਵੀ ਚੀਜ਼ ਨੂੰ ਨੈਟਵਰਕ ਨਾਲ ਗੱਲ ਕਰਨੀ ਹੁੰਦੀ ਹੈ, ਉਸਨੂੰ boundary 'ਤੇ ਮੌਕ ਕਰੋ। ਆਪਣੀ API client ਨੂੰ seam ਵਜੋਂ ਵਰਤੋ: request shape (method, path, ਮੁੱਖ query params, ਅਤੇ payload) Assert ਕਰੋ, ਫਿਰ component ਨੂੰ realistic response ਫੀਡ ਕਰੋ। ਇਹ contract drift ਨੂੰ ਪਹਿਲੇ ਪੱਧਰ 'ਤੇ ਫੜਦਾ ਹੈ, ਖਾਸਕਰ ਜਦੋਂ ਬੈਕਐਂਡ ਤੇਜ਼ੀ ਨਾਲ ਜਨਰੇਟ ਜਾਂ ਸੋਧਿਆ ਜਾ ਰਿਹਾ ਹੋਵੇ।
ਇੱਕ ਨਿਯਮ ਜੋ ਹਰ ਵੇਲੇ ਫਾਇਦਾ ਪਹੁੰਚਾਉਂਦਾ ਹੈ: ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਬੱਗ ਨੂੰ ਠੀਕ ਕਰੋ, ਇੱਕ ਟੈਸਟ ਜੋੜੋ ਜੋ ਦੁਬਾਰਾ ਉਸੇ ਬੱਗ ਦੀ ਵਾਪਸੀ 'ਤੇ fail ਹੋ ਜਾਵੇ। ਉਦਾਹਰਣ ਵਜੋਂ, ਜੇ ਕੋਲ ਕਦੇ Koder.ai-generated ਪੇਜ਼ userId ਭੇਜਦਾ ਸੀ id ਦੀ ਥਾਂ, ਤਾਂ ਇੱਕ ਟੈਸਟ ਜੋੜੋ ਜੋ outgoing payload keys ਨੂੰ verify ਕਰਦਾ ਹੋਵੇ।
Go handlers ਸਹੀ ਦਿਖ ਸਕਦੇ ਹਨ ਪਰ ਛੋਟੀਆਂ ਲਾਜਿਕ ਗੈਪ ਛੁਪਾ ਸਕਦੇ ਹਨ ਜੋ ਵਾਸਤਵਿਕ ਬੱਗ ਬਣ ਜਾਂਦੇ ਹਨ। ਸਭ ਤੋਂ ਤੇਜ਼ ਜਿੱਤ ਉਹ ਟੈਸਟ ਹਨ ਜੋ ਇਨਪੱਟ, permissions, ਅਤੇ ਉਹ ਨਿਯਮ ਜੋ ਡਾਟਾ ਨੂੰ ਮਿਊਟੇਟ ਕਰਦੇ ਹਨ, ਪੱਕੇ ਕਰਦੇ ਹਨ।
Request validation ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਚੈਟ-ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਖਾਲੀ strings, ਵੱਧ ਲੰਬਾਈਆਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਗਲਤ ਡੀਫੌਲਟ ਲਗਾ ਸਕਦਾ ਹੈ। ਉਹਨਾਂ payloads ਨਾਲ handler (ਜਾਂ ਉਸ ਦੀ validation ਫੰਕਸ਼ਨ) ਨੂੰ ਕਾਲ ਕਰਨ ਵਾਲੇ ਟੈਸਟ ਲਿਖੋ ਜੋ ਖਰਾਬ ਹਨ ਅਤੇ ਸਪੱਸ਼ਟ 400 response ਅਤੇ ਉਪਯੋਗੀ error assert ਕਰੋ।
ਅਗਲੇ, edge 'ਤੇ auth ਅਤੇ permissions ਨੂੰ ਲਾਕ ਕਰੋ। ਇੱਕ ਆਮ ਰਿਗ੍ਰੈਸ਼ਨ ਹੈ “auth ਮੌਜੂਦ ਹੈ, ਪਰ ਗਲਤ role ਅਜੇ ਵੀ update ਕਰ ਸਕਦਾ ਹੈ।” Happy path ਅਤੇ ਕੁਝ forbidden ਕੇਸ ਟੈਸਟ ਕਰੋ ਇੱਕ user context ਨਾਲ request ਬਣਾਕੇ ਅਤੇ handler ਜਾਂ middleware ਨੂੰ ਕਾਲ ਕਰਕੇ।
ਫਿਰ ਉਹ ਬਿਜਨਸ ਰੂਲਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਡਾਟਾ ਨੂੰ ਮਿਊਟੇਟ ਕਰਦੇ ਹਨ। Create, update, delete, ਅਤੇ ਦੇ ਕੋਈ ਵੀ idempotent endpoints (ਜਿਵੇਂ “create if not exists”) ਨੂੰ ਕੜੇ ਟੈਸਟ ਮਿਲਣੇ ਚਾਹੀਦੇ ਹਨ। ਇੱਥੇ ਛੋਟਾ ਰੀਫੈਕਟਰ ਅਕਸਰ duplicates ਆਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ, ਲਾਜ਼ਮੀ state transitions ਛੱਡ ਜਾਣ ਜਾਂ immutable ਫੀਲਡਾਂ ਦੀ ਅਣਜਾਣ ਬਦਲੀ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ।
Error mapping ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ। ਤੁਹਾਡੀ API ਨੂੰ ਆਮ ਫੇਲਿਆਂ ਨੂੰ ਸਹੀ ਸਟੇਟਸ ਕੋਡ ਵਿੱਚ ਕਨਵਰਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: bad input (400), not found (404), conflict (409), ਅਤੇ unexpected errors (500). ਯੂਨੀਟ ਟੈਸਟਾਂ ਨੂੰ status ਅਤੇ ਇੱਕ ਸਥਿਰ error shape ਦੋਹਾਂ assert ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਕਿ clients ਟੁੱਟਣ ਨਾ।
ਉੱਚ-ROI ਚੈਕ ਜੋ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਕਵਰ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ: required fields ਅਤੇ defaults, role ਪ੍ਰਤੀ permission checks, idempotency, ਅਤੇ ਆਮ ਫੇਲਿਆਂ ਅਤੇ status codes ਵਿੱਚ ਸਾਫ਼ mapping।
Table-driven tests edge cases ਨੂੰ ਪੜ੍ਹਨ ਯੋਗ ਰੱਖਦੇ ਹਨ:
tests := []struct{
name string
body string
wantStatus int
}{
{"missing name", `{"name":""}`, 400},
{"too long", `{"name":"aaaaaaaaaaaaaaaa"}`, 400},
}
ਚੈਟ-ਜਨਰੇਟ ਕੀਤੀਆਂ ਐਪਾਂ ਵਿੱਚ Flutter ਦੀਆਂ ਬੱਗਾਂ ਅਕਸਰ ਛੋਟੀਆਂ client-side ਧਾਰਨਾਵਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ: ਇੱਕ ਫੀਲਡ ਜੋ ਕਦੇ-ਕਦੇ null ਹੁੰਦੀ ਹੈ, ਇੱਕ date ਜੋ ਵੱਖਰਾ ਫਾਰਮੈਟ ਵਿੱਚ ਆਉਂਦੀ ਹੈ, ਜਾਂ ਇੱਕ ਸਕ੍ਰੀਨ ਜੋ retry ਦੇ ਬਾਅਦ ਲੋਡਿੰਗ ਵਿੱਚ ਫਸ ਜਾਂਦੀ ਹੈ। ਕੁਝ ਫੋਕਸਡ ਟੈਸਟ ਜ਼ਿਆਦਾਤਰ ਇਹਨਾਂ ਨੂੰ ਸਹੀ ਸਮੇਂ 'ਤੇ ਫੜ ਸਕਦੇ ਹਨ।
ਸ਼ੁਰੂਆਤ data mapping ਨਾਲ ਕਰੋ। ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ JSON ਅਤੇ ਤੁਹਾਡੇ Dart ਮਾਡਲਜ਼ ਦੀ ਬਾਊਂਡਰੀ ਹੈ। ਅਸਲੀ-ਲੱਗਣ ਵਾਲੇ payloads fromJson ਵਿੱਚ ਫੀਡ ਕਰੋ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਤੁਸੀਂ missing fields, renamed keys, ਅਤੇ ਅਜੀਬ ਮੁੱਲਾਂ ਨੂੰ ਸੰਭਾਲਦੇ ਹੋ। Enums ਅਤੇ dates ਆਮ ਮੁੱਦੇ ਹਨ: ਨਵਾਂ enum value ਐਪ ਨੂੰ crash ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਅਤੇ parsing ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ fail ਹੋਣਾ ਚਾਹੀਦਾ (ਸਪਸ਼ਟ error ਨਾਲ) ਨਾ ਕਿ silently ਗਲਤ ਮੁੱਲ ਉਤਪੰਨ ਕਰ ਦੇਵੇ।
ਅਗਲੇ, state transitions ਟੈਸਟ ਕਰੋ। ਤੁਸੀਂ BLoC, Provider, Riverpod ਜਾਂ simple setState ਵਰਤੋ, ਜੋ ਯੂਜ਼ਰ ਹਰ ਰੋਜ਼ ਦੇਖਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਲਾਕ ਕਰੋ: first load, refresh, error, ਅਤੇ retry। ਇਹ ਟੈਸਟ ਸਸਤੇ ਹਨ ਅਤੇ ਆਮ “ਸਪੀਨ ਹੋ ਕੇ ਰਹਿ ਜਾਣ” ਸਮੱਸਿਆ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਫੜ ਲੈਂਦੇ ਹਨ।
ਇੱਕ ਛੋਟੀ ਸੈੱਟ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਫਾਇਦਾ ਦੇਂਦੀ ਹੈ:
Concrete ਉਦਾਹਰਣ: ਇੱਕ “Create Project” ਸਕ੍ਰੀਨ ਜੋ Koder.ai ਨਾਲ ਬਣੀ ਹੋਵੇ, ਪ੍ਰੋਜੈਕਟ ਨਾਮ ਅਤੇ region ਲੈਂਦੀ ਹੋਵੇ। ਯੂਨੀਟ-ਟੈਸਟ ਕਰੋ ਕਿ ਖਾਲੀ ਨਾਮ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ, whitespace ਟ੍ਰਿਮ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਅਜਿਹਾ region value ਜੋ ਪਹਿਲਾਂ ਨਹੀਂ ਸੀ ਆਇਆ dropdown ਨੂੰ crash ਨਾ ਕਰੇ।
Golden UI tests ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਕਮ ਰੱਖੋ। ਸਿਰਫ਼ ਕੁਝ ਸਥਿਰ ਸਕ੍ਰੀਨਾਂ ਲਈ ਵਰਤੋ ਜਿੱਥੇ layout regressions ਵਾਕਈ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ—ਜਿਵੇਂ login screen, ਪ੍ਰਾਇਮਰੀ ਡੈਸ਼ਬੋਰਡ, ਜਾਂ critical checkout/create flow।
ਜਦੋਂ ਤੁਸੀਂ chat ਟੂਲ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਸਭ ਤੋਂ ਦਰਦਨਾਕ ਬੱਗ ਲੇਅਰਾਂ ਦੇ ਵਿਚਕਾਰ ਆਉਂਦੇ ਹਨ: React ਪੇਜ਼ API ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, Go handler Postgres ਨੂੰ ਲਿਖਦਾ ਹੈ, ਫਿਰ UI ਇੱਕ ਅਜਿਹਾ response shape ਮੰਨ ਲੈਂਦੀ ਹੈ ਜੋ ਬਦਲ ਗਿਆ। ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਉਹ ਕ੍ਰਾਸ-ਲਏਰ ਬ੍ਰੇਕਸ ਫੜਨ ਲਈ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਮਦਦਗਾਰ ਹਨ ਬਿਨਾਂ ਹਰ ਚੀਜ਼ ਟੈਸਟ ਕੀਤੇ।
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਹਰ ਕੋਰ resource (users, projects, orders ਆਦਿ) ਲਈ ਇਕ ਅਸਲ Postgres-backed path end-to-end ਟੈਸਟ ਕਰੋ। ਹਰ edge case ਨਹੀਂ—ਸਿਰਫ਼ ਇੱਕ happy path ਜੋ ਵਾਇਰਿੰਗ ਕੰਮ ਕਰਦੀ ਹੈ ਇਹ ਸਾਬਤ ਕਰੇ।
ਛੋਟੇ, ਉੱਚ-ਸਿਗਨਲ चੈਕ ਸ਼ੁਰੂ ਕਰੋ:
ਇਹ ਟੈਸਟਾਂ ਲਈ ਅਸਲੀ Postgres instance ਵਰਤੋ (ਅਕਸਰ ਇੱਕ disposable database)। ਸਿਰਫ਼ ਜ਼ਰੂਰੀ seed ਕੀਤੀਆਂ ਚੀਜ਼ਾਂ ਪਾਉ, ਹਰ ਟੈਸਟ ਤੋਂ ਬਾਅਦ cleanup ਕਰੋ, ਅਤੇ assertions ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖੋ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ: saved data ਸਹੀ ਹੈ, permissions ਲਾਗੂ ਹਨ, ਅਤੇ clients responses ਨੂੰ parse ਕਰ ਸਕਦੇ ਹਨ।
ਉਦਾਹਰਣ: “Create Project” ਫੀਚਰ। Go integration test POST /projects ਨੂੰ ਹਿੱਟ ਕਰਦਾ ਹੈ, 201 response ਚੈੱਕ ਕਰਦਾ ਹੈ, ਫਿਰ ਪ੍ਰੋਜੈਕਟ ਫੈਚ ਕਰਦਾ ਹੈ ਅਤੇ name ਅਤੇ owner ID ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ। React integration test create form submit ਕਰਦਾ ਹੈ ਅਤੇ success state 'ਤੇ ਨਵੇਂ name ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ। Flutter тест projects list ਖੋਲ੍ਹਦਾ, ਪ੍ਰੋਜੈਕਟ ਬਣਾਂਦਾ, ਅਤੇ refresh ਤੋਂ ਬਾਅਦ ਇਹ ظاہر ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਐਪਾਂ ਜਨਰੇਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਟੈਸਟ ਵੀ ਤੁਹਾਨੂੰ ਬਚਾਉਂਦੇ ਹਨ ਜਦੋਂ ਦੁਬਾਰਾ ਜਨਰੇਟ ਕੀਤੇ UI ਜਾਂ handlers ਗਲਤ payload shape ਜਾਂ error format ਕਰ ਦੇਂ।
E2E ਟੈਸਟ ਤੁਹਾਡਾ "ਕੀ ਐਪ end-to-end ਕੰਮ ਕਰਦੀ ਹੈ?" ਸੁਰੱਖਿਆ ਜਾਲ ਹਨ। ਉਹ ਸਭ ਤੋਂ ਕੀਮਤੀ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਛੋਟੇ ਅਤੇ ਨਿਰਵਿਕਾਰੀ ਹੁੰਦੇ ਹਨ: smoke tests ਜੋ ਇਹ ਸਾਬਤ ਕਰਦੇ ਹਨ ਕਿ React, Go API, Postgres, ਅਤੇ Flutter ਕਿਆ-ਕਿਆ ਬਾਕੀ ਰਹਿੰਦਾ ਹੈ।
ਸਿਰਫ਼ ਕੁਝ ਯਾਤ੍ਰਾਵਾਂ ਚੁਣੋ ਜੋ ਪੈਸਾ ਜਾਂ ਦਰਦ-ਭਰੇ ਨਤੀਜੇ ਹੇਠਾਂ ਲਿਆਉਂਦੀਆਂ ਹਨ ਜੇ ਉਹ ਟੁੱਟ ਜਾਣ: sign in/out, create a record, edit and save, search/filter ਅਤੇ result ਖੋਲ੍ਹਣਾ, ਅਤੇ checkout/payment (ਜੇ ਹੈ)।
ਪਹਿਲਾਂ ਇੱਕ browser ਅਤੇ ਇੱਕ device profile 'ਤੇ ਚਲਾਓ (ਜਿਵੇਂ Chrome ਵੈੱਬ ਲਈ ਅਤੇ ਇੱਕ ਆਮ ਫੋਨ ਸਾਈਜ਼ ਮੋਬਾਈਲ ਲਈ)। ਹੋਰ browsers ਜਾਂ ਡਿਵਾਈਸਾਂ 'ਤੇ ਫੈਲਾਓ ਤਦ ਹੀ ਜਦੋਂ ਗਾਹਕਾਂ ਨੇ ਅਸਲੀ ਸਮੱਸਿਆ ਰਿਪੋਰਟ ਕੀਤੀ ਹੋਵੇ।
ਸਥਿਰਤਾ ਇੱਕ ਫੀਚਰ ਹੈ। ਟੈਸਟ deterministic ਬਣਾਓ ਤਾਂ ਕਿ ਉਹ ਤਬ ਹੀ fail ਕਰਨ ਜਦੋਂ ਕੁਝ ਵਾਕਈ ਟੁੱਟਿਆ ਹੋਵੇ:
E2E ਨੂੰ ਮੁੱਖ path validate ਕਰਨ ਲਈ ਵਰਤੋ, ਹਰ edge case ਲਈ ਨਹੀ—edge cases unit ਅਤੇ integration tests ਵਿੱਚ ਰਹਿਣ।
ਸਭ ਤੋਂ ਤੇਜ਼ ਢੰਗ ਟਾਈਮ ਬਰਬਾਦ ਕਰਨ ਦਾ ਹੈ ਉਹ ਟੈਸਟ ਲਿਖਣਾ ਜੋ thorough ਲੱਗਦੇ ਹਨ ਪਰ ਅਸਲ ਬੱਗ ਨਹੀਂ ਫੜਦੇ। ਇੱਕ ਛੋਟੀ, ਫੋਕਸਡ ਸੈੱਟ ਵੱਧ ਸਰੇਗਾ ਕਿਸੇ ਵਿਸਤ੍ਰਿਤ ਨੈੱਟ ਤੋਂ ਜੋ ਕਿਸੇ ਨੂੰ ਭਰੋਸਾ ਨਹੀਂ।
Snapshot tests React ਅਤੇ Flutter ਵਿੱਚ ਆਮ ਜਾਲ ਹਨ। ਵੱਡੇ snapshots harmless ਕਾਰਨਾਂ (copy tweaks, layout shifts, ਛੋਟੇ ਰੀਫੈਕਟਰ) ਲਈ ਬਦਲਦੇ ਹਨ, ਇਸ ਲਈ ਟੀਮਾਂ ਜਾਂ ਤਾਂ noisy updates ਕਬੂਲ ਕਰ ਲੈਂਦੀਆਂ ਹਨ ਜਾਂ failures ਤੇ ਧਿਆਨ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। snapshots ਸਿਰਫ਼ ਬਹੁਤ ਛੋਟੀ, ਸਥਿਰ ਸਤਹ ਲਈ ਰੱਖੋ—ਕਿਸੇ ਛੋਟੀ formatter output ਲਈ, ਨਾ ਕਿ ਪੂਰੇ ਸਕ੍ਰੀਨ ਲਈ।
ਹੋਰ ਇੱਕ ਸੌਖਾ ਛੱਡ: third-party libraries ਦੀ ਟੈਸਟਿੰਗ। ਤੁਹਾਨੂੰ React Router, date picker, ਜਾਂ HTTP client ਕੰਮ ਕਰਦੇ ਹੋਏ ਸਾਬਤ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਬਜਾਏ ਇਸਦੇ, ਆਪਣਾ integration point ਟੈਸਟ ਕਰੋ: ਜਿੱਥੇ ਤੁਸੀਂ ਇਸਨੂੰ configure ਕਰਦੇ ਹੋ, data ਨੂੰ ਉਸ ਵਿੱਚ ਮੈਪ ਕਰਦੇ ਹੋ, ਜਾਂ ਉਸਦੇ errors ਨੂੰ ਹੈਂਡਲ ਕਰਦੇ ਹੋ।
Styling tests ਅਕਸਰ ਮੁੱਲ ਨਹੀਂ ਰੱਖਦੇ। ਵਿਹਾਰਿਕ ਚੈੱਕ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ (ਜਿਵੇਂ form invalid ਹੋਣ 'ਤੇ ਬਟਨ disabled ਹੋਣਾ, 401 'ਤੇ error message ਦਿਖਾਉਣਾ) ਪਿਕਸਲ-ਸਤਰਵਾਲੇ assertions ਨਾਲੋਂ। ਜਦੋਂ styling ਵਿਹਾਰ ਜਾਂ ਕੰਪਲਾਇੰਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੋਵੇ ਤਾਂ ਛੋੜੋ ਇੱਕ special exception (ਕਾਨਟ੍ਰਾਸਟ ਯੋਗਤਾਵਾਂ, ਫੋਕਸ outlines ਆਦਿ)।
ਇੱਕੋ ਗੈਰੰਟੀ ਨੂੰ ਹਰ ਲੇਅਰ 'ਤੇ ਡੁਪਲੀਕੇਟ ਨਾ ਕਰੋ। ਜੇ ਤੁਸੀਂ Go API integration test ਵਿੱਚ assertion ਕਰਦੇ ਹੋ ਕਿ unauthorized requests 401 ਰਿਟਰਨ ਕਰਦੇ ਹਨ, ਤਾਂ ਸੰਭਵਤ: ਤੁਹਾਨੂੰ ਇਹੋ ਹੀ assertion unit tests ਅਤੇ e2e ਵਿੱਚ ਦੋਹਰਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ।
Performance ਟੈਸਟਿੰਗ ਕੀਮਤੀ ਹੈ—ਪਰ ਬਾਅਦ ਵਿੱਚ। ਉਡੀਕ ਕਰੋ ਜਦੋਂ ਤੁਹਾਡਾ app flow stable ਹੋਵੇ (ਉਦਾਹਰਣ ਲਈ, Koder.ai-generated feature ਹਰ ਰੋਜ਼ ਬਦਲਣਾ ਬੰਦ ਕਰ ਦੇਵੇ), ਫਿਰ ਇਕ ਜਾਂ ਦੋ measurable targets ਸੈੱਟ ਕਰੋ ਅਤੇ ਨਿਰੰਤਰ ਟਰੈਕ ਕਰੋ।
ਮਾਨ ਲਓ ਤੁਸੀਂ ਇੱਕ ਸਿੰਪਲ ਫੀਚਰ ਸ਼ਿਪ ਕਰਦੇ ਹੋ: signed-in user ਆਪਣਾ profile edit ਕਰਦਾ ਅਤੇ email ਬਦਲਦਾ। ਇਹ ਚੰਗਾ canary ਹੈ ਕਿਉਂਕਿ ਇਹ UI state, API ਨਿਯਮ, ਅਤੇ client caching ਨੂੰ ਛੂਹਦਾ ਹੈ।
ਇੱਥੇ ਘੱਟੋ-ਘੱਟ ਟੈਸਟ ਸੈੱਟ ਹੈ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਸਾਰੇ ਰਿਗ੍ਰੈਸ਼ਨ ਫੜ ਲੈਂਦਾ ਹੈ ਬਿਨਾਂ ਪੂਰੀ ਟੈਸਟ ਸੂਟ ਬਣਾਉਣ ਦੇ।
updated_at ਬਦਲਦਾ ਹੈ) ਜਦੋਂ email ਬਦਲਦਾ ਹੈ।ਇਹ ਸੈੱਟ ਆਮ breakpoints ਨੂੰ ਟਾਰਗੇਟ ਕਰਦਾ ਹੈ: React ਵਿੱਚ UI validation ਅਤੇ disabled states, Go ਵਿੱਚ rule drift, ਅਤੇ Flutter ਵਿੱਚ stale ਜਾਂ ਭ੍ਰਮਕ UI। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਨਾਲ ਬਿਲਡ ਕਰਦੇ ਹੋ ਜਿੱਥੇ ਕੋਡ ਤੇਜ਼ੀ ਨਾਲ ਲੇਅਰਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਇਹ ਟੈਸਟ ਤੇਜ਼ signal ਦੇਂਦੇ ਹਨ ਘੱਟ ਰਖ-ਰਖਾਅ ਨਾਲ।
60 ਮਿੰਟ ਲਈ ਟਾਈਮਰ ਸੈਟ ਕਰੋ ਅਤੇ ਰਿਸਕ ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰੋ, ਨਿ Perfection 'ਤੇ ਨਹੀਂ। ਚੈਟ-ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਠੀਕ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਛੋਟੇ ਨਿਯਮ, edge cases, ਜਾਂ ਲੇਅਰਾਂ ਵਿਚਕਾਰ wiring ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ। ਤੁਹਾਡਾ ਲਕੜੀ ਦਾ ਲਕੜ ਹੈ ਇੱਕ ਛੋਟੀ ਟੈਸਟ ਸੈੱਟ ਜੋ ਵਿਹਾਰ ਬਦਲਣ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਫੇਲ ਹੋਵੇ।
ਉਹ 5 user actions ਲਿਖੋ ਜੋ ਹਰ ਵਾਰੀ ਕੰਮ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ konkreਤ ਰੱਖੋ: “sign in”, “create an order”, “pay”, “see order history”, “reset password”。ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਉਹ ਚੁਣੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਅੱਜ end-to-end ਡੈਮੋ ਕਰ ਸਕਦੇ ਹੋ, ਨਾ ਕਿ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਜੁੜਨ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ।
ਹਰ ਫਲੋ ਲਈ ਉਹ ਇਕ ਨਿਯਮ ਲੱਭੋ ਜੋ ਗਲਤ ਹੋਣ ਤੇ ਅਸਲ ਨੁਕਸਾਨ ਪੈਦਾ ਕਰੇ। ਉਸ ਲੇਅਰ ਵਿੱਚ ਇੱਕ ਛੇਤੀ ਯੂਨਿਟ ਟੈਸਟ ਜੋੜੋ ਜਿੱਥੇ ਉਹ ਨਿਯਮ ਰਹਿੰਦਾ:
ਉਦਾਹਰਣ: “Checkout ਨੂੰ negative quantity ਦੀ ਆਗਿਆ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।” ਇਕ ਵਾਰੀ API ਵਿੱਚ ਟੈਸਟ ਕਰੋ, ਅਤੇ ਜੇ UI/ਕਲਾਇੰਟ ਵੀ ਇਸਦੀ enforcement ਕਰਦੇ ਹਨ ਤਾਂ ਓਥੇ ਵੀ ਇਕ ਵਾਰੀ ਕਰੋ।
ਹਰ ਫਲੋ ਲਈ ਇੱਕ integration test ਜੋ ਅਸਲੀ API ਨੂੰ ਹਿਟ ਕਰੇ ਅਤੇ Postgres ਵਿੱਚ ਅਸਲੀ ਡਾਟਾ ਲਿਖੇ। ਇਸਨੂੰ ਤੇਜ਼ ਅਤੇ ਸੰਕੁਚਿਤ ਰੱਖੋ: create, update, fetch, ਅਤੇ stored result verify ਕਰੋ। ਇਹ wiring mistakes ਜਿਵੇਂ ਗਲਤ field names, missing transactions, ਜਾਂ broken migrations ਫੜਦਾ ਹੈ।
ਕੁੱਲ 3-6 e2e flows ਚੁਣੋ। ਸਭ ਤੋਂ cross-layer ਪਾਥਾਂ ਨੂੰ ترجیح ਦਿਓ (login → create → view)। stable test data (seeded user, known IDs, fixed clock) define ਕਰੋ ਤਾਂ ਕਿ randomness ਤੋਂ dependency ਨਾ ਹੋਵੇ।
CI ਵਿੱਚ ਇਹ ਕ੍ਰਮ ਰੱਖੋ: ਹਰ push 'ਤੇ unit tests, integration tests ਹਰ push ਜਾਂ main 'ਤੇ, ਅਤੇ e2e ਸਿਰਫ਼ main ਜਾਂ nightly 'ਤੇ ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ।
ਗਲਤ ਚੀਜ਼ ਨੂੰ ਗਲਤ ਪੱਧਰ 'ਤੇ ਟੈਸਟ ਕਰਨਾ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਮਾਂ ਖਰਚ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ। ਬਹੁਤਰ ਫੇਲ predictable ਹਨ: unclear contracts, unrealistic mocks, ਅਤੇ ਇਕ suite ਜੋ ਕਿਸੇ ਭਰੋਸੇਯੋਗ ਨਹੀਂ।
ਇੱਕ ਆਮ ਗਲਤੀ ਹੈ ਟੈਸਟ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ API contract 'ਤੇ ਸਹਿਮਤ ਨਾ ਹੋਣਾ। ਜੇ Go API error codes, field names, ਜਾਂ pagination rules ਬਦਲਦੇ ਹਨ, ਤਾਂ React ਅਤੇ Flutter clients ਐਸੇ ਢੰਗ ਨਾਲ ਫੇਲ ਹੋਣਗੇ ਜੋ ਬੇਕਾਰ ਲੱਗ ਸਕਦੇ ਹਨ। ਪਹਿਲਾਂ contract ਲਿਖੋ (request, response, status codes, error shapes), ਫਿਰ ਕੁਝ integration tests ਨਾਲ ਉਨ੍ਹਾਂ ਨੂੰ ਲਾਕ ਕਰੋ।
ਦੂਜਾ ਫੇੰਸ/ਟ੍ਰੈਪ mocks ਦਾ ਵੱਧ ਉਪਯੋਗ ਹੈ। ਉਹ mocks ਜੋ Postgres, auth middleware, ਜਾਂ ਅਸਲੀ ਨੈਟਵਰਕ responses ਵਰਗੀ ਤਰ੍ਹਾਂ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ, ਇੱਕ ਗਲਤ ਸੁਰੱਖਿਆ ਭਰੋਸਾ ਦੇਂਦੇ ਹਨ। Pure logic ਲਈ unit tests ਵਰਤੋ, ਪਰ process boundaries cross ਕਰਨ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਖਰਾਬ mocks ਦੀ ਥਾਂ thin integration tests ਪਸੰਦ ਕਰੋ।
ਤੀਜਾ ਗਲਤ ਫੈਸਲਾ end-to-end tests 'ਤੇ ਹੀ ਨਿਰਭਰ ਰਹਿਣਾ ਹੈ। E2E ਧੀਮੇ ਅਤੇ fragile ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਸਿਰਫ਼ ਸਭ ਤੋਂ ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਯੂਜ਼ਰ ਯਾਤ੍ਰਿਆਂ ਦੀ ਹਿਫਾਜ਼ਤ ਕਰਨ ਜਾਣ। ਜਿਆਦਾਤਰ ਕਵਰੇਜ(unit & integration) ਵਿੱਚ ਰੱਖੋ ਜਿੱਥੇ failures diagnose ਕਰਨਾ ਅਸਾਨ ਹੈ।
ਆਖ਼ਿਰਕਾਰ, flakiness ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਾ ਕਰੋ। ਜੇ ਟੈਸਟ ਕਦੇ-ਕਦੇ fail ਕਰਦੇ ਹਨ, ਟੀਮ ਧਿਆਨ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ। flaky tests ਨੂੰ ਤੁਹਾਡੇ delivery pipeline ਵਿੱਚ ਬੱਗ ਸਮਝੋ ਅਤੇ ਝਟਪਟ ਠੀਕ ਕਰੋ।
ਤੇਜ਼ ਚੈੱਕਲਿਸਟ ਪਹਿਲਾਂ:
ਅਗਲੇ ਕਦਮ: ਯੋਜਨਾ ਲਾਗੂ ਕਰੋ, ਰਿਗ੍ਰੈਸ਼ਨ ਲੇਅਰ ਵਾਰ ਟ੍ਰੈਕ ਕਰੋ, ਅਤੇ suite ਨੂੰ ਜ਼ੋਰ ਦੇ ਕੇ ਛੋਟਾ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ generated API contract ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੇ ਤੁਰੰਤ ਬਾਅਦ ਟੈਸਟ ਜੋੜੋ ਅਤੇ ਫਿਰ features ਵਧਾਓ।
ਜੇ ਤੁਸੀਂ Koder.ai ਰਾਹੀਂ ਜਨਰੇਟ ਕੀਤੀਆਂ ਐਪਾਂ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਵੈੱਬ, ਬੈਕਐਂਡ, ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਇਕ ਸਥਾਨ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ iterate ਕਰਨ ਲਈ, koder.ai 'ਤੇ ਪਲੇਟਫਾਰਮ ਉਸ workflow ਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਜਿਸ ਵੀ ਟੂਲ ਨੂੰ ਤੁਸੀਂ ਵਰਤੋ, ਟੈਸਟਿੰਗ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਇੱਕੋ ਜਿਹੇ ਰਹਿੰਦੇ ਹਨ: contracts ਨੂੰ ਲਾਕ ਕਰੋ, ਮੁੱਖ ਰਸਤਿਆਂ ਨੂੰ ਕਵਰ ਕਰੋ, ਅਤੇ suite ਬੋਰਿੰਗ ਨਹੀਂ—ਇਸ ਨੁਕਤੇ 'ਤੇ ਪਰਮਿੱਸ਼ਨ ਦਿਓ ਕਿ ਤੁਸੀਂ ਉਹ ਚਲਾਉਂਦੇ ਰਹੋ।
ਉਹ ਅਕਸਰ ਬਾਊਂਡਰੀਆਂ 'ਤੇ fail ਹੁੰਦੇ ਹਨ: UI ↔ API ↔ ਡੇਟਾਬੇਸ. ਜਨਰੇਟ ਕੀਤੇ ਹਿੱਸੇ ਖੁਦ ਵਿੱਚ ਠੀਕ ਲੱਗ ਸਕਦੇ ਹਨ, ਪਰ ਛੋਟੀਆਂ ਕਾਂਟਰੈਕਟ ਮਿਸਮੈਚ (ਫੀਲਡ ਨਾਮ, ਟਾਈਪ, ਡੀਫੌਲਟ, ਸਟੇਟਸ ਕੋਡ) ਉਹ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜੋ ਅਸਲ ਯੂਜ਼ਰਾਂ ਵੱਲੋਂ ਕੀਤੇ “ਮੇਸੀ” ਕੰਮਾਂ ਜਿਵੇਂ ਦੁਹਰਾਏ ਕਲਿੱਕ, ਅਜੀਬ ਇਨਪੁਟ ਭੇਜਣਾ ਜਾਂ ਥੋੜ੍ਹਾ ਪੁਰਾਣਾ ਕਲਾਇੰਟ ਵਰਤਣ 'ਤੇ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ।
ਗਲੂ (glue) ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਮੁੱਖ ਯੂਜ਼ਰ ਫਲੋਜ਼ ਅਤੇ ਹੇਠਾਂ ਜੁੜੇ API ਕਾਂਟਰੈਕਟ। ਇੱਕ ਛੋਟੀ ਸੈੱਟ ਜੋ “create/update + validate + save + read back” ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ ਅਕਸਰ ਬਹੁਤ ਸੱਚੀਆਂ ਬੱਗਾਂ ਫੜ ਲੈਂਦੀ ਹੈ ਬੜੀ ਗਿਣਤੀ UI snapshots ਨਾਲੋਂ।
ਉਹ ਰਿਸਕ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਜਲਦੀ ਮਹਿੰਗੇ ਪੈ ਸਕਦੇ ਹਨ:
ਫਿਰ ਉਹਨਾਂ ਨਿਯਮਾਂ ਲਈ ਸਭ ਤੋਂ ਛੋਟੇ ਟੈਸਟ ਲਿਖੋ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਇਹ ਨਰਮਤਾ ਚੁੱਕ ਨਹੀਂ ਸਕਦੀ।
ਪਹਿਲਾਂ ਸ਼੍ਰੇਣੀ ਦੀ ਫੈਸਲਾ ਕਰੋ, ਫਿਰ ਟੈਸਟ ਲਿਖੋ।
ਸ਼ੁਰੂਆਤ pure logic ਟੈਸਟਾਂ ਨਾਲ ਕਰੋ (formatter, validator, API response → view model mapping, reducers/state machines). ਫਿਰ ਕੁੱਝ component ਟੈਸਟ ਜੋ ਯੂਜ਼ਰ ਵਾਂਗ ਵਰਤੋਂ ਕਰਨ: submit success, validation failure, loading → success, loading → error → retry. ਨੈਟਵਰਕ ਨਾਲ ਗੱਲ ਕਰਨ ਵਾਲੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ boundary 'ਤੇ ਮੌਕ ਕਰੋ: assert ਕਰੋ ਕਿ ਬਾਹਰ ਜਾਂਦਾ payload ਸਹੀ keys ਰੱਖਦਾ ਹੈ ਤਾਂ ਕਿ contract drift ਜ਼ਰੂਰ ਫੜੇ।
ਚਾਰ ਚੀਜ਼ਾਂ ਪੱਕੇ ਕਰੋ:
Table-driven tests ਵਰਤੋ ਤਾਂ ਕਿ edge cases ਪੜ੍ਹਨ ਯੋਗ ਅਤੇ ਆਸਾਨ ਰਹਿਣ।
JSON → Dart ਮਾਡਲ ਬਾਊਂਡਰੀ 'ਤੇ ਧਿਆਨ ਦਿਓ:
fromJson missing/nullable fields ਨੂੰ crash ਨਾ ਕਰਾਉਣੇਇਕ ਟੈਸਟ ਜ਼ਰੂਰ ਰੱਖੋ ਜੋ ਸਿੱਧੇ ਦਿਖਾਏ ਕਿ ਸਰਵਰ ਤੋਂ validation error ਆਉਣ 'ਤੇ ਯੂਜ਼ਰ ਨੂੰ ਦੋਸਤਾਨਾ ਸੁਨੇਹਾ ਦਿਖਾਉਂਦੇ ਹੋ।
ਹਰ ਟੈਸਟ ਨੂੰ ਇੱਕ ਸਨਾਰਿਓ 'ਤੇ ਰੱਖੋ ਅਤੇ seed ਡੇਟਾ ਘੱਟ ਰੱਖੋ ਤਾਂ ਕਿ ਇਹ ਸਥਿਰ ਰਹੇ।
ਛੋਟੇ, ਨਿਰੀਖਣਯੋਗ E2E smoke tests ਰੱਖੋ:
ਇਹਨਾਂ ਨੂੰ deterministic ਬਣਾਓ: fixed test accounts, seeded data, واضح wait ਸਿੰਗਨਲ (ਕੋਈ random sleeps ਨਹੀਂ), ਅਤੇ ਹਰ run ਤੋਂ ਬਾਅਦ ਸਾਫ਼ ਸਟੇਟ।
ਉਹ ਟੈਸਟ ਜੋ ਸ਼ੋਰ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜਾਂ ਇਕੋ ਗਰਾਂਟੀ ਨੂੰ ਹਰ ਲੇਅਰ 'ਤੇ ਦੁਹਰਾਉਂਦੇ ਹਨ, ਉਹ ਰੋਕ ਦਿਓ:
ਜੇ ਕੋਈ ਅਸਲ ਬੱਗ ਮਿਲੇ ਤਾਂ ਟੈਸਟ ਜੋੜੋ—ਇਸ ਤਰੀਕੇ ਨਾਲ suite ਵਰਤੋਂਯੋਗ ਅਤੇ ਨਿਰਧਾਰਤ ਰਹੇਗੀ।