இதோ How to Test Concurrent Code with Testing/Synctest: Go 1.24

கோவின் கையொப்ப அம்சங்களில் ஒன்று, ஒத்திசைவுக்கான உள்ளமைக்கப்பட்ட ஆதரவு ஆகும். ஒத்திசைவு நிரல்களை எழுதுவதற்கு கோரூட்டின்கள் மற்றும் சேனல்கள் எளிமையான மற்றும் பயனுள்ள பழமையானவை. இருப்பினும், ஒரே நேரத்தில் இயங்கும் நிரல்களைச் சோதிப்பது கடினமாகவும் பிழை ஏற்படக்கூடியதாகவும் இருக்கலாம். Go 1.24 இல், ஒரே நேரத்தில் குறியீட்டைச் சோதிப்பதை ஆதரிக்க ஒரு புதிய, சோதனை தொகுப்பை அறிமுகப்படுத்துகிறோம். இந்தப் பதிவு இந்தப் பரிசோதனைக்குப் பின்னால் உள்ள உந்துதலை விளக்குகிறது, ஒத்திசைவு தொகுப்பை எவ்வாறு பயன்படுத்துவது என்பதை விளக்குகிறது மற்றும் அதன் சாத்தியமான எதிர்காலத்தைப் பற்றி விவாதிக்கிறது. testing/synctest Go 1.24 இல், தொகுப்பு சோதனைக்குரியது மற்றும் Go இணக்கத்தன்மை வாக்குறுதிக்கு உட்பட்டது அல்ல. இது இயல்பாகவே தெரியவில்லை. இதைப் பயன்படுத்த, உங்கள் சூழலில் தொகுப்புடன் உங்கள் குறியீட்டை தொகுக்கவும். testing/synctest GOEXPERIMENT=synctest ஒரே நேரத்தில் நிரல்களைச் சோதிப்பது கடினம். தொடங்குவதற்கு, ஒரு எளிய உதாரணத்தைக் கருத்தில் கொள்வோம். சூழல் ரத்து செய்யப்பட்ட பிறகு, ஒரு செயல்பாட்டை அதன் சொந்த கோரூட்டினில் அழைக்க செயல்பாடு ஏற்பாடு செய்கிறது. க்கான சாத்தியமான சோதனை இங்கே: context.AfterFunc AfterFunc func TestAfterFunc(t *testing.T) { ctx, cancel := context.WithCancel(context.Background()) calledCh := make(chan struct{}) // closed when AfterFunc is called context.AfterFunc(ctx, func() { close(calledCh) }) // TODO: Assert that the AfterFunc has not been called. cancel() // TODO: Assert that the AfterFunc has been called. } இந்தச் சோதனையில் இரண்டு நிபந்தனைகளைச் சரிபார்க்க விரும்புகிறோம்: சூழல் ரத்து செய்யப்படுவதற்கு முன்பு செயல்பாடு அழைக்கப்படாது, மேலும் சூழல் ரத்து செய்யப்பட்ட பிறகு செயல்பாடு . அழைக்கப்படுகிறது ஒரு concurrent system-ல் எதிர்மறையை சரிபார்ப்பது கடினம். அந்த function call செய்யப்படவில்லை என்பதை நாம் எளிதாக சோதிக்கலாம், ஆனால் அது call என்பதை எவ்வாறு சரிபார்க்கலாம்? இன்னும் செய்யப்படாது ஒரு நிகழ்வு நடக்காது என்று முடிவு செய்வதற்கு முன்பு சிறிது நேரம் காத்திருப்பது ஒரு பொதுவான அணுகுமுறையாகும். இதைச் செய்யும் ஒரு உதவி செயல்பாட்டை நமது சோதனையில் அறிமுகப்படுத்த முயற்சிப்போம். // funcCalled reports whether the function was called. funcCalled := func() bool { select { case <-calledCh: return true case <-time.After(10 * time.Millisecond): return false } } if funcCalled() { t.Fatalf("AfterFunc function called before context is canceled") } cancel() if !funcCalled() { t.Fatalf("AfterFunc function not called after context is canceled") } இந்த சோதனை மெதுவாக உள்ளது: 10 மில்லி விநாடிகள் அதிக நேரம் இல்லை, ஆனால் இது பல சோதனைகளில் கூடுகிறது. இந்தச் சோதனையும் சீரற்றது: வேகமான கணினியில் 10 மில்லி விநாடிகள் நீண்ட நேரம், ஆனால் பகிரப்பட்ட மற்றும் அதிக சுமை கொண்ட அமைப்புகளில் பல வினாடிகள் நீடிக்கும் இடைநிறுத்தங்களைக் காண்பது அசாதாரணமானது அல்ல. CI சோதனையை மெதுவாக்குவதன் மூலம் அதை குறைவான சீரற்றதாக மாற்றலாம், மேலும் அதை மேலும் சீரற்றதாக மாற்றுவதன் மூலம் அதை குறைவான மெதுவாக்கலாம், ஆனால் அதை வேகமாகவும் நம்பகமானதாகவும் மாற்ற முடியாது. சோதனை/ஒத்திசைவு தொகுப்பை அறிமுகப்படுத்துதல் தொகுப்பு இந்த சிக்கலை தீர்க்கிறது. இது சோதிக்கப்படும் குறியீட்டில் எந்த மாற்றங்களும் இல்லாமல், இந்த சோதனையை எளிமையாகவும், வேகமாகவும், நம்பகமானதாகவும் மீண்டும் எழுத அனுமதிக்கிறது. testing/synctest தொகுப்பில் இரண்டு செயல்பாடுகள் மட்டுமே உள்ளன: மற்றும் . Run Wait என்பது ஒரு புதிய கோரூட்டீனில் ஒரு செயல்பாட்டை அழைக்கிறது. இந்த கோரூட்டீனும் இதனால் தொடங்கப்படும் எந்த கோரூட்டீன்களும் ஒரு தனிமைப்படுத்தப்பட்ட சூழலில் உள்ளன, அதை நாம் என்று அழைக்கிறோம். தற்போதைய கோரூட்டீனின் குமிழியில் உள்ள ஒவ்வொரு கோரூட்டீனும் குமிழியில் உள்ள மற்றொரு கோரூட்டீனைத் தடுக்க . Run குமிழி Wait மேலே உள்ள நமது சோதனையை தொகுப்பைப் பயன்படுத்தி மீண்டும் எழுதுவோம். testing/synctest func TestAfterFunc(t *testing.T) { synctest.Run(func() { ctx, cancel := context.WithCancel(context.Background()) funcCalled := false context.AfterFunc(ctx, func() { funcCalled = true }) synctest.Wait() if funcCalled { t.Fatalf("AfterFunc function called before context is canceled") } cancel() synctest.Wait() if !funcCalled { t.Fatalf("AfterFunc function not called after context is canceled") } }) } இது எங்கள் அசல் சோதனையைப் போலவே உள்ளது, ஆனால் நாங்கள் சோதனையை ஒரு இணைத்துள்ளோம். அழைப்பை இயக்கவும், என்று அழைக்கிறோம். செயல்பாடு அழைக்கப்பட்டதா இல்லையா என்பதை உறுதிப்படுத்தும் முன் காத்திருக்கவும். synctest.Run synctest.Wait அழைப்பாளரின் குமிழியில் உள்ள ஒவ்வொரு கோரூட்டீனும் தடுக்கப்படும் வரை செயல்பாடு காத்திருக்கிறது. அது திரும்பும்போது, சூழல் தொகுப்பு செயல்பாட்டை அழைத்துள்ளது அல்லது நாம் மேலும் சில நடவடிக்கைகளை எடுக்கும் வரை அதை அழைக்காது என்பதை நாம் அறிவோம். Wait இந்த சோதனை இப்போது வேகமாகவும் நம்பகமானதாகவும் உள்ளது. இந்த சோதனையும் எளிமையானது: சேனலை பூலியனுடன் மாற்றியுள்ளோம். முன்பு சோதனை கோரூட்டீனுக்கும் கோரூட்டீனுக்கும் இடையிலான தரவு பந்தயத்தைத் தவிர்க்க ஒரு சேனலைப் பயன்படுத்த வேண்டியிருந்தது, ஆனால் இப்போது செயல்பாடு அந்த ஒத்திசைவை வழங்குகிறது. calledCh AfterFunc Wait ரேஸ் டிடெக்டர் அழைப்புகளைப் புரிந்துகொள்கிறது, மேலும் உடன் இயக்கும்போது இந்த சோதனை தேர்ச்சி பெறுகிறது. இரண்டாவது அழைப்பை நாம் அகற்றினால், ரேஸ் டிடெக்டர் சோதனையில் ஒரு டேட்டா ரேஸை சரியாகப் புகாரளிக்கும். Wait -race Wait சோதனை நேரம் ஒரே நேரத்தில் குறியீடு பெரும்பாலும் நேரத்தைக் கையாள்கிறது. நேரத்துடன் இணைந்து செயல்படும் குறியீட்டைச் சோதிப்பது கடினமாக இருக்கலாம். மேலே நாம் பார்த்தது போல, சோதனைகளில் நிகழ்நேரத்தைப் பயன்படுத்துவது மெதுவான மற்றும் சீரற்ற சோதனைகளை ஏற்படுத்துகிறது. போலி நேரத்தைப் பயன்படுத்துவதற்கு தொகுப்பு செயல்பாடுகளைத் தவிர்ப்பது அவசியம், மேலும் சோதனையின் கீழ் உள்ள குறியீட்டை விருப்பமான போலி கடிகாரத்துடன் வேலை செய்ய வடிவமைக்க வேண்டும். time தொகுப்பு நேரத்தைப் பயன்படுத்தும் குறியீட்டைச் சோதிப்பதை எளிதாக்குகிறது. testing/synctest மூலம் தொடங்கப்பட்ட குமிழியில் உள்ள கோரூட்டின்கள் ஒரு போலி கடிகாரத்தைப் பயன்படுத்துகின்றன. குமிழிக்குள், தொகுப்பில் உள்ள செயல்பாடுகள் போலி கடிகாரத்தில் இயங்குகின்றன. அனைத்து கோரூட்டின்களும் தடுக்கப்படும்போது குமிழியில் நேரம் முன்னேறும். Run time நிரூபிக்க, ஒரு சோதனையை எழுதுவோம். WithTimeout செயல்பாடு. ஒரு சூழலின் ஒரு துணையை உருவாக்குகிறது, இது ஒரு குறிப்பிட்ட நேர முடிவிற்குப் பிறகு காலாவதியாகிறது. context.WithTimeout WithTimeout func TestWithTimeout(t *testing.T) { synctest.Run(func() { const timeout = 5 * time.Second ctx, cancel := context.WithTimeout(context.Background(), timeout) defer cancel() // Wait just less than the timeout. time.Sleep(timeout - time.Nanosecond) synctest.Wait() if err := ctx.Err(); err != nil { t.Fatalf("before timeout, ctx.Err() = %v; want nil", err) } // Wait the rest of the way until the timeout. time.Sleep(time.Nanosecond) synctest.Wait() if err := ctx.Err(); err != context.DeadlineExceeded { t.Fatalf("after timeout, ctx.Err() = %v; want DeadlineExceeded", err) } }) } இந்த சோதனையை நாங்கள் நிகழ்நேரத்தில் வேலை செய்வது போல எழுதுகிறோம். ஒரே வித்தியாசம் என்னவென்றால், சோதனை செயல்பாட்டை இல் சுற்றி, அழைக்கிறோம். ஒவ்வொரு காத்திருங்கள். சூழல் தொகுப்பின் டைமர்கள் இயங்குவதை முடிக்க காத்திருக்க தூக்க அழைப்பை மேற்கொள்ளுங்கள். synctest.Run synctest.Wait time.Sleep தடுப்பு மற்றும் குமிழி ஒரு முக்கிய கருத்து என்னவென்றால், குமிழி . குமிழியில் உள்ள ஒவ்வொரு கோரூட்டீனும் தடுக்கப்படும்போது இது நிகழ்கிறது, மேலும் குமிழியில் உள்ள மற்றொரு கோரூட்டீனால் மட்டுமே தடையை நீக்க முடியும். testing/synctest நீடித்து நிலையாகத் தடுக்கப்படுகிறது ஒரு குமிழி நீடித்து நிலையாகத் தடுக்கப்படும்போது: நிலுவையில் உள்ள அழைப்பு இருந்தால், அது திரும்பும். Wait இல்லையெனில், அடுத்த முறைக்கு நேரம் நகர்கிறது, அது ஒரு கோரூட்டீனைத் தடைநீக்கக்கூடும், ஏதேனும் இருந்தால். இல்லையெனில், குமிழி முட்டுக்கட்டையாகிவிடும், மேலும் பீதியடையும். Run ஏதேனும் கோரூட்டீன் தடுக்கப்பட்டால் ஒரு குமிழி நீடித்து நிலைக்க முடியாது, ஆனால் குமிழிக்கு வெளியே இருந்து வரும் ஏதேனும் ஒரு நிகழ்வால் அது விழித்தெழக்கூடும். ஒரு கோரூட்டீனை நீடித்து நிலைக்கும் வகையில் தடுக்கும் செயல்பாடுகளின் முழுமையான பட்டியல்: பூஜ்ஜிய சேனலில் அனுப்புதல் அல்லது பெறுதல் ஒரே குமிழிக்குள் உருவாக்கப்பட்ட சேனலில் அனுப்புதல் அல்லது பெறுதல் தடுக்கப்பட்டது. ஒவ்வொரு வழக்கும் நீடித்து நிலைத்துத் தடுக்கும் ஒரு தேர்ந்தெடுக்கப்பட்ட அறிக்கை. time.Sleep sync.Cond.Wait sync.WaitGroup.Wait மியூடெக்ஸ்கள் செயல்பாடுகள். மியூடெக்ஸ் நீடித்துத் தடுக்கப்படுவதில்லை. sync.Mutex செயல்பாடுகள் ஒரு உலகளாவிய மியூடெக்ஸைப் பெறுவது பொதுவானது. எடுத்துக்காட்டாக, பிரதிபலிப்பு தொகுப்பில் உள்ள பல செயல்பாடுகள் ஒரு மியூடெக்ஸால் பாதுகாக்கப்பட்ட உலகளாவிய தற்காலிக சேமிப்பைப் பயன்படுத்துகின்றன. ஒரு ஒத்திசைவு குமிழியில் உள்ள ஒரு கோரூட்டீன், குமிழிக்கு வெளியே ஒரு கோரூட்டீனால் வைத்திருக்கப்படும் மியூடெக்ஸைப் பெறும்போது தடுக்கப்பட்டால், அது நீடித்து நிலைக்கப்படாது - அது தடுக்கப்படுகிறது, ஆனால் அதன் குமிழிக்கு வெளியே உள்ள ஒரு கோரூட்டீனால் தடை நீக்கப்படும். மியூடெக்ஸ்கள் பொதுவாக நீண்ட காலத்திற்கு வைக்கப்படுவதில்லை என்பதால், அவற்றை பரிசீலனையிலிருந்து நாங்கள் விலக்குகிறோம். testing/synctest சேனல்கள் ஒரு குமிழிக்குள் உருவாக்கப்படும் சேனல்கள் வெளியே உருவாக்கப்பட்ட சேனல்களிலிருந்து வித்தியாசமாக நடந்து கொள்கின்றன. சேனல் குமிழியாக இருந்தால் மட்டுமே (குமிழியில் உருவாக்கப்பட்டது) சேனல் செயல்பாடுகள் நீடித்து நிலைத்துத் தடுக்கப்படும். குமிழி பீதிக்கு வெளியே இருந்து குமிழி சேனலில் இயங்குவது. இந்த விதிகள் ஒரு கோரூட்டீன் அதன் குமிழிக்குள் கோரூட்டீன்களுடன் தொடர்பு கொள்ளும்போது மட்டுமே நீடித்து நிலைத்துத் தடுக்கப்படுவதை உறுதி செய்கின்றன. நான்/ஓ நெட்வொர்க் இணைப்பிலிருந்து படிப்பது போன்ற வெளிப்புற I/O செயல்பாடுகள் நீடித்துத் தடுக்கப்படுவதில்லை. குமிழிக்கு வெளியே இருந்து எழுதுவதன் மூலம், ஒருவேளை மற்ற செயல்முறைகளிலிருந்து கூட, நெட்வொர்க் வாசிப்புகள் தடைநீக்கப்படலாம். ஒரு பிணைய இணைப்பிற்கான ஒரே எழுத்தாளர் அதே குமிழியில் இருந்தாலும், கூடுதல் தரவு வருவதற்காகக் காத்திருக்கும் இணைப்புக்கும், கர்னல் தரவைப் பெற்று அதை வழங்கும் செயல்பாட்டில் உள்ள இணைப்புக்கும் இடையில் இயக்க நேரத்தால் வேறுபடுத்திப் பார்க்க முடியாது. ஒரு பிணைய சேவையகம் அல்லது கிளையண்டை synctest மூலம் சோதிக்க பொதுவாக ஒரு போலி நெட்வொர்க் செயல்படுத்தலை வழங்க வேண்டியிருக்கும். எடுத்துக்காட்டாக, செயல்பாடு ஒரு ஜோடி ஐ உருவாக்குகிறது, அவை நினைவகத்தில் உள்ள பிணைய இணைப்பைப் பயன்படுத்துகின்றன மற்றும் synctest சோதனைகளில் பயன்படுத்தப்படலாம். net.Pipe net.Conn பப்பில் வாழ்நாள் செயல்பாடு ஒரு புதிய குமிழில் ஒரு கோரூட்டீனைத் தொடங்குகிறது. குமிழில் உள்ள ஒவ்வொரு கோரூட்டீனும் வெளியேறியதும் அது திரும்பும். குமிழி நீடித்துத் தடுக்கப்பட்டு, நேரத்தை முன்னேற்றுவதன் மூலம் தடையை நீக்க முடியாவிட்டால் அது பீதியடையும். Run ரன் திரும்புவதற்கு முன்பு குமிழியில் உள்ள ஒவ்வொரு கோரூட்டீனும் வெளியேற வேண்டும் என்ற தேவை, சோதனைகள் முடிப்பதற்கு முன்பு ஏதேனும் பின்னணி கோரூட்டீன்களை சுத்தம் செய்ய கவனமாக இருக்க வேண்டும் என்பதாகும். நெட்வொர்க் குறியீட்டைச் சோதிக்கிறது இன்னொரு உதாரணத்தைப் பார்ப்போம், இந்த முறை தொகுப்பைப் பயன்படுத்தி ஒரு நெட்வொர்க் செய்யப்பட்ட நிரலைச் சோதிக்கிறோம். இந்த எடுத்துக்காட்டில், தொகுப்பின் 100 Continue பதிலைக் கையாளுவதைச் சோதிப்போம். testing/synctest net/http ஒரு கோரிக்கையை அனுப்பும் ஒரு HTTP கிளையன்ட், "எதிர்பார்ப்பு: 100-தொடரவும்" என்ற தலைப்பை உள்ளடக்கி, கிளையன்ட் அனுப்ப கூடுதல் தரவு உள்ளது என்பதை சேவையகத்திற்குத் தெரிவிக்கலாம். பின்னர் சேவையகம் மீதமுள்ள கோரிக்கையை கோர 100 தொடர் தகவல் பதிலுடன் பதிலளிக்கலாம் அல்லது உள்ளடக்கம் தேவையில்லை என்று கிளையண்டிற்குத் தெரிவிக்க வேறு ஏதேனும் நிலையுடன் பதிலளிக்கலாம். எடுத்துக்காட்டாக, ஒரு பெரிய கோப்பைப் பதிவேற்றும் கிளையன்ட், சேவையகம் கோப்பை அனுப்புவதற்கு முன்பு அதை ஏற்கத் தயாராக உள்ளதா என்பதை உறுதிப்படுத்த இந்த அம்சத்தைப் பயன்படுத்தலாம். “எதிர்பார்ப்பு: 100-தொடரவும்” தலைப்பை அனுப்பும்போது, சேவையகம் கோருவதற்கு முன்பு HTTP கிளையன்ட் கோரிக்கையின் உள்ளடக்கத்தை அனுப்புவதில்லை என்பதையும், 100 தொடர் பதிலைப் பெற்ற பிறகு உள்ளடக்கத்தை அனுப்புகிறது என்பதையும் எங்கள் சோதனை உறுதிப்படுத்தும். பெரும்பாலும் தொடர்பு கொள்ளும் கிளையன்ட் மற்றும் சர்வரின் சோதனைகள் ஒரு லூப்பேக் நெட்வொர்க் இணைப்பைப் பயன்படுத்தலாம். இருப்பினும், உடன் பணிபுரியும் போது, நெட்வொர்க்கில் அனைத்து goroutines தடுக்கப்பட்டிருக்கும் போது கண்டறிய அனுமதிக்கும் வகையில், பொதுவாக ஒரு போலி நெட்வொர்க் இணைப்பைப் பயன்படுத்த விரும்புவோம். ஆல் உருவாக்கப்பட்ட நினைவகத்தில் உள்ள நெட்வொர்க் இணைப்பைப் பயன்படுத்தும் (ஒரு HTTP கிளையன்ட்) ஐ உருவாக்குவதன் மூலம் இந்த சோதனையைத் தொடங்குவோம். testing/synctest net.Pipe http.Transport func Test(t *testing.T) { synctest.Run(func() { srvConn, cliConn := net.Pipe() defer srvConn.Close() defer cliConn.Close() tr := &http.Transport{ DialContext: func(ctx context.Context, network, address string) (net.Conn, error) { return cliConn, nil }, // Setting a non-zero timeout enables "Expect: 100-continue" handling. // Since the following test does not sleep, // we will never encounter this timeout, // even if the test takes a long time to run on a slow machine. ExpectContinueTimeout: 5 * time.Second, } இந்தப் போக்குவரத்தில் “எதிர்பார்ப்பு: 100-தொடரவும்” என்ற தலைப்புத் தொகுப்புடன் ஒரு கோரிக்கையை அனுப்புகிறோம். சோதனை முடியும் வரை அது நிறைவடையாததால், கோரிக்கை ஒரு புதிய கோரூட்டினில் அனுப்பப்படுகிறது. body := "request body" go func() { req, _ := http.NewRequest("PUT", "http://test.tld/", strings.NewReader(body)) req.Header.Set("Expect", "100-continue") resp, err := tr.RoundTrip(req) if err != nil { t.Errorf("RoundTrip: unexpected error %v", err) } else { resp.Body.Close() } }() கிளையன்ட் அனுப்பிய கோரிக்கை தலைப்புகளைப் படிக்கிறோம். req, err := http.ReadRequest(bufio.NewReader(srvConn)) if err != nil { t.Fatalf("ReadRequest: %v", err) } இப்போது நாம் சோதனையின் மையத்திற்கு வருகிறோம். வாடிக்கையாளர் இன்னும் கோரிக்கைப் பகுதியை அனுப்ப மாட்டார் என்பதை நாங்கள் உறுதியாகக் கூற விரும்புகிறோம். சேவையகத்திற்கு அனுப்பப்பட்ட உடலை ஒரு இல் நகலெடுக்கும் ஒரு புதிய கோரூட்டீனை நாங்கள் தொடங்குகிறோம், குமிழியில் உள்ள அனைத்து கோரூட்டீன்களும் தடுக்கப்படும் வரை காத்திருந்து, உடலில் இருந்து எதையும் நாங்கள் இன்னும் படிக்கவில்லை என்பதைச் சரிபார்க்கிறோம். strings.Builder நாம் அழைப்பை மறந்துவிட்டால், ரேஸ் டிடெக்டர் ஒரு தரவு பந்தயத்தைப் பற்றி சரியாகப் புகார் செய்யும், ஆனால் இது பாதுகாப்பானது. synctest.Wait Wait var gotBody strings.Builder go io.Copy(&gotBody, req.Body) synctest.Wait() if got := gotBody.String(); got != "" { t.Fatalf("before sending 100 Continue, unexpectedly read body: %q", got) } நாங்கள் வாடிக்கையாளருக்கு "100 தொடர்ச்சி" என்ற பதிலை எழுதி, அது இப்போது கோரிக்கைப் பகுதியை அனுப்புகிறதா என்பதைச் சரிபார்க்கிறோம். srvConn.Write([]byte("HTTP/1.1 100 Continue\r\n\r\n")) synctest.Wait() if got := gotBody.String(); got != body { t.Fatalf("after sending 100 Continue, read body %q, want %q", got, body) } இறுதியாக, கோரிக்கையை முடிக்க “200 சரி” பதிலை அனுப்பி முடிக்கிறோம். இந்தச் சோதனையின் போது நாங்கள் பல கோரூட்டின்களைத் தொடங்கியுள்ளோம். அழைப்பு அவை அனைத்தும் வெளியேறும் வரை காத்திருந்து திரும்பும். synctest.Run srvConn.Write([]byte("HTTP/1.1 200 OK\r\n\r\n")) }) } சேவையகம் கோரிக்கையை கேட்கவில்லை என்றால் கோரிக்கை அமைப்பு அனுப்பப்படவில்லை என்பதை சரிபார்ப்பது அல்லது சேவையகம் ஒரு காலக்கெடுவிற்குள் பதிலளிக்கவில்லை என்றால் அது அனுப்பப்பட்டதா என்பதை சரிபார்ப்பது போன்ற பிற நடத்தைகளைச் சோதிக்க இந்த சோதனையை எளிதாக நீட்டிக்க முடியும். பரிசோதனையின் நிலை Go 1.24 இல் ஒரு தொகுப்பாக அறிமுகப்படுத்துகிறோம். கருத்து மற்றும் அனுபவத்தைப் பொறுத்து, திருத்தங்களுடன் அல்லது இல்லாமல் அதை வெளியிடலாம், பரிசோதனையைத் தொடரலாம் அல்லது Go இன் எதிர்கால பதிப்பில் அதை அகற்றலாம். testing/synctest சோதனை இந்தத் தொகுப்பு முன்னிருப்பாகத் தெரியவில்லை. அதைப் பயன்படுத்த, உங்கள் சூழலில் தொகுப்புடன் உங்கள் குறியீட்டைத் தொகுக்கவும். GOEXPERIMENT=synctest உங்கள் கருத்தை நாங்கள் கேட்க விரும்புகிறோம்! நீங்கள் முயற்சித்தால், உங்கள் அனுபவங்களை, நேர்மறையாகவோ அல்லது எதிர்மறையாகவோ, இல் தெரிவிக்கவும். testing/synctest go.dev/issue/67434 நன்றி: டேமியன் நீல் இல் எடுத்த புகைப்படம். Unsplash கேப்ரியல் குஸ்மாவோ இந்தக் கட்டுரை இங்கு கிடைக்கிறது CC BY 4.0 DEED உரிமத்தின் கீழ். தி கோ வலைப்பதிவு