அலகு சோதனை பற்றிய அனைத்தும்: நுட்பங்கள், கருத்துகள், நடைமுறை

சோதனைகள் இல்லாத ஒரு பயன்பாட்டை இன்று நீங்கள் கண்டுபிடிக்க முடியாது, எனவே இந்த தலைப்பு புதிய டெவலப்பர்களுக்கு முன்பை விட மிகவும் பொருத்தமானதாக இருக்கும்: சோதனைகள் இல்லாமல் நீங்கள் வெற்றிபெற முடியாது. கொள்கையளவில் எந்த வகையான சோதனைகள் பயன்படுத்தப்படுகின்றன என்பதைக் கருத்தில் கொள்வோம், பின்னர் அலகு சோதனை பற்றி தெரிந்து கொள்ள வேண்டிய அனைத்தையும் விரிவாகப் படிப்போம்.

சோதனை வகைகள்

சோதனை என்றால் என்ன? விக்கிபீடியாவின் கூற்றுப்படி: "மென்பொருள் சோதனை என்பது ஒன்று அல்லது அதற்கு மேற்பட்ட ஆர்வமுள்ள பண்புகளை மதிப்பிடுவதற்கு ஒரு மென்பொருள் கூறு அல்லது கணினி கூறுகளை செயல்படுத்துவதை உள்ளடக்கியது." வேறு வார்த்தைகளில் கூறுவதானால், இது சில சூழ்நிலைகளில் எங்கள் கணினியின் சரியான தன்மையை சரிபார்க்கிறது. சரி, பொதுவாக என்ன வகையான சோதனைகள் உள்ளன என்பதைப் பார்ப்போம்:

• அலகு சோதனை - கணினியின் ஒவ்வொரு தொகுதியையும் தனித்தனியாக சரிபார்க்கும் சோதனைகள். இந்தச் சோதனைகள் கணினியின் மிகச்சிறிய அணு பாகங்களுக்குப் பயன்படுத்தப்பட வேண்டும், எ.கா. தொகுதிகள்.
• கணினி சோதனை — ஒரு பெரிய அளவிலான பயன்பாடு அல்லது கணினியின் செயல்பாட்டைச் சரிபார்க்க உயர்நிலை சோதனை.
• பின்னடைவு சோதனை — புதிய அம்சங்கள் அல்லது பிழை திருத்தங்கள் பயன்பாட்டின் தற்போதைய செயல்பாட்டை பாதிக்கிறதா அல்லது பழைய பிழைகளை அறிமுகப்படுத்துகிறதா என்பதைச் சரிபார்க்கப் பயன்படும் சோதனை.
• செயல்பாட்டு சோதனை - விவரக்குறிப்புகள், பயனர் கதைகள் போன்றவற்றில் கூறப்பட்டுள்ள தேவைகளை பயன்பாட்டின் ஒரு பகுதி பூர்த்திசெய்கிறதா என்பதைச் சரிபார்க்கிறது.

  செயல்பாட்டு சோதனையின் வகைகள்:

  • ஒயிட்-பாக்ஸ் சோதனை - பயன்பாட்டின் ஒரு பகுதி தேவைகளைப் பூர்த்திசெய்கிறதா என்பதைச் சரிபார்த்து, கணினியின் உள் செயலாக்கத்தை அறிந்துகொள்ளுதல்;
  • பிளாக்-பாக்ஸ் சோதனை - கணினியின் உள் செயலாக்கம் தெரியாமல் பயன்பாட்டின் ஒரு பகுதி தேவைகளைப் பூர்த்திசெய்கிறதா என்பதைச் சரிபார்க்கிறது.

• செயல்திறன் சோதனை - ஒரு குறிப்பிட்ட சுமையின் கீழ் கணினி அல்லது அமைப்பின் பகுதி எவ்வாறு செயல்படுகிறது என்பதை தீர்மானிக்க எழுதப்பட்ட சோதனைகள்.
• சுமை சோதனை - நிலையான சுமைகளின் கீழ் கணினியின் நிலைத்தன்மையை சரிபார்க்கவும், பயன்பாடு இன்னும் சரியாக வேலை செய்யும் அதிகபட்ச சுமையை கண்டறியவும் வடிவமைக்கப்பட்ட சோதனைகள்.
• அழுத்த சோதனை — தரமற்ற சுமைகளின் கீழ் பயன்பாட்டின் செயல்திறனைச் சரிபார்க்கவும் மற்றும் கணினி தோல்விக்கு முன் அதிகபட்ச சுமையைக் கண்டறியவும் வடிவமைக்கப்பட்ட சோதனை.
• பாதுகாப்பு சோதனை - கணினியின் பாதுகாப்பைச் சரிபார்க்கப் பயன்படுத்தப்படும் சோதனைகள் (ஹேக்கர்கள், வைரஸ்கள், ரகசியத் தரவுகளுக்கான அங்கீகரிக்கப்படாத அணுகல் மற்றும் பிற மகிழ்ச்சிகரமான தாக்குதல்கள்).
• உள்ளூர்மயமாக்கல் சோதனை - பயன்பாட்டின் உள்ளூர்மயமாக்கலின் சோதனைகள்.
• பயன்பாட்டு சோதனை - பயன்பாட்டினை, புரிந்துகொள்ளக்கூடிய தன்மை, கவர்ச்சி மற்றும் கற்றல் ஆகியவற்றைச் சரிபார்க்கும் நோக்கில் சோதனை.

இவை அனைத்தும் நன்றாகத் தெரிகிறது, ஆனால் நடைமுறையில் இது எவ்வாறு செயல்படுகிறது? எளிமையானது! நாங்கள் மைக் கோனின் சோதனை பிரமிடைப் பயன்படுத்துகிறோம்: இது பிரமிட்டின் எளிமைப்படுத்தப்பட்ட பதிப்பாகும்: இது இப்போது சிறிய பகுதிகளாகப் பிரிக்கப்பட்டுள்ளது. ஆனால் இன்று நாம் மிகவும் நுட்பமாக இருக்க மாட்டோம். எளிமையான பதிப்பை நாங்கள் கருத்தில் கொள்வோம்.

1. யூனிட் - இந்த பிரிவு யூனிட் சோதனைகளைக் குறிக்கிறது, அவை பயன்பாட்டின் வெவ்வேறு அடுக்குகளில் பயன்படுத்தப்படுகின்றன. பயன்பாட்டு தர்க்கத்தின் மிகச்சிறிய வகுக்கக்கூடிய அலகுகளை அவை சோதிக்கின்றன. உதாரணமாக, வகுப்புகள், ஆனால் பெரும்பாலும் முறைகள். இந்த சோதனைகள் பொதுவாக எந்த வெளிப்புற தர்க்கத்திலிருந்தும் சோதிக்கப்பட்டதை தனிமைப்படுத்த முடிந்தவரை முயற்சி செய்கின்றன. அதாவது, மீதமுள்ள பயன்பாடு எதிர்பார்த்தபடி இயங்குகிறது என்ற மாயையை உருவாக்க முயற்சிக்கிறார்கள்.

   இந்த சோதனைகள் (வேறு எந்த வகையையும் விட அதிகமாக) எப்போதும் இருக்க வேண்டும், ஏனெனில் அவை சிறிய துண்டுகளை சோதிக்கின்றன மற்றும் மிகவும் இலகுவானவை, நிறைய வளங்களை உட்கொள்ளாது (ரேம் மற்றும் நேரம் என்று பொருள்).

2. ஒருங்கிணைப்பு - இந்தப் பிரிவு ஒருங்கிணைப்பு சோதனையைக் குறிக்கிறது. இந்த சோதனையானது கணினியின் பெரிய பகுதிகளை சரிபார்க்கிறது. அதாவது, இது தர்க்கத்தின் பல பகுதிகளை (பல முறைகள் அல்லது வகுப்புகள்) ஒருங்கிணைக்கிறது, அல்லது வெளிப்புறக் கூறுகளுடனான தொடர்புகளின் சரியான தன்மையை சரிபார்க்கிறது. இந்த சோதனைகள் பொதுவாக அலகு சோதனைகளை விட சிறியதாக இருக்கும், ஏனெனில் அவை கனமானவை.

   ஒரு ஒருங்கிணைப்பு சோதனையின் உதாரணம் தரவுத்தளத்துடன் இணைத்து அதனுடன் பணிபுரியும் முறைகளின் செயல்பாட்டின் சரியான தன்மையை சரிபார்க்கலாம்.

3. UI — இந்தப் பிரிவு பயனர் இடைமுகத்தின் செயல்பாட்டைச் சரிபார்க்கும் சோதனைகளைக் குறிக்கிறது. அவை பயன்பாட்டின் அனைத்து நிலைகளிலும் உள்ள தர்க்கத்தை உள்ளடக்கியது, அதனால்தான் அவை இறுதி முதல் இறுதி சோதனைகள் என்றும் அழைக்கப்படுகின்றன. ஒரு விதியாக, அவற்றில் மிகக் குறைவானவை உள்ளன, ஏனென்றால் அவை மிகவும் சிக்கலானவை மற்றும் மிகவும் தேவையான (பயன்படுத்தப்பட்ட) பாதைகளை சரிபார்க்க வேண்டும்.

   மேலே உள்ள படத்தில், முக்கோணத்தின் வெவ்வேறு பகுதிகள் அளவு வேறுபடுவதைக் காண்கிறோம்: உண்மையான வேலையில் வெவ்வேறு வகையான சோதனைகளின் எண்ணிக்கையில் தோராயமாக அதே விகிதங்கள் உள்ளன.

   இன்று நாம் மிகவும் பொதுவான சோதனைகள், யூனிட் சோதனைகள் ஆகியவற்றைக் கூர்ந்து கவனிப்போம், ஏனெனில் அனைத்து சுய மரியாதைக்குரிய ஜாவா டெவலப்பர்களும் அவற்றை அடிப்படை மட்டத்தில் பயன்படுத்த முடியும்.

அலகு சோதனையின் முக்கிய கருத்துக்கள்

சோதனை கவரேஜ் (குறியீடு கவரேஜ்) என்பது ஒரு பயன்பாடு எவ்வளவு சிறப்பாக சோதிக்கப்படுகிறது என்பதற்கான முக்கிய நடவடிக்கைகளில் ஒன்றாகும். சோதனைகள் (0-100%) உள்ளடக்கிய குறியீட்டின் சதவீதம் இதுவாகும். நடைமுறையில், பலர் இந்த சதவீதத்தை தங்கள் இலக்காகப் பின்பற்றுகிறார்கள். இது நான் உடன்படாத ஒன்று, ஏனென்றால் சோதனைகள் தேவையில்லாத இடங்களில் பயன்படுத்தத் தொடங்குகின்றன. எடுத்துக்காட்டாக, எங்கள் சேவையில் கூடுதல் தர்க்கம் இல்லாமல் நிலையான CRUD (உருவாக்கம்/பெறுதல்/புதுப்பித்தல்/நீக்கு) செயல்பாடுகள் உள்ளன என்று வைத்துக்கொள்வோம். இந்த முறைகள் முற்றிலும் இடைத்தரகர்கள், அவை களஞ்சியத்துடன் பணிபுரியும் அடுக்குக்கு வேலையை வழங்குகின்றன. இந்த சூழ்நிலையில், கொடுக்கப்பட்ட முறை DAO முறையை அழைக்கிறதா என்பதைத் தவிர, நாங்கள் சோதிக்க எதுவும் இல்லை, ஆனால் அது ஒரு நகைச்சுவை. சோதனைக் கவரேஜை மதிப்பிடுவதற்கு கூடுதல் கருவிகள் வழக்கமாகப் பயன்படுத்தப்படுகின்றன: ஜாகோகோ, கோபெர்டுரா, க்ளோவர், எம்மா போன்றவை. இந்த தலைப்பைப் பற்றிய விரிவான ஆய்வுக்கு,

• மீடியத்தில் குறியீடு கவரேஜ்
• கருப்பு பெட்டி சோதனை: எடுத்துக்காட்டுகள் மற்றும் நுட்பங்களுடன் ஒரு ஆழமான பயிற்சி

TDD என்பது சோதனை சார்ந்த வளர்ச்சியைக் குறிக்கிறது. இந்த அணுகுமுறையில், வேறு எதையும் செய்வதற்கு முன், குறிப்பிட்ட குறியீட்டைச் சரிபார்க்கும் ஒரு சோதனையை எழுதுங்கள். இது பிளாக்-பாக்ஸ் சோதனையாக மாறிவிடும்: உள்ளீடு என்ன என்பதை நாங்கள் அறிவோம் மற்றும் வெளியீடு என்னவாக இருக்க வேண்டும் என்பது எங்களுக்குத் தெரியும். இது குறியீடு நகலெடுப்பதைத் தவிர்க்க உதவுகிறது. சோதனை உந்துதல் மேம்பாடு உங்கள் பயன்பாட்டில் உள்ள ஒவ்வொரு பிட் செயல்பாட்டிற்கும் சோதனைகளை வடிவமைத்து மேம்படுத்துவதில் தொடங்குகிறது. TDD அணுகுமுறையில், குறியீட்டின் நடத்தையை வரையறுத்து சோதிக்கும் சோதனையை முதலில் உருவாக்குவோம். TDD இன் முக்கிய குறிக்கோள், உங்கள் குறியீட்டை மிகவும் புரிந்துகொள்ளக்கூடியதாகவும், எளிமையாகவும், பிழையின்றியும் மாற்றுவதாகும். அணுகுமுறை பின்வருவனவற்றைக் கொண்டுள்ளது:

• நாங்கள் எங்கள் தேர்வை எழுதுகிறோம்.
• நாங்கள் சோதனையை நடத்துகிறோம். ஆச்சரியப்படத்தக்க வகையில், தேவையான தர்க்கத்தை நாங்கள் இன்னும் செயல்படுத்தாததால், அது தோல்வியடைகிறது.
• சோதனை வெற்றிபெற காரணமான குறியீட்டைச் சேர்க்கவும் (சோதனையை மீண்டும் இயக்குவோம்).
• நாங்கள் குறியீட்டை மறுபரிசீலனை செய்கிறோம்.

TDD ஆனது யூனிட் சோதனைகளை அடிப்படையாகக் கொண்டது, ஏனெனில் அவை சோதனை ஆட்டோமேஷன் பிரமிடில் மிகச்சிறிய கட்டுமானத் தொகுதிகள் ஆகும். யூனிட் சோதனைகள் மூலம், எந்த வகுப்பின் வணிக தர்க்கத்தையும் நாம் சோதிக்க முடியும். BDD என்பது நடத்தை சார்ந்த வளர்ச்சியைக் குறிக்கிறது. இந்த அணுகுமுறை TDD அடிப்படையிலானது. மேலும் குறிப்பாக, வளர்ச்சியில் ஈடுபட்டுள்ள அனைவருக்கும் கணினி நடத்தையை விளக்கும் எளிய மொழி உதாரணங்களைப் பயன்படுத்துகிறது. இது முக்கியமாக சோதனையாளர்கள் மற்றும் வணிக ஆய்வாளர்களை பாதிக்கும் என்பதால், இந்த வார்த்தையை நாங்கள் ஆராய மாட்டோம். சோதனை வழக்கு என்பது சோதனையின் கீழ் உள்ள குறியீட்டைச் சரிபார்க்க தேவையான படிகள், குறிப்பிட்ட நிபந்தனைகள் மற்றும் அளவுருக்கள் ஆகியவற்றை விவரிக்கும் ஒரு காட்சியாகும். சோதனைப் பொருத்தம் என்பது சோதனையின் கீழ் உள்ள முறை வெற்றிகரமாக இயங்குவதற்குத் தேவையான நிலையைக் கொண்டிருக்கும் சோதனை சூழலை அமைக்கும் குறியீடாகும். இது ஒரு முன் வரையறுக்கப்பட்ட பொருள்கள் மற்றும் குறிப்பிட்ட நிபந்தனைகளின் கீழ் அவற்றின் நடத்தை.

சோதனையின் நிலைகள்

ஒரு சோதனை மூன்று நிலைகளைக் கொண்டுள்ளது:

• சோதனைத் தரவைக் குறிப்பிடவும் (உறுதிகள்).
• சோதனையின் கீழ் உள்ள குறியீட்டைப் பயன்படுத்தவும் (சோதனை செய்யப்பட்ட முறையை அழைக்கவும்).
• முடிவுகளை சரிபார்த்து, எதிர்பார்த்த முடிவுகளுடன் ஒப்பிடவும்.

சோதனை மாடுலாரிட்டியை உறுதிப்படுத்த, நீங்கள் பயன்பாட்டின் மற்ற அடுக்குகளிலிருந்து தனிமைப்படுத்த வேண்டும். ஸ்டப்ஸ், மோக்ஸ் மற்றும் உளவாளிகளைப் பயன்படுத்தி இதைச் செய்யலாம். மாக்ஸ் என்பது தனிப்பயனாக்கக்கூடிய பொருள்கள் (உதாரணமாக, ஒவ்வொரு சோதனைக்கும் ஏற்றது). முறை அழைப்புகளில் இருந்து நாம் என்ன எதிர்பார்க்கிறோம் என்பதை அவர்கள் குறிப்பிடலாம், அதாவது எதிர்பார்க்கப்படும் பதில்கள். நாம் எதிர்பார்ப்பதைப் பெறுகிறோம் என்பதைச் சரிபார்க்க போலிப் பொருட்களைப் பயன்படுத்துகிறோம். சோதனையின் போது அழைப்புகளுக்கு ஸ்டப்கள் கடின குறியிடப்பட்ட பதிலை வழங்குகின்றன. அவர்கள் அழைப்பைப் பற்றிய தகவலையும் சேமிக்க முடியும் (எடுத்துக்காட்டாக, அளவுருக்கள் அல்லது அழைப்புகளின் எண்ணிக்கை). இவர்கள் சில சமயங்களில் உளவாளிகள் என்று குறிப்பிடப்படுகிறார்கள். சில நேரங்களில் மக்கள் ஸ்டப் மற்றும் மோக் என்ற சொற்களைக் குழப்புகிறார்கள்: வித்தியாசம் என்னவென்றால், ஒரு ஸ்டப் எதையும் சரிபார்க்காது - இது கொடுக்கப்பட்ட நிலையை மட்டுமே உருவகப்படுத்துகிறது. ஒரு போலி என்பது எதிர்பார்ப்புகளைக் கொண்ட ஒரு பொருள். எடுத்துக்காட்டாக, கொடுக்கப்பட்ட முறை ஒரு குறிப்பிட்ட எண்ணிக்கையிலான முறை அழைக்கப்பட வேண்டும். வேறு வார்த்தைகளில் கூறுவதானால்,

சோதனை சூழல்கள்

எனவே, இப்போது புள்ளி. ஜாவாவிற்கு பல சோதனை சூழல்கள் (கட்டமைப்புகள்) உள்ளன. இவற்றில் மிகவும் பிரபலமானவை ஜூனிட் மற்றும் டெஸ்ட்என்ஜி. இங்கே எங்கள் மதிப்பாய்விற்கு, நாங்கள் பயன்படுத்துகிறோம்: ஒரு ஜூனிட் சோதனை என்பது சோதனைக்கு மட்டுமே பயன்படுத்தப்படும் வகுப்பில் உள்ள ஒரு முறையாகும். வகுப்பானது வழக்கமாக அது சோதிக்கும் வகுப்பின் பெயரிலேயே பெயரிடப்படுகிறது, இறுதியில் "சோதனை" சேர்க்கப்பட்டுள்ளது. எடுத்துக்காட்டாக, CarService -> CarServiceTest. மேவன் பில்ட் சிஸ்டம் தானாகவே சோதனை நோக்கத்தில் இத்தகைய வகுப்புகளை உள்ளடக்கியது. உண்மையில், இந்த வகுப்பு சோதனை வகுப்பு என்று அழைக்கப்படுகிறது. அடிப்படைக் குறிப்புகளை சுருக்கமாகப் பார்ப்போம்:

• @Test என்பது முறை ஒரு சோதனை என்பதைக் குறிக்கிறது (அடிப்படையில், இந்த சிறுகுறிப்புடன் குறிக்கப்பட்ட ஒரு முறை ஒரு அலகு சோதனை).
• @முன் என்பது ஒவ்வொரு சோதனைக்கும் முன் செயல்படுத்தப்படும் ஒரு முறையைக் குறிக்கிறது. எடுத்துக்காட்டாக, சோதனைத் தரவைக் கொண்டு வகுப்பை விரிவுபடுத்த, உள்ளீட்டுத் தரவைப் படிக்கவும்.
• @After என்பது ஒவ்வொரு சோதனைக்குப் பிறகும் அழைக்கப்படும் ஒரு முறையைக் குறிக்கப் பயன்படுகிறது (எ.கா. தரவை அழிக்க அல்லது இயல்புநிலை மதிப்புகளை மீட்டெடுக்க).
• @BeforeClass என்பது ஒரு முறைக்கு மேலே வைக்கப்பட்டுள்ளது, இது @Before க்கு ஒப்பானது. ஆனால் அத்தகைய முறை கொடுக்கப்பட்ட வகுப்பிற்கான அனைத்து சோதனைகளுக்கும் முன்பு ஒரு முறை மட்டுமே அழைக்கப்படுகிறது, எனவே நிலையானதாக இருக்க வேண்டும். சோதனை தரவுத்தளத்தை சுழற்றுவது போன்ற அதிக ஆதார-தீவிர செயல்பாடுகளைச் செய்ய இது பயன்படுகிறது.
• @AfterClass என்பது @BeforeClass க்கு எதிரானது: கொடுக்கப்பட்ட வகுப்பிற்கு இது ஒருமுறை செயல்படுத்தப்படும், ஆனால் அனைத்து சோதனைகளுக்கும் பிறகுதான். எடுத்துக்காட்டாக, நிலையான ஆதாரங்களை அழிக்க அல்லது தரவுத்தளத்திலிருந்து துண்டிக்க இது பயன்படுத்தப்படுகிறது.
• @புறக்கணிப்பு என்பது ஒரு முறை முடக்கப்பட்டுள்ளது மற்றும் ஒட்டுமொத்த சோதனை ஓட்டத்தின் போது புறக்கணிக்கப்படும் என்பதைக் குறிக்கிறது. இது பல்வேறு சூழ்நிலைகளில் பயன்படுத்தப்படுகிறது, உதாரணமாக, அடிப்படை முறை மாற்றப்பட்டு, மாற்றங்களுக்கு இடமளிக்கும் வகையில் சோதனை இன்னும் மறுவேலை செய்யப்படவில்லை. இதுபோன்ற சந்தர்ப்பங்களில், ஒரு விளக்கத்தைச் சேர்ப்பது விரும்பத்தக்கது, அதாவது @புறக்கணி ("சில விளக்கம்").
• @Test(எதிர்பார்க்கப்பட்டது = Exception.class) எதிர்மறை சோதனைகளுக்கு பயன்படுத்தப்படுகிறது. பிழையின் போது முறை எவ்வாறு செயல்படுகிறது என்பதைச் சரிபார்க்கும் சோதனைகள் இவை, அதாவது, ஒருவித விதிவிலக்கு முறையை சோதனை எதிர்பார்க்கிறது. அத்தகைய முறை @Test சிறுகுறிப்பு மூலம் குறிக்கப்படுகிறது, ஆனால் எந்தப் பிழையைப் பிடிக்க வேண்டும் என்பதற்கான அறிகுறியுடன்.
• @சோதனை(காலக்கெடு = 100) முறையானது 100 மில்லி விநாடிகளுக்கு மேல் இல்லை என்பதைச் சரிபார்க்கிறது.
• @Mock ஒரு போலி பொருளை ஒதுக்க புலத்தின் மேலே பயன்படுத்தப்படுகிறது (இது JUnit சிறுகுறிப்பு அல்ல, மாறாக Mockito இலிருந்து வந்தது). தேவைக்கேற்ப, ஒரு குறிப்பிட்ட சூழ்நிலைக்கு நேரடியாக சோதனை முறையில் போலியின் நடத்தையை அமைக்கிறோம்.
• @RunWith(MockitoJUnitRunner.class) ஒரு வகுப்பிற்கு மேல் வைக்கப்பட்டுள்ளது. இந்த சிறுகுறிப்பு ஜூனிட்டிடம் வகுப்பில் சோதனைகளைத் தொடங்கச் சொல்கிறது. மோக்கிட்டோஜூனிட் ரன்னர், ஜூனிட் பிளாட்ஃபார்ம் மற்றும் ஸ்பிரிங் ரன்னர் உட்பட பல்வேறு ரன்னர்கள் உள்ளனர். ஜூன் 5 இல், @RunWith சிறுகுறிப்பு மிகவும் சக்திவாய்ந்த @ExtendWith சிறுகுறிப்பு மூலம் மாற்றப்பட்டது.

முடிவுகளை ஒப்பிடுவதற்குப் பயன்படுத்தப்படும் சில முறைகளைப் பார்ப்போம்:

• assertEquals(ஆப்ஜெக்ட் எதிர்பார்க்கப்படுகிறது, பொருள் உண்மைகள்) — அனுப்பப்பட்ட பொருள்கள் சமமாக உள்ளதா என்பதைச் சரிபார்க்கிறது.
• assertTrue(பூலியன் கொடி) — அனுப்பப்பட்ட மதிப்பு உண்மையா என்பதைச் சரிபார்க்கிறது.
• assertFalse(பூலியன் கொடி) — அனுப்பப்பட்ட மதிப்பு தவறானதா என்பதைச் சரிபார்க்கிறது.
• assertNull(பொருள் பொருள்) - அனுப்பப்பட்ட பொருள் பூஜ்யமா என்பதை சரிபார்க்கிறது.
• assertSame (பொருள் முதல் பொருள், பொருள் இரண்டாவது பொருள்) - அனுப்பப்பட்ட மதிப்புகள் ஒரே பொருளைக் குறிக்கின்றனவா என்பதைச் சரிபார்க்கிறது.
• வலியுறுத்து(டி டி, மேட்சர் பொருத்தி) - மேட்சரில் குறிப்பிடப்பட்டுள்ள நிபந்தனையை t திருப்திப்படுத்துகிறதா என்பதைச் சரிபார்க்கிறது.

AssertJ ஒரு பயனுள்ள ஒப்பீட்டு முறையையும் வழங்குகிறது: assertThat(firstObject).isEqualTo(secondObject) . இங்கே நான் அடிப்படை முறைகளை குறிப்பிட்டுள்ளேன் - மற்றவை மேலே உள்ள மாறுபாடுகள்.

நடைமுறையில் சோதனை

இப்போது ஒரு குறிப்பிட்ட எடுத்துக்காட்டில் மேலே உள்ள பொருளைப் பார்ப்போம். சேவையின் புதுப்பிப்பு முறையை நாங்கள் சோதிப்போம். DAO லேயரை நாங்கள் கருத்தில் கொள்ள மாட்டோம், ஏனெனில் நாங்கள் இயல்புநிலையைப் பயன்படுத்துகிறோம். சோதனைகளுக்கு ஒரு ஸ்டார்ட்டரைச் சேர்ப்போம்:

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-test</artifactId>
   <version>2.2.2.RELEASE</version>
   <scope>test</scope>
</dependency>

இங்கே எங்களிடம் சேவை வகுப்பு உள்ளது:

@Service
@RequiredArgsConstructor
public class RobotServiceImpl implements RobotService {
   private final RobotDAO robotDAO;

   @Override
   public Robot update(Long id, Robot robot) {
       Robot found = robotDAO.findById(id);
       return robotDAO.update(Robot.builder()
               .id(id)
               .name(robot.getName() != null ? robot.getName() : found.getName())
               .cpu(robot.getCpu() != null ? robot.getCpu() : found.getCpu())
               .producer(robot.getProducer() != null ? robot.getProducer() : found.getProducer())
               .build());
   }
}

வரி 8 - தரவுத்தளத்திலிருந்து புதுப்பிக்கப்பட்ட பொருளை இழுக்கவும். வரிகள் 9-14 - பில்டர் மூலம் ஒரு பொருளை உருவாக்கவும். உள்வரும் பொருளுக்கு புலம் இருந்தால், அதை அமைக்கவும். இல்லையென்றால், தரவுத்தளத்தில் உள்ளதை விட்டுவிடுவோம். இப்போது எங்கள் சோதனையைப் பாருங்கள்:

@RunWith(MockitoJUnitRunner.class)
public class RobotServiceImplTest {
   @Mock
   private RobotDAO robotDAO;

   private RobotServiceImpl robotService;

   private static Robot testRobot;

   @BeforeClass
   public static void prepareTestData() {
       testRobot = Robot
               .builder()
               .id(123L)
               .name("testRobotMolly")
               .cpu("Intel Core i7-9700K")
               .producer("China")
               .build();
   }

   @Before
   public void init() {
       robotService = new RobotServiceImpl(robotDAO);
   }

வரி 1 - எங்கள் ரன்னர். வரி 4 - DAO லேயரில் இருந்து ஒரு போலியை மாற்றுவதன் மூலம் சேவையை தனிமைப்படுத்துகிறோம். வரி 11 — வகுப்பிற்கு ஒரு சோதனை நிறுவனத்தை (கினிப் பன்றியாகப் பயன்படுத்துவோம்) அமைத்துள்ளோம். வரி 22 - நாங்கள் சேவைப் பொருளை அமைத்துள்ளோம், அதை நாங்கள் சோதிப்போம்.

@Test
public void updateTest() {
   when(robotDAO.findById(any(Long.class))).thenReturn(testRobot);
   when(robotDAO.update(any(Robot.class))).then(returnsFirstArg());
   Robot robotForUpdate = Robot
           .builder()
           .name("Vally")
           .cpu("AMD Ryzen 7 2700X")
           .build();

   Robot resultRobot = robotService.update(123L, robotForUpdate);

   assertNotNull(resultRobot);
   assertSame(resultRobot.getId(),testRobot.getId());
   assertThat(resultRobot.getName()).isEqualTo(robotForUpdate.getName());
   assertTrue(resultRobot.getCpu().equals(robotForUpdate.getCpu()));
   assertEquals(resultRobot.getProducer(),testRobot.getProducer());
}

சோதனையில் மூன்று தெளிவான பிரிவுகள் இருப்பதை இங்கே காண்கிறோம்: கோடுகள் 3-9 - பொருத்துதல்களைக் குறிப்பிடுகிறது. வரி 11 - சோதனையின் கீழ் குறியீட்டை இயக்குகிறது. வரிகள் 13-17 - முடிவுகளை சரிபார்க்கிறது. இன்னும் விரிவாக: கோடுகள் 3-4 — DAO மோக்கிற்கான நடத்தையை அமைக்கவும். வரி 5 — எங்களின் தரநிலையின் மேல் புதுப்பிப்போம் என்பதை அமைக்கவும். வரி 11 - முறையைப் பயன்படுத்தி, அதன் விளைவாக எடுக்கப்பட்ட உதாரணத்தை எடுத்துக் கொள்ளுங்கள். வரி 13 - அது பூஜ்யமாக இல்லை என்பதை சரிபார்க்கவும். வரி 14 - முடிவு மற்றும் கொடுக்கப்பட்ட முறை வாதங்களின் ஐடியை ஒப்பிடுக. வரி 15 - பெயர் புதுப்பிக்கப்பட்டதா என சரிபார்க்கவும். வரி 16 — CPU முடிவைப் பார்க்கவும். வரி 17 — இந்த புலத்தை நாங்கள் குறிப்பிடவில்லை, எனவே அது அப்படியே இருக்க வேண்டும். அந்த நிலையை இங்கு சரிபார்க்கிறோம். அதை இயக்குவோம்:சோதனை பச்சை! நாம் நிம்மதிப் பெருமூச்சு விடலாம் :) சுருக்கமாக, சோதனையானது குறியீட்டின் தரத்தை மேம்படுத்துகிறது மற்றும் வளர்ச்சி செயல்முறையை மேலும் நெகிழ்வானதாகவும் நம்பகமானதாகவும் ஆக்குகிறது. நூற்றுக்கணக்கான வகுப்பு கோப்புகளை உள்ளடக்கிய மென்பொருளை மறுவடிவமைப்பு செய்ய எவ்வளவு முயற்சி எடுக்க வேண்டும் என்று கற்பனை செய்து பாருங்கள். இந்த வகுப்புகள் அனைத்திற்கும் யூனிட் தேர்வுகள் எழுதப்பட்டால், நாம் நம்பிக்கையுடன் மறுபரிசீலனை செய்யலாம். மற்றும் மிக முக்கியமாக, இது வளர்ச்சியின் போது பிழைகளை எளிதாகக் கண்டறிய உதவுகிறது. நண்பர்களே, இன்று எனக்கு கிடைத்தது அவ்வளவுதான். எனக்கு ஒரு லைக் கொடுங்கள், கருத்து தெரிவிக்கவும் :)