యూనిట్ టెస్టింగ్ గురించి అన్నీ: పద్ధతులు, భావనలు, అభ్యాసం

ఈ రోజు మీరు పరీక్షలతో కప్పబడని అప్లికేషన్‌ను కనుగొనలేరు, కాబట్టి ఈ అంశం అనుభవం లేని డెవలపర్‌లకు గతంలో కంటే మరింత సందర్భోచితంగా ఉంటుంది: మీరు పరీక్షలు లేకుండా విజయం సాధించలేరు. సూత్రప్రాయంగా ఏ రకమైన పరీక్షలను ఉపయోగించాలో పరిశీలిద్దాం, ఆపై యూనిట్ పరీక్ష గురించి తెలుసుకోవలసిన ప్రతిదాన్ని మేము వివరంగా అధ్యయనం చేస్తాము.

పరీక్ష రకాలు

పరీక్ష అంటే ఏమిటి? వికీపీడియా ప్రకారం: "సాఫ్ట్‌వేర్ టెస్టింగ్‌లో ఒకటి లేదా అంతకంటే ఎక్కువ ఆసక్తి ఉన్న లక్షణాలను అంచనా వేయడానికి సాఫ్ట్‌వేర్ భాగం లేదా సిస్టమ్ కాంపోనెంట్‌ని అమలు చేయడం ఉంటుంది." మరో మాటలో చెప్పాలంటే, ఇది నిర్దిష్ట పరిస్థితులలో మా సిస్టమ్ యొక్క ఖచ్చితత్వాన్ని తనిఖీ చేస్తుంది. సరే, సాధారణంగా ఏ రకమైన పరీక్షలు ఉన్నాయో చూద్దాం:

• యూనిట్ టెస్టింగ్ — సిస్టమ్ యొక్క ప్రతి మాడ్యూల్‌ను విడిగా తనిఖీ చేయడం దీని ఉద్దేశ్యమైన పరీక్షలు. ఈ పరీక్షలు సిస్టమ్‌లోని అతి చిన్న పరమాణు భాగాలకు వర్తిస్తాయి, ఉదా మాడ్యూల్స్.
• సిస్టమ్ టెస్టింగ్ — అప్లికేషన్ యొక్క పెద్ద భాగం లేదా మొత్తం సిస్టమ్ యొక్క ఆపరేషన్‌ను తనిఖీ చేయడానికి ఉన్నత-స్థాయి పరీక్ష.
• రిగ్రెషన్ టెస్టింగ్ — కొత్త ఫీచర్లు లేదా బగ్ పరిష్కారాలు అప్లికేషన్ యొక్క ప్రస్తుత కార్యాచరణను ప్రభావితం చేస్తాయా లేదా పాత బగ్‌లను పరిచయం చేస్తున్నాయో లేదో తనిఖీ చేయడానికి ఉపయోగించే పరీక్ష.
• ఫంక్షనల్ టెస్టింగ్ — అప్లికేషన్‌లోని కొంత భాగం స్పెసిఫికేషన్‌లు, యూజర్ స్టోరీలు మొదలైన వాటిలో పేర్కొన్న అవసరాలను సంతృప్తి పరుస్తుందో లేదో తనిఖీ చేస్తుంది.

  ఫంక్షనల్ టెస్టింగ్ రకాలు:

  • వైట్-బాక్స్ టెస్టింగ్ — సిస్టమ్ యొక్క అంతర్గత అమలును తెలుసుకుంటూ అప్లికేషన్‌లోని కొంత భాగం అవసరాలను తీరుస్తుందో లేదో తనిఖీ చేయడం;
  • బ్లాక్-బాక్స్ టెస్టింగ్ — సిస్టమ్ యొక్క అంతర్గత అమలు గురించి తెలియకుండానే అప్లికేషన్‌లో కొంత భాగం అవసరాలను తీరుస్తుందో లేదో తనిఖీ చేస్తోంది.

• పనితీరు పరీక్ష — సిస్టమ్ లేదా సిస్టమ్ యొక్క భాగం నిర్దిష్ట లోడ్‌లో ఎలా పని చేస్తుందో నిర్ణయించడానికి వ్రాయబడిన పరీక్షలు.
• లోడ్ పరీక్ష — ప్రామాణిక లోడ్‌ల క్రింద సిస్టమ్ యొక్క స్థిరత్వాన్ని తనిఖీ చేయడానికి మరియు అప్లికేషన్ ఇప్పటికీ సరిగ్గా పని చేసే గరిష్ట లోడ్‌ను కనుగొనడానికి రూపొందించబడిన పరీక్షలు.
• ఒత్తిడి పరీక్ష — ప్రామాణికం కాని లోడ్‌ల క్రింద అప్లికేషన్ యొక్క పనితీరును తనిఖీ చేయడానికి మరియు సిస్టమ్ వైఫల్యానికి ముందు గరిష్ట లోడ్‌ను నిర్ణయించడానికి రూపొందించబడిన పరీక్ష.
• భద్రతా పరీక్ష — సిస్టమ్ యొక్క భద్రతను తనిఖీ చేయడానికి ఉపయోగించే పరీక్షలు (హ్యాకర్లు, వైరస్లు, రహస్య డేటాకు అనధికారిక యాక్సెస్ మరియు ఇతర సంతోషకరమైన దాడుల నుండి).
• స్థానికీకరణ పరీక్ష - అప్లికేషన్ యొక్క స్థానికీకరణ పరీక్షలు.
• యుజబిలిటీ టెస్టింగ్ — వినియోగం, అర్థమయ్యేలా, ఆకర్షణీయత మరియు నేర్చుకునే సామర్థ్యాన్ని తనిఖీ చేయడం లక్ష్యంగా పరీక్ష.

ఇదంతా బాగానే ఉంది, కానీ ఆచరణలో ఇది ఎలా పని చేస్తుంది? సింపుల్! మేము మైక్ కోన్ యొక్క టెస్టింగ్ పిరమిడ్‌ని ఉపయోగిస్తాము: ఇది పిరమిడ్ యొక్క సరళీకృత వెర్షన్: ఇది ఇప్పుడు చిన్న భాగాలుగా విభజించబడింది. కానీ ఈ రోజు మనం చాలా అధునాతనంగా ఉండము. మేము సరళమైన సంస్కరణను పరిశీలిస్తాము.

1. యూనిట్ — ఈ విభాగం యూనిట్ పరీక్షలను సూచిస్తుంది, ఇది అప్లికేషన్ యొక్క వివిధ లేయర్‌లలో వర్తించబడుతుంది. వారు అప్లికేషన్ లాజిక్ యొక్క చిన్న విభజించదగిన యూనిట్‌ను పరీక్షిస్తారు. ఉదాహరణకు, తరగతులు, కానీ చాలా తరచుగా పద్ధతులు. ఈ పరీక్షలు సాధారణంగా ఏదైనా బాహ్య తర్కం నుండి పరీక్షించబడిన వాటిని వేరు చేయడానికి వీలైనంత ఎక్కువగా ప్రయత్నిస్తాయి. అదేమిటంటే, మిగతా అప్లికేషన్ అనుకున్నట్లుగానే నడుస్తోందన్న భ్రమ కలిగించే ప్రయత్నం చేస్తారు.

   ఈ పరీక్షలు ఎల్లప్పుడూ చాలా ఉండాలి (ఏ ఇతర రకాల కంటే ఎక్కువ), ఎందుకంటే అవి చిన్న ముక్కలను పరీక్షిస్తాయి మరియు చాలా తేలికగా ఉంటాయి, చాలా వనరులను వినియోగించవు (అంటే RAM మరియు సమయం).

2. ఇంటిగ్రేషన్ - ఈ విభాగం ఏకీకరణ పరీక్షను సూచిస్తుంది. ఈ పరీక్ష సిస్టమ్ యొక్క పెద్ద భాగాలను తనిఖీ చేస్తుంది. అంటే, ఇది అనేక లాజిక్ ముక్కలను (అనేక పద్ధతులు లేదా తరగతులు) మిళితం చేస్తుంది లేదా బాహ్య భాగంతో పరస్పర చర్య యొక్క ఖచ్చితత్వాన్ని తనిఖీ చేస్తుంది. ఈ పరీక్షలు సాధారణంగా యూనిట్ పరీక్షల కంటే చిన్నవిగా ఉంటాయి ఎందుకంటే అవి భారీగా ఉంటాయి.

   ఇంటిగ్రేషన్ పరీక్ష యొక్క ఉదాహరణ డేటాబేస్కు కనెక్ట్ చేయడం మరియు దానితో పని చేసే పద్ధతుల యొక్క ఆపరేషన్ యొక్క ఖచ్చితత్వాన్ని తనిఖీ చేయడం.

3. UI — ఈ విభాగం వినియోగదారు ఇంటర్‌ఫేస్ యొక్క ఆపరేషన్‌ను తనిఖీ చేసే పరీక్షలను సూచిస్తుంది. అవి అప్లికేషన్ యొక్క అన్ని స్థాయిలలో లాజిక్‌ను కలిగి ఉంటాయి, అందుకే వాటిని ఎండ్-టు-ఎండ్ పరీక్షలు అని కూడా అంటారు. నియమం ప్రకారం, వాటిలో చాలా తక్కువ ఉన్నాయి, ఎందుకంటే అవి చాలా గజిబిజిగా ఉంటాయి మరియు చాలా అవసరమైన (ఉపయోగించిన) మార్గాలను తనిఖీ చేయాలి.

   పై చిత్రంలో, త్రిభుజం యొక్క వివిధ భాగాలు పరిమాణంలో మారుతున్నట్లు మేము చూస్తాము: నిజ పనిలో వివిధ రకాలైన పరీక్షల సంఖ్యలో దాదాపు అదే నిష్పత్తిలో ఉంటుంది.

   ఈ రోజు మనం అత్యంత సాధారణ పరీక్షలు, యూనిట్ పరీక్షలను నిశితంగా పరిశీలిస్తాము, ఎందుకంటే అన్ని స్వీయ-గౌరవనీయ జావా డెవలపర్‌లు వాటిని ప్రాథమిక స్థాయిలో ఉపయోగించగలగాలి.

యూనిట్ పరీక్షలో కీలక అంశాలు

టెస్ట్ కవరేజ్ (కోడ్ కవరేజ్) అనేది అప్లికేషన్ ఎంత బాగా పరీక్షించబడుతుందనే దాని యొక్క ప్రధాన కొలతలలో ఒకటి. ఇది పరీక్షల ద్వారా కవర్ చేయబడిన కోడ్ శాతం (0-100%). ఆచరణలో, చాలామంది ఈ శాతాన్ని తమ లక్ష్యంగా కొనసాగిస్తున్నారు. ఇది నేను ఏకీభవించను, ఎందుకంటే పరీక్షలు అవసరం లేని చోట వర్తింపజేయడం ప్రారంభిస్తుంది. ఉదాహరణకు, అదనపు లాజిక్ లేకుండా మా సేవలో ప్రామాణిక CRUD (సృష్టించడం/పొందడం/నవీకరించడం/తొలగించడం) కార్యకలాపాలు ఉన్నాయని అనుకుందాం. ఈ పద్ధతులు రిపోజిటరీతో పనిచేసే లేయర్‌కు పనిని అప్పగించే మధ్యవర్తులు. ఈ పరిస్థితిలో, ఇవ్వబడిన పద్ధతి DAO పద్ధతిని పిలుస్తుందో లేదో తప్ప, మేము పరీక్షించడానికి ఏమీ లేదు, కానీ అది ఒక జోక్. పరీక్ష కవరేజీని అంచనా వేయడానికి సాధారణంగా అదనపు సాధనాలు ఉపయోగించబడతాయి: JaCoCo, Cobertura, Clover, Emma, ​​మొదలైనవి. ఈ అంశం గురించి మరింత వివరణాత్మక అధ్యయనం కోసం,

• మీడియంలో కోడ్ కవరేజ్
• బ్లాక్ బాక్స్ టెస్టింగ్: ఉదాహరణలు మరియు సాంకేతికతలతో కూడిన లోతైన ట్యుటోరియల్

TDD అంటే పరీక్ష ఆధారిత అభివృద్ధి. ఈ విధానంలో, ఏదైనా చేసే ముందు, మీరు నిర్దిష్ట కోడ్‌ని తనిఖీ చేసే పరీక్షను వ్రాస్తారు. ఇది బ్లాక్-బాక్స్ పరీక్షగా మారుతుంది: ఇన్‌పుట్ ఏమిటో మాకు తెలుసు మరియు అవుట్‌పుట్ ఎలా ఉండాలో మాకు తెలుసు. ఇది కోడ్ డూప్లికేషన్‌ను నివారించడం సాధ్యపడుతుంది. మీ అప్లికేషన్‌లోని ప్రతి బిట్ ఫంక్షనాలిటీ కోసం పరీక్షల రూపకల్పన మరియు అభివృద్ధి చేయడంతో టెస్ట్ ఆధారిత అభివృద్ధి ప్రారంభమవుతుంది. TDD విధానంలో, మేము ముందుగా కోడ్ ప్రవర్తనను నిర్వచించే మరియు పరీక్షించే పరీక్షను సృష్టిస్తాము. TDD యొక్క ప్రధాన లక్ష్యం మీ కోడ్‌ను మరింత అర్థమయ్యేలా, సరళంగా మరియు లోపం లేకుండా చేయడం. విధానం క్రింది వాటిని కలిగి ఉంటుంది:

• మేము మా పరీక్ష వ్రాస్తాము.
• మేము పరీక్షను అమలు చేస్తాము. మేము ఇంకా అవసరమైన లాజిక్‌ని అమలు చేయనందున ఆశ్చర్యకరంగా, ఇది విఫలమవుతుంది.
• పరీక్ష ఉత్తీర్ణత సాధించడానికి కారణమయ్యే కోడ్‌ను జోడించండి (మేము పరీక్షను మళ్లీ అమలు చేస్తాము).
• మేము కోడ్‌ను రీఫాక్టర్ చేస్తాము.

TDD అనేది యూనిట్ పరీక్షలపై ఆధారపడి ఉంటుంది, ఎందుకంటే అవి టెస్ట్ ఆటోమేషన్ పిరమిడ్‌లో అతి చిన్న బిల్డింగ్ బ్లాక్‌లు. యూనిట్ పరీక్షలతో, మేము ఏ తరగతి యొక్క వ్యాపార లాజిక్‌ను పరీక్షించగలము. BDD అంటే ప్రవర్తన-ఆధారిత అభివృద్ధి. ఈ విధానం TDDపై ఆధారపడి ఉంటుంది. మరింత ప్రత్యేకంగా, ఇది అభివృద్ధిలో పాల్గొన్న ప్రతి ఒక్కరికీ సిస్టమ్ ప్రవర్తనను వివరించే సాదా భాషా ఉదాహరణలను ఉపయోగిస్తుంది. ఇది ప్రధానంగా టెస్టర్లు మరియు వ్యాపార విశ్లేషకులను ప్రభావితం చేస్తుంది కాబట్టి మేము ఈ పదాన్ని లోతుగా పరిశోధించము. టెస్ట్ కేస్ అనేది పరీక్షలో కోడ్‌ను తనిఖీ చేయడానికి అవసరమైన దశలు, నిర్దిష్ట పరిస్థితులు మరియు పారామితులను వివరించే దృశ్యం. టెస్ట్ ఫిక్స్చర్ అనేది పరీక్షలో ఉన్న పద్ధతి విజయవంతంగా అమలు కావడానికి అవసరమైన స్థితిని కలిగి ఉండటానికి పరీక్ష వాతావరణాన్ని సెట్ చేసే కోడ్. ఇది నిర్దిష్ట పరిస్థితులలో వస్తువులు మరియు వాటి ప్రవర్తన యొక్క ముందే నిర్వచించబడిన సెట్.

పరీక్ష దశలు

ఒక పరీక్ష మూడు దశలను కలిగి ఉంటుంది:

• పరీక్ష డేటాను పేర్కొనండి (ఫిక్చర్లు).
• పరీక్షలో కోడ్‌ని అమలు చేయండి (పరీక్షించిన పద్ధతికి కాల్ చేయండి).
• ఫలితాలను ధృవీకరించండి మరియు ఆశించిన ఫలితాలతో సరిపోల్చండి.

పరీక్ష మాడ్యులారిటీని నిర్ధారించడానికి, మీరు అప్లికేషన్ యొక్క ఇతర లేయర్‌ల నుండి వేరుచేయాలి. ఇది స్టబ్స్, మాక్స్ మరియు గూఢచారులను ఉపయోగించి చేయవచ్చు. మాక్స్ అనేది అనుకూలీకరించదగిన వస్తువులు (ఉదాహరణకు, ప్రతి పరీక్షకు అనుగుణంగా). మెథడ్ కాల్‌ల నుండి మనం ఏమి ఆశిస్తున్నామో అవి పేర్కొనడానికి అనుమతిస్తాయి, అంటే ఆశించిన ప్రతిస్పందనలు. మేము ఆశించిన వాటిని పొందామని ధృవీకరించడానికి మేము మాక్ వస్తువులను ఉపయోగిస్తాము. పరీక్ష సమయంలో కాల్‌లకు స్టబ్‌లు హార్డ్-కోడెడ్ ప్రతిస్పందనను అందిస్తాయి. వారు కాల్ గురించి సమాచారాన్ని కూడా నిల్వ చేయవచ్చు (ఉదాహరణకు, పారామితులు లేదా కాల్‌ల సంఖ్య). వీటిని కొన్నిసార్లు గూఢచారులుగా సూచిస్తారు. కొన్నిసార్లు వ్యక్తులు స్టబ్ మరియు మాక్ అనే పదాలను గందరగోళానికి గురిచేస్తారు: తేడా ఏమిటంటే, స్టబ్ దేనినీ తనిఖీ చేయదు - ఇది ఇచ్చిన స్థితిని మాత్రమే అనుకరిస్తుంది. మాక్ అనేది అంచనాలను కలిగి ఉన్న వస్తువు. ఉదాహరణకు, ఇచ్చిన పద్ధతిని నిర్దిష్ట సంఖ్యలో సార్లు పిలవాలి. వేరే పదాల్లో,

పరీక్ష పరిసరాలు

కాబట్టి, ఇప్పుడు పాయింట్. జావా కోసం అనేక పరీక్షా వాతావరణాలు (ఫ్రేమ్‌వర్క్‌లు) అందుబాటులో ఉన్నాయి. వీటిలో జూనిట్ మరియు టెస్ట్‌ఎన్‌జి అత్యంత ప్రసిద్ధమైనవి. ఇక్కడ మా సమీక్ష కోసం, మేము ఉపయోగిస్తాము: JUnit పరీక్ష అనేది పరీక్ష కోసం మాత్రమే ఉపయోగించే తరగతిలోని ఒక పద్ధతి. తరగతికి సాధారణంగా అది పరీక్షించిన తరగతికి అదే పేరు పెట్టబడుతుంది, చివరకి "పరీక్ష" జోడించబడుతుంది. ఉదాహరణకు, CarService -> CarServiceTest. మావెన్ బిల్డ్ సిస్టమ్ స్వయంచాలకంగా పరీక్ష పరిధిలో అటువంటి తరగతులను కలిగి ఉంటుంది. వాస్తవానికి, ఈ తరగతిని పరీక్ష తరగతి అంటారు. ప్రాథమిక ఉల్లేఖనాలను క్లుప్తంగా చూద్దాం:

• @పరీక్ష పద్ధతి ఒక పరీక్ష అని సూచిస్తుంది (ప్రాథమికంగా, ఈ ఉల్లేఖనతో గుర్తించబడిన పద్ధతి ఒక యూనిట్ పరీక్ష).
• @ముందు ప్రతి పరీక్షకు ముందు అమలు చేయబడే పద్ధతిని సూచిస్తుంది. ఉదాహరణకు, పరీక్ష డేటాతో తరగతిని నింపడానికి, ఇన్‌పుట్ డేటాను చదవడం మొదలైనవి.
• @After అనేది ప్రతి పరీక్ష తర్వాత పిలవబడే పద్ధతిని గుర్తించడానికి ఉపయోగించబడుతుంది (ఉదా. డేటాను తీసివేయడానికి లేదా డిఫాల్ట్ విలువలను పునరుద్ధరించడానికి).
• @Beforeక్లాస్ అనేది ఒక పద్ధతి పైన ఉంచబడింది, ఇది @Beforeకి సారూప్యంగా ఉంటుంది. కానీ అటువంటి పద్ధతిని ఇచ్చిన తరగతికి సంబంధించిన అన్ని పరీక్షలకు ముందు ఒకసారి మాత్రమే పిలుస్తారు మరియు అందువల్ల స్థిరంగా ఉండాలి. పరీక్ష డేటాబేస్‌ను స్పిన్నింగ్ చేయడం వంటి మరిన్ని వనరుల-ఇంటెన్సివ్ ఆపరేషన్‌లను నిర్వహించడానికి ఇది ఉపయోగించబడుతుంది.
• @AfterClass అనేది @BeforeClassకి వ్యతిరేకం: ఇది ఇచ్చిన తరగతికి ఒకసారి అమలు చేయబడుతుంది, కానీ అన్ని పరీక్షల తర్వాత మాత్రమే. ఉదాహరణకు, నిరంతర వనరులను క్లియర్ చేయడానికి లేదా డేటాబేస్ నుండి డిస్‌కనెక్ట్ చేయడానికి ఇది ఉపయోగించబడుతుంది.
• @ఇగ్నోర్ అంటే ఒక పద్ధతి నిలిపివేయబడిందని మరియు మొత్తం టెస్ట్ రన్ సమయంలో విస్మరించబడుతుందని సూచిస్తుంది. ఇది వివిధ పరిస్థితులలో ఉపయోగించబడుతుంది, ఉదాహరణకు, బేస్ పద్ధతి మార్చబడితే మరియు మార్పులకు అనుగుణంగా పరీక్ష ఇంకా తిరిగి పని చేయకపోతే. అటువంటి సందర్భాలలో, వివరణను జోడించడం కూడా అవసరం, అంటే @విస్మరించు("కొంత వివరణ").
• ప్రతికూల పరీక్షల కోసం @Test(అంచనా = Exception.class) ఉపయోగించబడుతుంది. లోపం సంభవించినప్పుడు పద్ధతి ఎలా ప్రవర్తిస్తుందో ధృవీకరించే పరీక్షలు ఇవి, అంటే, పరీక్ష పద్ధతి ఒక రకమైన మినహాయింపును విసిరివేస్తుందని ఆశిస్తుంది. అటువంటి పద్ధతి @Test ఉల్లేఖనం ద్వారా సూచించబడుతుంది, కానీ ఏ లోపాన్ని పట్టుకోవాలో సూచనతో సూచించబడుతుంది.
• @పరీక్ష(సమయం = 100) పద్ధతి 100 మిల్లీసెకన్ల కంటే ఎక్కువ సమయంలో అమలు చేయబడిందో లేదో తనిఖీ చేస్తుంది.
• మాక్ ఆబ్జెక్ట్‌ను కేటాయించడానికి ఫీల్డ్ పైన @Mock ఉపయోగించబడుతుంది (ఇది JUnit ఉల్లేఖనం కాదు, బదులుగా Mockito నుండి వచ్చింది). అవసరమైన విధంగా, మేము పరీక్ష పద్ధతిలో నేరుగా నిర్దిష్ట పరిస్థితి కోసం మాక్ యొక్క ప్రవర్తనను సెట్ చేస్తాము.
• @RunWith(MockitoJUnitRunner.class) తరగతి పైన ఉంచబడింది. ఈ ఉల్లేఖనం జూనిట్‌కి తరగతిలో పరీక్షలను ప్రారంభించమని చెబుతుంది. మోకిటోజూనిట్‌రన్నర్, జూనిట్‌ప్లాట్‌ఫారమ్ మరియు స్ప్రింగ్‌రన్నర్‌తో సహా వివిధ రన్నర్లు ఉన్నారు. జూన్ 5లో, @RunWith ఉల్లేఖనాన్ని మరింత శక్తివంతమైన @ExtendWith ఉల్లేఖనంతో భర్తీ చేశారు.

ఫలితాలను పోల్చడానికి ఉపయోగించే కొన్ని పద్ధతులను పరిశీలిద్దాం:

• assertEquals(ఆబ్జెక్ట్ అంచనాలు, ఆబ్జెక్ట్ వాస్తవాలు) — పాస్ చేసిన వస్తువులు సమానంగా ఉన్నాయో లేదో తనిఖీ చేస్తుంది.
• assertTrue(బూలియన్ ఫ్లాగ్) — పాస్ చేసిన విలువ నిజమో కాదో తనిఖీ చేస్తుంది.
• assertFalse(బూలియన్ ఫ్లాగ్) — పాస్ చేసిన విలువ తప్పు కాదా అని తనిఖీ చేస్తుంది.
• assertNull(ఆబ్జెక్ట్ ఆబ్జెక్ట్) — పాస్ చేసిన వస్తువు శూన్యంగా ఉందో లేదో తనిఖీ చేస్తుంది.
• assertSame (ఆబ్జెక్ట్ ఫస్ట్ ఆబ్జెక్ట్, ఆబ్జెక్ట్ సెకండ్ ఆబ్జెక్ట్) — పాస్ చేసిన విలువలు ఒకే వస్తువును సూచిస్తాయో లేదో తనిఖీ చేస్తుంది.
• అది (T t, మ్యాచర్ సరిపోలిక) — మ్యాచర్‌లో పేర్కొన్న షరతును 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 — ఫలితం యొక్క ID మరియు ఇచ్చిన పద్ధతి వాదనలను సరిపోల్చండి. లైన్ 15 — పేరు నవీకరించబడిందో లేదో తనిఖీ చేయండి. లైన్ 16 — CPU ఫలితాన్ని చూడండి. లైన్ 17 — మేము ఈ ఫీల్డ్‌ను ఉదాహరణలో పేర్కొనలేదు, కనుక ఇది అలాగే ఉండాలి. మేము ఆ పరిస్థితిని ఇక్కడ తనిఖీ చేస్తాము. దీన్ని అమలు చేద్దాం:పరీక్ష పచ్చగా ఉంది! మేము ఉపశమనం పొందగలము :) సారాంశంలో, పరీక్ష కోడ్ యొక్క నాణ్యతను మెరుగుపరుస్తుంది మరియు అభివృద్ధి ప్రక్రియను మరింత సరళంగా మరియు నమ్మదగినదిగా చేస్తుంది. వందలాది క్లాస్ ఫైల్‌లతో కూడిన సాఫ్ట్‌వేర్‌ను రీడిజైన్ చేయడానికి ఎంత శ్రమ పడుతుందో ఊహించండి. మేము ఈ తరగతులన్నింటికీ యూనిట్ పరీక్షలు వ్రాసినప్పుడు, మేము విశ్వాసంతో రీఫాక్టర్ చేయవచ్చు. మరియు ముఖ్యంగా, ఇది అభివృద్ధి సమయంలో దోషాలను సులభంగా కనుగొనడంలో మాకు సహాయపడుతుంది. గైస్ అండ్ గాల్స్, ఈ రోజు నాకు దొరికింది అంతే. నాకు ఒక లైక్ ఇవ్వండి మరియు వ్యాఖ్యానించండి :)