რჩევები და საუკეთესო პრაქტიკა Salesforce ინტეგრაციის ტესტირებისთვის

salesforce ინტეგრაცია

Salesforce ტესტირება დაგეხმარებათ თქვენი პერსონალურად დამოწმებაში Salesforce ინტეგრაციები და ფუნქციონალური ფუნქციები სხვა საწარმოს პროგრამებთან. კარგი ტესტი მოიცავს Salesforce- ის ყველა მოდულს, ანგარიშებიდან ხელმძღვანელობამდე, შესაძლებლობებიდან ანგარიშებამდე და კამპანიებიდან კონტაქტებამდე. როგორც ყველა ტესტის შემთხვევაში, არსებობს Salesforce ტესტის გაკეთების კარგი (ეფექტური და ეფექტური) გზა და ცუდი გზა. რა არის Salesforce ტესტირების კარგი პრაქტიკა?

  • გამოიყენეთ ტესტირების უფლება ინსტრუმენტები - Salesforce ტესტირება ხდება ბრაუზერში ან დაბნელებაზე დაფუძნებულ გარემოში. უახლეს ბრაუზერებსა და დაბნელებას აქვს გამართვის დიდი საშუალებები და შეგიძლიათ დააკავშიროთ ისინი სატესტო კლასებთან ძალიან სასარგებლო შედეგებისთვის. ამასთან, თუ მეტი გჭირდებათ, გამოყენებული უნდა იყოს Force.com– ის Apex Interactive Debugger (ან უბრალოდ Apex). გაითვალისწინეთ, რომ თქვენ ასევე შეგიძლიათ გამოიყენოთ Salesforce Lightning Inspector, ქრომირებული გაფართოება, რომ Salesforce Lightning სპეციალურად შეამოწმოთ. Apex არის ა Force.com პლატფორმის საკუთარი პროგრამირების ენა, რომელიც ძალიან ჰგავს Java- ს. ეს არის ობიექტზე ორიენტირებული, მცირეზე მგრძნობიარე, მკაცრად ტიპის პროგრამირების ენა, რომელიც მიჰყვება ფრჩხილების ფრჩხილებს და წერტილოვანი სინტაქსს. თქვენ შეგიძლიათ გამოიყენოთ Apex პროგრამირებული ფუნქციების შესასრულებლად Force.com– ის უმეტეს პროცესში, მათ შორის, მორგებული ბმულები და ღილაკები, განახლებები, წაშლა და ჩანაწერების ჩასმის ღონისძიების დამმუშავებლები Visualforce გვერდის მორგებული კონტროლერების ან დაგეგმვის საშუალებით.
  • გამოიყენეთ სათანადო დასახელების კონვენციები - ტესტების წერის დაწყებამდე თქვენი ტესტის მეთოდების სწორად დასახელება ძალიან მნიშვნელოვანია. ტესტის მეთოდის სახელს უნდა ჰქონდეს სამი ნაწილი. ეს არის nameOfMethod (ინდივიდუალური მეთოდის სახელი, რომელსაც ატესტებთ, როგორიცაა ჩასმა / განახლება / წაშლა / წაშლა ტრიგერის შემოწმების დროს, ინფორმაცია TestPath– ის შესახებ, რომელიც არის მოქნილი, მაგალითად, null კონტაქტი, თუ თქვენ ამოწმებთ, რომ კონტაქტი ბათილია, და მოქმედებს ტესტირებისას პოზიტიური / უარყოფითი გზა.
  • 100% დაფარვის უზრუნველყოფა - მიუხედავად იმისა, რომ Salesforce– ის სტანდარტული დირექტივაა, რომ ერთეულის ტესტს უნდა ჰქონდეს თქვენი კოდის 75% (მინუს ტესტის კლასები, ზარები System.debug– ზე და ტესტის მეთოდები) და თქვენ ვერ შეძლებთ Apex კოდის ან პაკეტის AppExchange პროგრამების განთავსებას, თქვენ უნდა გაითვალისწინეთ, რომ ეს მხოლოდ სტანდარტია და თქვენი მიზანი უნდა იყოს 100% გაშუქება. შეამოწმეთ ყველა დადებითი / უარყოფითი შემთხვევა და არსებული მონაცემები, რომლებიც არ არსებობს. სხვა მნიშვნელოვანი რჩევები, როდესაც საქმე ეხება კოდის გაშუქებას, არის:
    • კოდის დაფარვის ნომრების განახლებისთვის უნდა ჩაატაროთ ტესტები, რადგან Apex კოდის განახლებისას ეს რიცხვები არ განახლდება, სანამ ტესტები არ გამეორდება.
    • თუ ორგანიზაციაში განახლება მოხდა ბოლო ტესტის შემდეგ, არსებობს საფრთხე, რომ კოდი დაფარვის ნომრები არასწორია. გაიარეთ ტესტები სწორი შეფასებისთვის.
    • კოდების დაფარვის პროცენტული მაჩვენებელი არ შეიცავს კოდექსის დაფარვას მართული პაკეტების ტესტებიდან, ერთადერთი გამონაკლისია, როდესაც ეს ტესტები იწვევს ტრიგერების ხანძარს.
    • გაშუქება დამოკიდებულია კოდების ხაზების საერთო რაოდენობაზე. თუ კოდის ხაზებს დაამატებთ ან წაშლით, ეს გავლენას მოახდენს პროცენტულ მაჩვენებელზე.
  • ტესტის შემთხვევები კლასებში და კონტროლერებში - Salesforce– ის განვითარების დროს, დეველოპერების უმეტესობა ქმნის ცალკეულ კლასებსა და კონტროლერის ფაილებს თითოეული ფუნქციისთვის. ეს კეთდება იმისთვის, რომ კოდირება იყოს უფრო ორგანიზებული, მარტივი, მრავალჯერადი და პორტატული. ამასთან, უნდა გაითვალისწინოთ, რომ ეს უფრო ადვილია, მაგრამ უფრო ეფექტური არ არის. პორტაბელურობას მიაღწევთ, თუ ტესტის კოდი თავდაპირველ კლასშია და კონტროლერის კოდში, რადგან საცდელი ყუთიდან წარმოებაში გადასვლისას არ გამოტოვებთ არცერთ სატესტო კლასს.
  • გამოიყენეთ System.assert () - Apex- ში, სისტემა.ამტკიცეთ() გამოიყენება პირობების შესამოწმებლად. ეს მნიშვნელოვანი ფუნქციონალია, რადგან ის საშუალებას გაძლევთ განსაზღვროთ, შესრულებულია თუ არა კონკრეტული ფუნქცია მეთოდით, როგორც მოსალოდნელი იყო. თქვენ უნდა გამოიყენოთ System.assertEquals () და System.assertNotEquals () კრიტიკულ ფუნქციებს შორის არა მხოლოდ დაგეხმარებათ იმის დადგენაში არის თუ არა კოდი შესრულებული ისე, როგორც საჭიროა, არამედ იმის უზრუნველყოფაც, რომ არასწორად არის დაწერილი მონაცემები, თუ კოდი არასწორად მიდის.
  • ყოვლისმომცველი ტესტი - ტესტირება ყველაფერს უნდა ფარავდეს. თქვენ უნდა გააკეთოთ ფუნქციური ტესტირება, დატვირთვის ტესტირება, უსაფრთხოების ტესტირება და განლაგების ტესტირება.
  • ერთეულის ტესტები - უნდა გქონდეთ ერთეულის ტესტები იმის დასადასტურებლად, რომ ინდივიდუალური ჩანაწერები იძლევა სწორ და მოსალოდნელ შედეგს. მიუხედავად იმისა, რომ გიგანტური ტესტის გამოყენება, რომელიც მოიცავს მთელ კოდს, შეიძლება კარგი იდეა ჩანდეს, გაითვალისწინეთ, რომ გამომუშავებული შედეგების გამოსწორება გაცილებით რთულია და წარუმატებლობის გაგება უფრო ძნელი იქნება. ერთეულის ტესტი უნდა მოიცავდეს ტესტირებადი ფუნქციონირების მცირე ქვეჯგუფს.
  • საცდელი მასალები - კარგი ტესტის კოდი (ტრიგერი, გამონაკლისი ან კლასი) შეიძლება ჩართულ იქნას რამდენიმე ასეული ჩანაწერისთვის (200 Apex- ისთვის). თქვენ უნდა ისარგებლოთ ამით და შეამოწმოთ არა მხოლოდ ინდივიდუალური ჩანაწერები, არამედ ნაყარი შემთხვევები.
  • პოზიტიური ტესტები - შეამოწმეთ, რომ მოსალოდნელი ქცევა მოხდა თუ არა ყველა მოსალოდნელი ჩანაცვლების საშუალებით. ტესტმა უნდა დაადასტუროს, რომ მომხმარებელმა სწორად შეავსო ფორმა და რომ მან არ გადალახა ლიმიტები.
  • ნეგატიური ტესტები - შეამოწმეთ უარყოფითი შემთხვევები, რათა დარწმუნდეთ, რომ შეცდომის შეტყობინებები სწორად არის წარმოებული. ამგვარი უარყოფითი შემთხვევების მაგალითებს არ აქვთ უარყოფითი თანხების დაზუსტება და მომავალი თარიღების დამატება. ნეგატიური ტესტები მნიშვნელოვანია, რადგან სწორად მოპყრობამ, როდესაც საქმე სამხრეთით მიდის, ყველანაირი ცვლილება შეიტანოს.
  • ავტომატიზირება ტესტირება - ტრადიციულად, Salesforce ტესტირება სახელმძღვანელო იყო. თქვენ უნდა გაითვალისწინოთ ავტომატიზირებული ტესტირება, რადგან ეს უფრო მეტ უპირატესობას გვთავაზობს. Ესენი მოიცავს:
    • სახელმძღვანელო ტესტირება შეცდომებისადმი მგრძნობიარობას გიქმნით, რადგან ტესტირება ხდება ადამიანის და არა რობოტის მიერ. რობოტები გამოირჩევიან განმეორებითი აქტივობებით, ხოლო ადამიანები შეცდომებს უშლიან მოწყენილობის, კონცენტრაციის და თანმიმდევრულობის შემცირებისა და კუთხეების მოჭრის ტენდენციის გამო.
    • სახელმძღვანელო ტესტირება განმეორებითი, ფორმულური და მოსაბეზრებელია. ტესტირების ჯგუფს სჯობს, უფრო მეტი საძიებო სამუშაო ჩაატაროს.
  • შეასრულეთ თითოეული Code Logic Branch - პირობითი ლოგიკის გამოყენებისას (როდესაც თქვენ მოათავსეთ ტერნარული ოპერატორები), კოდის ლოგიკის თითოეული ტოტი უნდა შესრულდეს.
  • გამოიყენეთ არასწორი და სწორი შეყვანის მეთოდები ზარებისათვის - მეთოდებისკენ დარეკვა უნდა განხორციელდეს როგორც არასწორი, ასევე მოქმედი შეტანის გამოყენებით.
  • სრული ტესტები - დარწმუნდით, რომ ტესტები წარმატებით დასრულდა - მათ არ უნდა გამოიყენონ გამონაკლისები, თუ შეცდომები არ არის მოსალოდნელი. გაუმკლავდეთ ყველა გამონაკლისს - დაჭერა არ არის საკმარისი.
  • გამოიყენეთ ORDER BY საკვანძო სიტყვებით - იმის უზრუნველსაყოფად, რომ თქვენი ჩანაწერები დააბრუნეთ თქვენი მოლოდინის მიხედვით, გამოიყენეთ ORDER BY საკვანძო სიტყვები.
  • არ ჩათვალოთ, რომ ჩანაწერების პირადობის მოწესრიგება ხდება თანმიმდევრულად - თავიდან ავიცილოთ საერთო შეცდომა, ვინაიდან ჩანაწერის პირადობის მოწმობები თანმიმდევრული თანმიმდევრობით არის განლაგებული. პირადობის მოწმობები არ არის ზრდადი თანმიმდევრობით, თუ თქვენ არ ჩასვით მრავალი ჩანაწერი ერთი და იგივე მოთხოვნით.
  • დარეკეთ Test.startTest () და Test.stopTest () - როდესაც თქვენ აწარმოებთ Apex– ის ტესტს, მიიღებთ 75% –ზე მეტ კოდის დაფარვას, რომელიც სავალდებულოა Salesforce– ში. მტკიცებებამდე უნდა დარეკოთ stopTest- ს, რათა აიძულოთ ასინქრონული კოდები, რომელთა დასრულებაც შესაძლოა ჯერ კიდევ მიმდინარეობს. გაუშვით ახალი მოთხოვნები საბოლოო შედეგების მისაღებად, ვინაიდან სხვა კოდმა შეიძლება შეცვალოს მონაცემები. UsingTest.startTest () და Test.stopTest () საშუალებას გაძლევთ მოაწყოთ ტესტი მის გამტარ ლიმიტებში. ამ გზით, თქვენს მიერ გამოყენებული დაყენების კოდი ხელს არ შეგიშლით და მოგცემთ ცრუ ნეგატივებს ან დადებით მხარეებს გამგებლის ლიმიტების გარშემო. Test.stopTest () ასევე უზრუნველყოფს @future ზარების დასრულებას ტესტირებისთვის.
  • იკითხება - ერთეულის ტესტებში კითხვა ძალიან მნიშვნელოვანია. ტესტის სახელები უნდა შეიცავდეს სპეციფიკურ მოქმედებას და მოსალოდნელ შედეგს. მეთოდი უნდა იყოს აღწერითი და მოკლე. მეთოდი ისეთი უნდა იყოს, რომ მრავალჯერადი გამოყენება იყოს შესაძლებელი სხვადასხვა ტესტის განმავლობაში.
  • შექმენით დიდი საცდელი მონაცემების ნაკრები startTest– მდე - ვინაიდან თქვენი ტესტები გადის სხვადასხვა სავარჯიშო და საწარმოო გარემოში, startTest- ის გამოძახებამდე ააშენეთ საცდელი მონაცემების დიდი ნაკრები, რათა დარწმუნდეთ, რომ ტესტს შესრულების სრული ლიმიტები აქვს. სტანდარტულად, Salesforce Github აწარმოებს წარმოების მონაცემებისგან იზოლირებულ ტესტებს. როდესაც გჭირდებათ სისტემის მონაცემები, როგორიცაა პროფილი, მოითხოვეთ კონკრეტული გარემოს შესაქმნელად.
  • შექმენით საკუთარი ტესტის მონაცემები - თქვენს მიერ გამოყენებული ტესტის მონაცემები უნდა იყოს გენერირებული ტესტში. ამ მონაცემების გენერირება შეგიძლიათ @testSetup ანოტაციისა და TestUtils კლასის გამოყენებით, რომ არა მხოლოდ უზრუნველყოთ რომ გაქვთ სწორი მონაცემები, არამედ ასევე უზრუნველყოთ, რომ ყველა ტესტი ტარდება დეველოპერული სავარჯიშო სისტემაზე, მონაცემთა მოთხოვნა არ არის.
  • მოერიდეთ AKA– ს ნულოვან ოპერაციებს - მრავალი ტესტერი იყენებს no-op AKA– ს ნულოვან ოპერაციებს. ეს არის უსარგებლო კოდები, რომლებიც არაფერს აკეთებს. რადგან ისინი უკვე არიან თქვენს კოდის ბაზაში, ისინი დაემატება თქვენი დაფარვის პროცენტს.
  • პარალელური ტესტის შესრულება - როდესაც იწყებთ ტესტებს Salesforce მომხმარებლის ინტერფეისიდან ან შემქმნელის კონსოლიდან, ტესტები პარალელურად იმუშავებს. ეს მნიშვნელოვანი მახასიათებელია, რადგან აჩქარებს ტესტის ხანგრძლივობას. ამასთან, უნდა გაითვალისწინოთ, რომ ამან შეიძლება გამოიწვიოს მონაცემთა სადავო საკითხები და თუ ეჭვი გაქვთ, რომ ეს შეიძლება მოხდეს, გამორთეთ პარალელური შესრულება. მონაცემთა სადავო საკითხების ყველაზე გავრცელებული მიზეზები, რომლებიც ხშირად იწვევს UNABLE_TO_LOCK_ROW შეცდომებს, არის:
    • როდესაც ტესტები ერთსა და იმავე ჩანაწერების განახლებას გულისხმობს. იგივე ჩანაწერების განახლება, ჩვეულებრივ, ხდება მაშინ, როდესაც ტესტები არ ქმნიან საკუთარ მონაცემებს.
    • როდესაც პარალელურად მიმდინარე ტესტებში ჩიხია და ისინი ცდილობენ შექმნან ჩანაწერები, რომლებსაც აქვთ ინდექსის ველის შესაბამისი მნიშვნელობები. ჩიხი მოხდება, როდესაც 2 გაშვებულ ტესტს დაემატება მონაცემების დასაბრუნებლად (ეს ხდება მაშინ, როდესაც 2 ტესტის შეყვანის ჩანაწერს აქვს სხვადასხვა უნიკალური ინდექსის ველის იგივე მნიშვნელობები).
    • პარალელური ტესტის შესრულების გამორთვისთვის გადადით Setup- ში, შეიყვანეთ Apex Test, გადადით Apex Test Execution Options დიალოგზე, აირჩიეთ Paralelel Apex Testing გამორთვა, დააჭირეთ OK.

გამორთეთ მწვერვალის პარალელური ტესტირება

დაიქირავეთ პროფესიონალი სამუშაოსთვის, რადგან მას ექნება გამოცდილება და ტრენინგი, რომელიც აუცილებელია კარგი ტესტის ჩასატარებლად, რაც ასევე სიმშვიდეს მოგანიჭებთ. პროფესიონალის დაქირავება საშუალებას გაძლევთ კონცენტრირება მოახდინოთ თქვენს მთავარ ბიზნესზე. ეს ასევე ზოგავს ფულს, რადგან სამუშაოსთვის შიდა გუნდი არ დაგჭირდებათ.

ეს საიტი იყენებს Akismet- ს, რათა შეამციროს სპამი. შეისწავლეთ თქვენი კომენტარის მონაცემები დამუშავებული.