BDD ਬਾਰੇ 3 ਗੱਲਾਂ ਜੋ ਤੁਹਾਨੂੰ ਕੋਈ ਨਹੀਂ ਦੱਸਦਾ
ਤੁਹਾਡੀ Cucumber suite ਨੂੰ ਚੱਲਣ ਵਿੱਚ ਚਾਲੀ ਮਿੰਟ ਲੱਗਦੇ ਹਨ। ਤੁਸੀਂ ਕੋਡ ਦੀਆਂ ਕਈ ਪਰਤਾਂ ਪੜ੍ਹੇ ਬਿਨਾਂ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਇੱਕ ਸਿੰਗਲ feature file ਕੀ ਟੈਸਟ ਕਰ ਰਹੀ ਹੈ।
ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ BDD ਨੂੰ ਇਸ ਲਈ ਅਪਣਾਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ business stakeholders ਨੂੰ ਟੈਸਟ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਫਿਰ, ਉਹ stakeholders ਪੜ੍ਹਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ। ਅੰਤ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਮੇਨਟੇਨੈਂਸ (maintenance) ਦੀ ਇੱਕ ਭਿਆਨਕ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
BDD ਬਾਰੇ ਤਿੰਨ ਸੱਚਾਈਆਂ ਇੱਥੇ ਹਨ।
- Gherkin ਕੋਈ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਨਹੀਂ ਹੈ
Gherkin ਵਿੱਚ test scripts ਲਿਖਣਾ ਬੰਦ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡੇ scenarios ਵਿੱਚ ਹਰ ਇੱਕ ਕਲਿੱਕ ਅਤੇ ਹਰ ਇੱਕ ਫੀਲਡ ਦੀ ਸੂਚੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਗਲਤ ਕਰ ਰਹੇ ਹੋ।
ਗਲਤ Gherkin:
- Given ਯੂਜ਼ਰ ਈਮੇਲ "test@example.com" ਦਰਜ ਕਰਦਾ ਹੈ
- And ਯੂਜ਼ਰ ਪਾਸਵਰਡ "Password123!" ਦਰਜ ਕਰਦਾ ਹੈ
- And ਯੂਜ਼ਰ "Place Order" 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ
ਸਹੀ Gherkin:
- Given ਯੂਜ਼ਰ ਕੋਲ ਖਰੀਦਣ ਲਈ ਆਈਟਮਾਂ ਤਿਆਰ ਹਨ
- When ਯੂਜ਼ਰ ਇੱਕ ਵੈਧ (valid) ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਨਾਲ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ
- Then ਆਰਡਰ ਕਨਫਰਮ ਹੋ ਜਾਂਦਾ ਹੈ
"ਕਿਵੇਂ" (how) ਤੁਹਾਡੇ step definitions ਵਿੱਚ ਹੁੰਦਾ ਹੈ। "ਕੀ" (what) ਤੁਹਾਡੀਆਂ feature files ਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਆਪਣੀਆਂ feature files ਨੂੰ ਸਰਲ ਰੱਖੋ ਤਾਂ ਜੋ ਇੱਕ product manager ਉਹਨਾਂ ਨੂੰ ਕੁਝ ਹੀ ਸਕਿੰਟਾਂ ਵਿੱਚ ਪੜ੍ਹ ਸਕੇ।
- Step definitions ਕੋਈ dependency graph ਨਹੀਂ ਹਨ
Step definitions ਨੂੰ ਦੂਜੇ step definitions ਨੂੰ import ਨਾ ਕਰਨ ਦਿਓ। ਇਹ ਇੱਕ ਉਲਝਿਆ ਹੋਇਆ ਜਾਲ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਸਟੈਪ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਪੂਰੀ ਸਟੇਟ (state) ਨੂੰ ਖਰਾਬ ਕਰ ਦਿੰਦਾ ਹੈ।
ਹੱਲ ਸਰਲ ਹੈ:
- ਆਪਣੇ page objects ਨੂੰ ਆਪਣੇ step definitions ਤੋਂ ਵੱਖ ਕਰੋ।
- ਇੱਕ shared domain layer ਦੀ ਵਰਤੋਂ ਕਰੋ।
- Step definitions ਬਹੁਤ ਹਲਕੇ (thin wrappers) ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ domain objects ਨੂੰ ਕਾਲ (call) ਕਰਨ।
ਇਹ ਤੁਹਾਡੇ ਸਟੈਪਸ ਨੂੰ stateless ਬਣਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਬਾਕੀ ਸਾਰੇ scenarios ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਆਪਣੇ ਕੋਡ ਦੇ ਇੱਕ ਹਿੱਸੇ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ।
- BDD ਇੱਕ documentation project ਹੈ
BDD ਸੰਚਾਰ (communication) ਬਾਰੇ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਟੈਸਟਿੰਗ ਬਾਰੇ। ਟੈਸਟ ਇੱਕ ਸਾਈਡ ਇਫੈਕਟ (side effect) ਹਨ।
ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ test coverage ਜਾਂ execution speed ਲਈ ਆਪਟੀਮਾਈਜ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮੁੱਖ ਉਦੇਸ਼ ਗੁਆ ਲੈਂਦੇ ਹੋ। ਤੁਹਾਡੀਆਂ feature files ਉਹ ਪਹਿਲੀ ਚੀਜ਼ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਜੋ ਇੱਕ ਨਵਾਂ ਇੰਜੀਨੀਅਰ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਸਮਝਣ ਲਈ ਪੜ੍ਹਦਾ ਹੈ।
ਜੇਕਰ ਕੋਈ ਵਿਅਕਤੀ ਤੁਹਾਡੀਆਂ feature files ਨੂੰ ਪੜ੍ਹ ਕੇ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਨਹੀਂ ਸਮਝ ਸਕਦਾ, ਤਾਂ ਤੁਹਾਡੀ BDD suite ਅਸਫਲ ਰਹੀ ਹੈ।
ਕੱਲ੍ਹ ਕੀ ਕਰਨਾ ਹੈ:
- ਆਪਣੀ ਸਭ ਤੋਂ ਮਾੜੀ feature file ਚੁਣੋ।
- Scenarios ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੋ ਤਾਂ ਜੋ ਉਹ ਤਿੰਨ ਤੋਂ ਪੰਜ ਲਾਈਨਾਂ ਦੇ ਹੋਣ।
- ਡੇਟਾ ਨੂੰ step definitions ਜਾਂ factories ਵਿੱਚ ਬਦਲੋ।
- Step-to-step imports ਦੀ ਜਗ੍ਹਾ domain objects ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਕੀ ਤੁਸੀਂ ਸਿਰਫ਼ ਆਪਣੀਆਂ feature files ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੰਜ ਮਿੰਟਾਂ ਵਿੱਚ ਕਿਸੇ ਨਵੇਂ ਕਰਮਚਾਰੀ ਨੂੰ ਆਪਣਾ ਸਿਸਟਮ ਸਮਝਾ ਸਕਦੇ ਹੋ? ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਦੁਬਾਰਾ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕਰੋ।
ਵਿਕਲਪਿਕ ਸਿੱਖਣ ਕਮਿਊਨਿਟੀ: https://t.me/GyaanSetuAi