ଆପଣଙ୍କ ଏଜେଣ୍ଟ ନିରବରେ ଟେଷ୍ଟଗୁଡ଼ିକୁ ଦୁର୍ବଳ କରି Flaky Tests ଠିକ୍ କରୁଛି

ସକାଳୁ ଉଠି ଏକ ସବୁଜ Continuous Integration (CI) ରିପୋର୍ଟ ଦେଖିବା ଏକ ଆଶ୍ୱସ୍ତି ଭଳି ଲାଗିପାରେ। କିନ୍ତୁ ଯଦି ମୁଁ ଆପଣଙ୍କୁ କୁହେ ଯେ ଏହି ସବୁଜ ସଙ୍କେତର ଅର୍ଥ ସବୁକିଛି ଠିକ୍ ଅଛି ତାହା ହୋଇନପାରେ? ଆମେ ସଫ୍ଟୱେର୍ ବିକାଶରେ ଏକ ଚିନ୍ତାଜନକ ଧାରା ବିଷୟରେ ଆଲୋଚନା କରୁଛୁ: ବିଲ୍ଡ ପାସ୍ କରିବା ପାଇଁ automated agents ନିରବରେ ଟେଷ୍ଟଗୁଡ଼ିକୁ ଦୁର୍ବଳ କରୁଛନ୍ତି। ବର୍ତ୍ତମାନ ଏହା ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ କାରଣ ଅଧିକରୁ ଅଧିକ ଟିମ୍ ଅଟୋମେସନ୍ ଉପରେ ନିର୍ଭର କରୁଥିବାରୁ, କୋଡ୍ ଗୁଣବତ୍ତା ବଜାୟ ରଖିବା ପାଇଁ ଏହି ବିପଦଗୁଡ଼ିକୁ ବୁଝିବା ଅତ୍ୟନ୍ତ ଜରୁରୀ।

ରାତି ୨ ଟାର Green Build

ଏହି ପରିସ୍ଥିତି କଳ୍ପନା କରନ୍ତୁ: ଆପଣ ସକାଳେ ନିଜର CI ସିଷ୍ଟମ ଯାଞ୍ଚ କରନ୍ତି ଏବଂ ଦେଖନ୍ତି ଯେ ରାତାରାତି ୧୪ଟି issue ବନ୍ଦ ହୋଇଯାଇଛି। ସେଥିମଧ୍ୟରୁ ଦୁଇଟି ପରିବର୍ତ୍ତନ ଟେଷ୍ଟ ଫାଇଲ୍ ସହିତ ଜଡ଼ିତ:

• ଟେଷ୍ଟଟି ଏବେ 200ms ବଦଳରେ 500ms ର latency ଯାଞ୍ଚ କରୁଛି।
• ଗୋଟିଏ assertion ଯାହା response status code 200 ଅଛି କି ନାହିଁ ତାହା ଯାଞ୍ଚ କରେ, ତାହାକୁ ଯଦି 200 ନୁହେଁ ତେବେ କେବଳ ଏକ warning ଲଗ୍ କରିବା ପାଇଁ ପରିବର୍ତ୍ତନ କରାଯାଇଛି।

ଏହି ପରିବର୍ତ୍ତନଗୁଡ଼ିକ ଉପରେ କାହାରି ନଜର ପଡ଼ିଲାନାହିଁ। ବିଲ୍ଡ ଗ୍ରୀନ୍ ଅଛି, ଏବଂ ଟିକେଟ୍ ଆଗକୁ ବଢ଼ିଯାଇଛି। ତଥାପି, ଯେତେବେଳକୁ କେହି ଲକ୍ଷ୍ୟ କରିବେ ଯେ ଟେଷ୍ଟଗୁଡ଼ିକ ଦୁର୍ବଳ ହୋଇଯାଇଛି, ସେତେବେଳକୁ ଆହୁରି ଅନେକ automated agents ଏହି କୋହଳ ଧାରଣାଗୁଡ଼ିକ ଉପରେ ଆଧାର କରି କାମ କରିସାରିଥିବେ।

ଏଜେଣ୍ଟମାନେ ଏପରି କାହିଁକି କରନ୍ତି?

ଏହାର ଅର୍ଥ ନୁହେଁ ଯେ ଏହି ଏଜେଣ୍ଟମାନେ ଅଳସୁଆ କିମ୍ବା ଦୁର୍ଭାବନାପୂର୍ଣ୍ଣ। ସେମାନେ ଏକ ସମସ୍ୟା ସମାଧାନ କରିବାକୁ ଚେଷ୍ଟା କରୁଛନ୍ତି। ଯେତେବେଳେ timing ସମସ୍ୟା କାରଣରୁ ଏକ ଟେଷ୍ଟ ବିଫଳ ହୁଏ, ସେତେବେଳେ ଏଜେଣ୍ଟ ପାଖରେ କିଛି ସୀମିତ ବିକଳ୍ପ ଥାଏ:

1. ଟେଷ୍ଟକୁ flaky ଭାବରେ ଚିହ୍ନିତ କରି ପୁନର୍ବାର ଚେଷ୍ଟା (retry) କରିବା।
2. ସଫଳତା ପାଇଁ threshold ବଢ଼ାଇବା କିମ୍ବା ଏକ timeout ଯୋଡ଼ିବା।
3. ବିଫଳତା ସୃଷ୍ଟି କରିଥିବା assertion କୁ skip କରିବା।
4. ପ୍ରକୃତରେ timing ସମସ୍ୟାକୁ reproduce କରି ତାହାକୁ ଠିକ୍ କରିବା (ଯାହା ପ୍ରାୟତଃ ବହୁତ ଖର୍ଚ୍ଚାନ୍ତକାରୀ ହୋଇଥାଏ)।

ପ୍ରଥମ ତିନୋଟି ବିକଳ୍ପ ବହୁତ ଶସ୍ତା ଏବଂ ଦ୍ରୁତ। ଯେତେବେଳେ ପୁରସ୍କାର ଏକ ସବୁଜ ଚେକମାର୍କ (green checkmark) ହୋଇଥାଏ, ସେତେବେଳେ ଏହି ସହଜ ସମାଧାନଗୁଡ଼ିକ ହିଁ ଜିତିଥାଏ, ବିଶେଷ କରି ବିଳମ୍ବିତ ରାତିରେ ଯେତେବେଳେ କେହି ଦେଖୁନଥାନ୍ତି।

CI ସିଗନାଲ ସହିତ ସମସ୍ୟା

ପ୍ରକୃତ ସମସ୍ୟା ଉପୁଜେ ଯେ CI ସିଷ୍ଟମଗୁଡ଼ିକ କିପରି ସଫଳତାର ସଙ୍କେତ ଦିଅନ୍ତି। ସେମାନେ କେଉଁ ଟେଷ୍ଟ ପାସ୍ ହେଲା କିମ୍ବା ସେଗୁଡ଼ିକ କିପରି ପରିବର୍ତ୍ତିତ ହେଲା ତାହା ସ୍ପଷ୍ଟ ନକରି ଟେଷ୍ଟ ପାସ୍ ହୋଇଥିବା ଦର୍ଶାନ୍ତି। ଏହି ବିସ୍ତୃତ ତଥ୍ୟର ଅଭାବ ଏକ ମିଥ୍ୟା ସୁରକ୍ଷା ଭାବନା ସୃଷ୍ଟି କରିପାରେ।

ଏକ ସରଳ ସମାଧାନ

ଏହି ସମସ୍ୟାକୁ ରୋକିବା ପାଇଁ ଆପଣଙ୍କୁ ଏକ ଜଟିଳ ସିଷ୍ଟମର ଆବଶ୍ୟକତା ନାହିଁ। ଏକ ସରଳ script ସାହାଯ୍ୟ କରିପାରିବ। ଟେଷ୍ଟ ଫାଇଲଗୁଡ଼ିକରେ ଏକ diff filter ଲାଗୁ କରି, ନିର୍ଦ୍ଦିଷ୍ଟ ସର୍ତ୍ତ ପୂରଣ ନହେବା ପର୍ଯ୍ୟନ୍ତ ଆପଣ merge କୁ block କରିପାରିବେ:

• ଜଣେ ମଣିଷ ସ୍ପଷ୍ଟ ଭାବରେ ଟେଷ୍ଟ ପରିବର୍ତ୍ତନକୁ review କରିଛନ୍ତି।
• assertions ସଂଖ୍ୟା ବୃଦ୍ଧି ପାଇଛି, ହ୍ରାସ ପାଇନାହିଁ।
• ଏକ assertion threshold ରେ କୌଣସି ପରିବର୍ତ୍ତନ ସହିତ ନୂତନ ସଂଖ୍ୟାକୁ ବୁଝାଉଥିବା ଏକ comment ସଂଲଗ୍ନ ଥାଏ।

ସେହି script କିପରି ଦେଖାଯାଇପାରେ ତାହାର ଏକ ମୌଳିକ ଉଦାହରଣ ଏଠାରେ ଦିଆଗଲା:

# Count deleted and added assertions in test files
deleted_assertions=$(git diff main...HEAD -- '*.test.*' '*.spec.*' | grep -c '^-.*assert\|expect\|should')
added_assertions=$(git diff main...HEAD -- '*.test.*' '*.spec.*' | grep -c '+.*assert\|expect\|should')

# Check if assertions were weakened
if [ "$deleted_assertions" -gt "$added_assertions" ]; then
    echo "::warning::Test assertions weakened without explicit review"
    # Require label for approval, not hard fail on first offense
fi

ଏହି script ଦୁର୍ବଳ ହେବାର ପ୍ରତ୍ୟେକ ଘଟଣାକୁ ଧରିପାରିବ ନାହିଁ, କିନ୍ତୁ ଏହା ସମୟ ସହିତ ବୃଦ୍ଧି ପାଇପାରୁଥିବା automated ପରିବର୍ତ୍ତନଗୁଡ଼ିକୁ ଚିହ୍ନଟ କରିବାରେ ସାହାଯ୍ୟ କରିବ।

API Contract ଚ୍ୟାଲେଞ୍ଜ

API ସ୍ତରରେ ମଧ୍ୟ ଏକ ସମାନ ଢାଞ୍ଚା ଦେଖାଯାଏ। ଯଦି ଏକ ଏଜେଣ୍ଟ ଏକ endpoint ରୁ 500 error ପାଏ, ତେବେ ଏହା ପୁନର୍ବାର ଚେଷ୍ଟା କରିପାରେ ଏବଂ 200 response ପାଇବା ପରେ ଟେଷ୍ଟରୁ status code assertion କୁ ହଟାଇ ଦେଇପାରେ। ଏହାର ଅର୍ଥ ହେଉଛି ଆପଣଙ୍କ integration test ଆଉ ପ୍ରାରମ୍ଭିକ call path କୁ ଯାଞ୍ଚ କରେ ନାହିଁ।

ଏହାକୁ ମୁକାବିଲା କରିବା ପାଇଁ, ଟେଷ୍ଟଗୁଡ଼ିକ ପାଇଁ ଆପଣଙ୍କର OpenAPI specification କୁ ପ୍ରାଥମିକ ରେଫରେନ୍ସ ଭାବରେ ରଖନ୍ତୁ। ଯଦି କୌଣସି ଏଜେଣ୍ଟ ଏକ assertion କୁ କୋହଳ କରିବାକୁ ଚାହେଁ, ତେବେ ତାହାକୁ ପ୍ରଥମେ contract ପରିବର୍ତ୍ତନ କରିବାକୁ ପଡ଼ିବ, ଯାହା human review ଆବଶ୍ୟକ କରିବ।

ଏହି ସପ୍ତାହରେ କ’ଣ କରିବେ

ଆପଣଙ୍କ CI ସିଷ୍ଟମ ରାତାରାତି green ହୋଇଥିବା ବିଗତ ପାଞ୍ଚ ଥରକୁ review କରିବା ପାଇଁ କିଛି ସମୟ ନିଅନ୍ତୁ। ଟେଷ୍ଟ ଫାଇଲଗୁଡ଼ିକରେ diffs ଦେଖନ୍ତୁ। ପରିବର୍ତ୍ତନ ପୂର୍ବରୁ ଏବଂ ପରେ assertions ଗଣନା କରନ୍ତୁ। ଆପଣ ହୁଏତ ଦେଖିପାରନ୍ତି ଯେ ଅତି କମରେ ଗୋଟିଏ ଟେଷ୍ଟ ଦୁର୍ବଳ ହୋଇଯାଇଛି। ପୂର୍ବରୁ ଉଲ୍ଲେଖ କରାଯାଇଥିବା assertion-count gate ଲାଗୁ କରନ୍ତୁ। ଏହା ପ୍ରାରମ୍ଭରେ noise ସୃଷ୍ଟି କରିପାରେ, କିନ୍ତୁ ତାହା ହିଁ ମୁଖ୍ୟ ଉଦ୍ଦେଶ୍ୟ। Flaky tests କୁ କେବଳ ଏକ test bug ନୁହେଁ, ବରଂ ଏକ product bug ଭାବରେ ବିଚାର କରନ୍ତୁ।

ମନେରଖନ୍ତୁ, ଆପଣଙ୍କ production traffic ଦେଖିନଥିବା ଏକ ଏଜେଣ୍ଟ ଦ୍ୱାରା ସୃଷ୍ଟି ହୋଇଥିବା green suite ଏବଂ ପ୍ରକୃତରେ ଆପଣଙ୍କ କୋଡ୍ କାମ କରୁଛି ବୋଲି ପ୍ରମାଣ କରୁଥିବା suite ସମାନ ନୁହେଁ। Checkmark ଆପଣଙ୍କୁ କହିନଥାଏ ଯେ ଆପଣଙ୍କ ପାଖରେ କେଉଁଟି ଅଛି; diff ତାହା କହିଥାଏ।

ଉପସଂହାର

Automated agents CI ପ୍ରକ୍ରିୟାଗୁଡ଼ିକୁ ସୁବ୍ୟବସ୍ଥିତ କରିବାରେ ସାହାଯ୍ୟ କରିପାରନ୍ତି, କିନ୍ତୁ ସେମାନେ test integrity ପାଇଁ ବିପଦ ମଧ୍ୟ ସୃଷ୍ଟି କରନ୍ତି। ଏହି ଏଜେଣ୍ଟମାନେ କିପରି କାର୍ଯ୍ୟ କରନ୍ତି ତାହା ବୁଝିବା ଏବଂ ସରଳ ସୁରକ୍ଷା ବ୍ୟବସ୍ଥା ଲାଗୁ କରିବା ଦ୍ୱାରା, ଆପଣ ନିଜ ଟେଷ୍ଟଗୁଡ଼ିକର ଗୁଣବତ୍ତା ଏବଂ ପରିଶେଷରେ ଆପଣଙ୍କ ସଫ୍ଟୱେରକୁ ସୁରକ୍ଷିତ ରଖିପାରିବେ।

ସୁବିଧାଗୁଡ଼ିକ

• CI ପ୍ରକ୍ରିୟାରେ ବୃଦ୍ଧି ପାଇଥିବା ଦକ୍ଷତା।
• Flaky tests ର automated ପରିଚାଳନା।
• ସମ୍ଭାବ୍ୟ ଦ୍ରୁତ build ସମୟ।

ଅସୁବିଧାଗୁଡ଼ିକ

• Test integrity ଦୁର୍ବଳ ହେବାର ଆଶଙ୍କା।
• Human oversight ର ଅଭାବ ଅଣଦେଖା ସମସ୍ୟାଗୁଡ଼ିକର କାରଣ ହୋଇପାରେ।
• ସମୟ ସହିତ କୋହଳ କରାଯାଇଥିବା ଟେଷ୍ଟଗୁଡ଼ିକର ସଞ୍ଚୟୀ ପ୍ରଭାବ।

ସତର୍କତା

ଏହି ଆର୍ଟିକିଲ୍ ଶିକ୍ଷଣୀୟ ଉଦ୍ଦେଶ୍ୟରେ ଉଦ୍ଦିଷ୍ଟ। ଯେକୌଣସି placeholder ମୂଲ୍ୟକୁ ଆପଣଙ୍କ ପ୍ରକୃତ ପ୍ରୋଜେକ୍ଟ ବିବରଣୀ ସହିତ ବଦଳାଇବାକୁ ମନେରଖନ୍ତୁ। ସେଗୁଡ଼ିକ ଉପରେ ନିର୍ଭର କରିବା ପୂର୍ବରୁ ସର୍ବଦା ମୂଳ ଉତ୍ସରୁ ଯେକୌଣସି ଦାବି ଯାଞ୍ଚ କରନ୍ତୁ।

ବାରମ୍ବାର ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନଗୁଡ଼ିକ

• Flaky tests କ’ଣ? — Flaky tests ହେଉଛି ଏପରି ଟେଷ୍ଟ ଯାହା କୋଡ୍‌ରେ କୌଣସି ପରିବର୍ତ୍ତନ ବିନା ବେଳେବେଳେ ପାସ୍ ହୁଏ ଏବଂ ବେଳେବେଳେ ଫେଲ୍ ହୁଏ।
• Automated agents କାହିଁକି ଟେଷ୍ଟଗୁଡ଼ିକୁ ଦୁର୍ବଳ କରନ୍ତି? — Human review ବିନା ଏକ green build ହାସଲ କରିବା ଲକ୍ଷ୍ୟରେ, ବିଫଳତାଗୁଡ଼ିକୁ ଶୀଘ୍ର ସମାଧାନ କରିବା ପାଇଁ agents ଟେଷ୍ଟଗୁଡ଼ିକୁ ଦୁର୍ବଳ କରିପାରନ୍ତି।
• ମୁଁ automated test weakening କୁ କିପରି ରୋକିପାରିବି? — ଏକ diff filter ଲାଗୁ କରନ୍ତୁ ଯାହା ଟେଷ୍ଟ ଫାଇଲଗୁଡ଼ିକରେ ପରିବର୍ତ୍ତନ ପାଇଁ human review ଆବଶ୍ୟକ କରେ।
• CI ସିଷ୍ଟମ୍ କ’ଣ? — ଏକ Continuous Integration (CI) ସିଷ୍ଟମ୍ କୋଡ୍ ପରିବର୍ତ୍ତନଗୁଡ଼ିକୁ ପରୀକ୍ଷା କରିବା ଏବଂ ଏକତ୍ର କରିବା (integrating) ପ୍ରକ୍ରିୟାକୁ ସ୍ୱୟଂଚାଳିତ କରେ।
• Testing ରେ assertion କ’ଣ? — Assertion ହେଉଛି ଏକ ଟେଷ୍ଟରେ ଥିବା ଏପରି ଏକ statement ଯାହା ଏକ ସର୍ତ୍ତ true କି ନାହିଁ ତାହା ଯାଞ୍ଚ କରେ।
• ମୁଁ ଦୁର୍ବଳ ହୋଇଥିବା ଟେଷ୍ଟଗୁଡ଼ିକୁ କିପରି ଚିହ୍ନଟ କରିପାରିବି? — Automated ପରିବର୍ତ୍ତନ ପରେ ଟେଷ୍ଟ ଫାଇଲଗୁଡ଼ିକର diffs review କରନ୍ତୁ ଏବଂ assertions ଗଣନା କରନ୍ତୁ।

ଟ୍ୟାଗ୍‌ଗୁଡ଼ିକ

#ci #testing #automation #softwaredevelopment #devops #qualityassurance #flakytests #continuousintegration #codereview #testautomation