Съвети и най-добри практики за тестване на интеграции на Salesforce

интеграция на Salesforce

Тестването на Salesforce ще ви помогне да потвърдите вашите персонализирани Интеграции на Salesforce и функционалности с други корпоративни приложения. Добър тест обхваща всички модули на Salesforce от акаунти до потенциални клиенти, от възможности до отчети и от кампании до контакти. Както е при всички тестове, има добър (ефективен и ефикасен) начин за извършване на тест на Salesforce и лош начин. И така, какво представлява Salesforce за тестване на добри практики?

  • Използвайте правилните инструменти за тестване - Тестването на Salesforce се извършва в браузъра или в среда, базирана на затъмнение. Както най-новите браузъри, така и eclipse имат чудесни инструменти за отстраняване на грешки и можете да ги комбинирате с тестови класове за много полезни резултати. Ако обаче имате нужда от повече, трябва да се използва интерактивният дебъгер Apex (или просто Apex) от Force.com. Имайте предвид, че можете също да използвате Salesforce Lightning Inspector, хромирано разширение, за да тествате специално Salesforce Lightning. Apex е a Force.com патентован език за програмиране на платформа, който има големи прилики с Java. Това е обектно-ориентиран, нечувствителен към регистъра, силно типизиран език за програмиране, който следва синтаксис на къдрави скоби и точки. Можете да използвате Apex за изпълнение на програмирани функции по време на повечето процеси на Force.com, включително персонализирани връзки и бутони, актуализации, изтривания и обработчици на събития за вмъкване на записи чрез потребителски контролери на страницата на Visualforce или планиране.
  • Използвайте правилните конвенции за именуване - Правилното именуване на вашите методи за тестване, преди да започнете да пишете тестове, е много важно. Името на метода за изпитване трябва да има три части. Това са nameOfMethod (име на отделния метод, който тествате, като insert / update / delete / undelete при тестване на задействане, информация за TestPath, която е гъвкава, като нулев контакт, ако тествате, че контактът е нулев и валиден при тестване положителен / отрицателен път.
  • Осигурете 100% покритие - Въпреки че стандартната директива на Salesforce е, че модулният тест трябва да покрива 75% от вашия код (минус тестови класове, извиквания на System.debug и тестови методи) и няма да можете да внедрите Apex код или да пакетирате приложения AppExchange, трябва имайте предвид, че това е просто стандарт и вашата цел трябва да бъде 100% покритие. Тествайте всички положителни / отрицателни случаи и за данни, които присъстват и не присъстват. Други важни съвети по отношение на покритието на кода са:
    • Трябва да стартирате тестове, за да обновите номерата за покритие на кода, тъй като тези номера не се обновяват, когато кодът на Apex се актуализира, докато тестовете не бъдат повторени.
    • Ако има актуализация в организацията от последното тестово изпълнение, съществува риск номерата за покритие на кода да бъдат неправилни. Повторете тестовете за правилната оценка.
    • Процентът на покритие на кода не включва покритие на код от тестове на управлявани пакети, с единственото изключение, когато тези тестове карат тригерите да се задействат.
    • Покритието зависи от общия брой кодови редове. Ако добавите или изтриете редове код, ще повлияете на процента.
  • Тестови случаи в класове и контролери - В разработката на Salesforce повечето разработчици създават отделни класове и файлове на контролери за всяка функция. Това се прави, за да направи кодирането по-организирано, по-лесно, многократно и преносимо. Трябва обаче да отбележите, че макар това да е по-лесно, то не е по-ефективно. Ще постигнете преносимост, ако тестовият код е в оригиналния клас и самия код на контролера, тъй като няма да пропуснете нито един тестов клас при мигриране от пясъчник към производствен.
  • Използвайте System.assert () - В Apex, System.assert() се използва за проверка на условията. Това е важна функционалност, тъй като ви позволява да определите дали определена функция е изпълнена по метода, както се очаква. Трябва да използвате System.assertEquals () и System.assertNotEquals () между критичните функционалности не само ви помага да определите дали кодът е изпълнен както трябва, но и да гарантирате, че данните не се записват погрешно, ако кодът се обърка.
  • Изчерпателен тест - Тестването трябва да обхваща всичко. Трябва да направите функционално тестване, тестване на натоварване, тестване на сигурността и тестване за внедряване.
  • Единични тестове - Трябва да имате единични тестове, за да проверите дали отделните записи дават правилния и очакван резултат. Въпреки че използването на гигантски тест, който обхваща целия код, може да изглежда като добра идея, имайте предвид, че генерираните резултати ще бъдат по-трудни за отстраняване на грешки, а отказът ще бъде по-труден за разбиране. Единичният тест трябва да обхваща малка част от функционалността, която се тества.
  • Тестови случаи в насипно състояние - Добър тестов код (тригер, изключение или клас) може да бъде включен за до няколкостотин записа (200 за Apex). Трябва да се възползвате от това и да тествате не само отделни записи, но и групови случаи.
  • Положителни тестове - Тествайте, за да се уверите дали очакваното поведение се появява през всички очаквани пермутации. Тестът трябва да провери дали потребителят е попълнил правилно формуляра и дали не е преминал ограниченията.
  • Отрицателни тестове - Тествайте отрицателните случаи, за да сте сигурни, че съобщенията за грешки се изготвят правилно. Примери за такива отрицателни случаи са неспособността да се посочат отрицателни суми и неспособността да се добавят бъдещи дати. Отрицателните тестове са важни, защото правилното боравене, когато нещата тръгнат на юг, може да промени всичко.
  • Автоматизирайте тестване - Традиционно тестването на Salesforce беше ръчно. Трябва да помислите за автоматизирано тестване, тъй като това предлага повече предимства. Те включват:
    • Ръчното тестване ви прави податливи на грешки, тъй като тестването се извършва от хора, а не от роботи. Роботите се отличават с повтарящи се дейности, докато хората правят грешки поради скуката, намалената концентрация и последователност и склонността да намаляват ъглите.
    • Ръчното тестване е повтарящо се, формулиращо и уморително. Екипът за тестване е по-добре да върши работа, която е по-изследователска.
  • Изпълнете всеки клон на логиката на кода - Когато използвате условна логика (когато сте включили троични оператори), всеки клон на кодовата логика трябва да бъде изпълнен.
  • Използвайте невалидни и валидни входове за повиквания към методи - Извикванията към методите трябва да се извършват, като се използват както невалидни, така и валидни входове.
  • Пълни тестове - Уверете се, че тестовете завършват успешно - те не трябва да правят изключения, освен ако не се очакват грешки. Обработвайте всички уловени изключения - уловът им не е достатъчно добър.
  • Използвайте ПОРЪЧКА ПО ключови думи - За да сте сигурни, че записите ви се връщат в реда, в който ги очаквате, използвайте ключовите думи ПОРЪЧАЙТЕ ПО.
  • Не приемайте, че идентификаторите на записите са подредени последователно - Избягвайте често срещаната грешка, като приемете, че идентификаторите на записите са подредени в последователен ред. Идентификаторите не са във възходящ ред, освен ако не сте вмъкнали множество записи с една и съща заявка.
  • Обадете се на Test.startTest () и Test.stopTest () - Когато изпълните Apex unit test, ще получите повече от 75% покритие на кода, което е задължително в Salesforce. Трябва да извикате stopTest преди твърдения, за да принудите асинхронни кодове, които все още се изпълняват, за да завършат. Изпълнете нови заявки за крайни резултати, тъй като другият код може да промени данните. Използването на Test.startTest () и Test.stopTest () гарантира, че тестовата среда е тестова в рамките на ограниченията на нейния регулатор. По този начин кодът за настройка, който използвате, няма да се намесва и да ви дава фалшиви отрицателни или положителни резултати около ограниченията на гуверньора. Test.stopTest () също гарантира, че повикванията @future ще завършат за тестване.
  • Четливост - Четливостта е много важна при модулните тестове. Имената на теста трябва да включват конкретното действие, което трябва да се предприеме, и очаквания резултат. Методът трябва да бъде описателен и кратък. Методът трябва да бъде такъв, че да може да се използва повторно при различни тестове.
  • Изградете големи набори от тестови данни преди startTest - Тъй като тестовете ви ще се изпълняват в различни пясъчници и производствени среди, изградете големи набори от тестови данни, преди да извикате startTest, за да сте сигурни, че тестът има пълни граници на изпълнение. По подразбиране, Salesforce Github изпълнява тестове, изолирани от производствени данни. Когато имате нужда от системни данни като Профил, направете заявка, за да получите правилното нещо за тази конкретна среда.
  • Генерирайте свои собствени тестови данни - Данните от теста, които използвате, трябва да бъдат генерирани в теста. Можете да генерирате тези данни, като използвате анотация @testSetup и клас TestUtils, за да не само се уверите, че разполагате с правилните данни, но и да гарантирате, че всички тестове се изпълняват в пясъчник за разработчици без изискване за данни.
  • Избягвайте нулеви операции AKA без нула - Много тестери използват нулеви операции AKA, нулеви. Това са безполезни кодове, които не правят нищо. Тъй като те вече са във вашата кодова база, те ще добавят към процента на покритие.
  • Изпълнение на паралелен тест - Когато стартирате тестове от потребителския интерфейс на Salesforce или Developer Console, тестовете ще работят паралелно. Това е важна характеристика, тъй като ускорява времето за тестване. Трябва обаче да имате предвид, че това може да доведе до проблеми със състезанието на данни и ако подозирате, че това може да се случи, изключете паралелното изпълнение. Най-честите причини за проблеми с оспорването на данни, които често водят до UNABLE_TO_LOCK_ROW грешки, са:
    • Когато тестовете имат за цел да актуализират едни и същи записи едновременно. Актуализиране на същите записи обикновено се случва, когато тестовете не създават свои собствени данни.
    • Когато има блокировка в тестовете, които се изпълняват паралелно и те се опитват да създадат записи, които имат съответстващи стойности на полето на индекса. Блокиране ще настъпи, когато 2 текущи теста са на опашка за връщане на данните (това се случва, когато 2 тестови входни записа, които имат еднакви стойности на уникални полета на индекса в различни подреждания).
    • За да изключите паралелното тестово изпълнение, отидете на Setup, въведете Apex Test, отидете в диалоговия прозорец Apex Test Execution Options, изберете Disable Parallel Apex Testing, щракнете върху OK.

Деактивирайте паралелното тестване на Apex

Наемете професионалист за тази работа, тъй като той ще има необходимия опит и обучение, за да направи добър тест, който също ви дава спокойствие. Наемането на професионалист ви позволява да се концентрирате върху основния си бизнес. Освен това ви спестява пари, тъй като няма да имате нужда от вътрешен екип за работата.

Какво мислите?

Този сайт използва Akismet за намаляване на спама. Научете как се обработват данните за коментарите ви.