Парады і лепшыя метады праверкі інтэграцыі Salesforce

інтэграцыя Salesforce

Тэставанне Salesforce дапаможа вам праверыць наладжанасць Інтэграцыя Salesforce і функцыянальныя магчымасці з іншымі карпаратыўнымі праграмамі. Добры тэст ахоплівае ўсе модулі Salesforce - ад уліковых запісаў да патэнцыйных кліентаў, ад магчымасцей да справаздач і ад кампаній да кантактаў. Як і ў выпадку з усімі тэстамі, ёсць добры (эфектыўны і эфектыўны) спосаб правесці тэст Salesforce і дрэнны спосаб. Такім чынам, што такое праверка практыкі Salesforce?

  • Выкарыстоўвайце правільныя інструменты тэсціравання - Тэставанне Salesforce адбываецца ў браўзэры альбо ў асяроддзі зацьмення. І ў апошніх браўзэрах, і ў eclipse ёсць выдатныя інструменты адладкі, і вы можаце аб'яднаць іх з тэставымі класамі, каб атрымаць вельмі карысныя вынікі. Аднак, калі вам трэба больш, варта выкарыстоўваць інтэрактыўны адладчык Apex (альбо проста Apex) ад Force.com. Звярніце ўвагу, што вы таксама можаце выкарыстоўваць Salesforce Lightning Inspector, храмавае пашырэнне, для спецыяльнага тэсціравання Salesforce Lightning. Apex - гэта Force.com Фірмовая мова праграмавання на платформе, якая мае вялікае падабенства з Java. Гэта аб'ектна арыентаваная мова, якая не ўлічвае рэгістра, моцна тыпавая мова праграмавання, якая прытрымліваецца фігурных дужак і сінтаксісу кропкавых напісаў. Вы можаце выкарыстоўваць Apex для выканання запраграмаваных функцый падчас большасці працэсаў Force.com, уключаючы карыстацкія спасылкі і кнопкі, абнаўленні, выдаленні і апрацоўшчыкі падзей устаўкі запісаў праз карыстацкія кантролеры старонак Visualforce альбо планаванне.
  • Выкарыстоўвайце правільныя правілы наймення - Перад тым, як пачаць пісаць тэсты, вельмі важна правільна называць метады тэставання. Назва метаду выпрабаванняў павінна складацца з трох частак. Гэта nameOfMethod (назва індывідуальнага метаду, які вы тэстуеце, напрыклад, устаўка / абнаўленне / выдаленне / аднаўленне пры тэставанні трыгера, інфармацыя пра TestPath, якая з'яўляецца гнуткай, напрыклад, нулявы кантакт, калі вы тэстуеце, што кантакт нулявы і сапраўдны пры тэставанні станоўчы / адмоўны шлях.
  • Забяспечыць 100% пакрыццё - Хоць стандартная дырэктыва Salesforce заключаецца ў тым, што модульны тэст павінен ахопліваць 75% вашага кода (за вылікам тэставых класаў, выклікаў System.debug і метадаў тэсціравання), і вы не зможаце разгарнуць код Apex альбо ўпакаваць прыкладання AppExchange, вам варта звярніце ўвагу, што гэта проста стандарт, і ваша мэта павінна быць 100% ахопам. Праверце ўсе станоўчыя / адмоўныя выпадкі і наяўнасць дадзеных, якія ёсць і адсутнічаюць. Іншымі важнымі парадамі, якія тычацца ахопу кода, з'яўляюцца:
    • Вы павінны запусціць тэсты для абнаўлення нумароў пакрыцця кода, паколькі гэтыя лічбы не абнаўляюцца пры абнаўленні кода Apex, пакуль тэсты не будуць паўтораны.
    • Калі ў арганізацыі адбылося абнаўленне пасля апошняга тэставага запуску, існуе рызыка, што нумары пакрыцця кода будуць няправільнымі. Перазапусціце тэсты для правільнай ацэнкі.
    • Працэнт ахопу кода не ўключае ахоп кода з тэстаў кіраваных пакетаў, за выключэннем, калі гэтыя тэсты выклікаюць спрацоўванне трыгераў.
    • Ахоп залежыць ад агульнай колькасці радкоў кода. Калі вы дадасце або выдаліце ​​радкі кода, вы паўплываеце на працэнт.
  • Тэставыя справы ў класах і кантролерах - У распрацоўцы Salesforce большасць распрацоўшчыкаў стварае асобныя класы і файлы кантролера для кожнай функцыі. Гэта робіцца для таго, каб зрабіць кадаванне больш арганізаваным, прасцейшым, шматразовым і партатыўным. Аднак варта адзначыць, што, хоць гэта прасцей, але не больш эфектыўна. Вы даможацеся партатыўнасці, калі тэставы код будзе ў зыходным класе і сам код кантролера, бо пры міграцыі з пясочніцы на вытворчасць вы не прапусціце ніводнага тэставага класа.
  • Выкарыстоўвайце System.assert () - У Apex, System.assert() выкарыстоўваецца для праверкі ўмоў. Гэта важная функцыянальнасць, бо дазваляе вызначыць, ці была пэўная функцыя выканана метадам, як чакалася. Вы павінны выкарыстоўваць System.assertEquals () і System.assertNotEquals () паміж крытычнымі функцыянальнымі магчымасцямі не толькі дапамагае вам вызначыць, ці быў код выкананы належным чынам, але і пераканацца, што дадзеныя не запісаны памылкова, калі код памыляецца.
  • Комплексны тэст - Тэставанне павінна ахопліваць усё. Вы павінны зрабіць функцыянальнае тэсціраванне, тэставанне нагрузкі, тэсціраванне бяспекі і тэсціраванне разгортвання.
  • Адзінкавыя тэсты - Вы павінны прайсці модульныя тэсты, каб пераканацца, што асобныя запісы даюць правільны і чаканы вынік. Хоць выкарыстанне гіганцкага тэсту, які ахоплівае ўвесь код, можа здацца добрай ідэяй, звярніце ўвагу, што атрыманыя вынікі будуць складаней адладжваць, а няўдачы будзе цяжэй зразумець. Адзінкавы тэст павінен ахопліваць невялікую падгрупу функцыянальнасці, якая тэстуецца.
  • Тэставыя масавыя справы - Добры тэставы код (трыгер, выключэнне альбо клас) можа быць выкарыстаны для некалькіх соцень запісаў (200 для Apex). Вы павінны скарыстацца гэтым і праверыць не толькі асобныя запісы, але і масавыя выпадкі.
  • Станоўчыя тэсты - Тэст, каб пераканацца, што чаканае паводзіны адбываецца праз усе чаканыя перастаноўкі. Тэст павінен пераканацца, што карыстальнік правільна запоўніў форму і што ён / яна не перавысіў абмежаванні.
  • Адмоўныя тэсты - Праверце адмоўныя выпадкі, каб пераканацца, што паведамленні пра памылкі выдаюцца правільна. Прыклады такіх адмоўных выпадкаў - гэта адсутнасць магчымасці ўказаць адмоўныя сумы і адсутнасць магчымасці дадаваць будучыя даты. Негатыўныя тэсты важныя, таму што правільная апрацоўка, калі справы ідуць на поўдзень, можа ўсё змяніць.
  • Аўтаматызаваць тэставанне - Традыцыйна тэсціраванне Salesforce праводзілася ўручную. Вы павінны разгледзець магчымасць аўтаматызаванага тэсціравання, бо гэта дае больш пераваг. Сюды ўваходзяць:
    • Ручное тэсціраванне робіць вас успрымальнымі да памылак, бо тэсціраванне праводзіцца людзьмі, а не робатамі. Робаты атрымліваюць поспех у паўтаральных дзеяннях, у той час як людзі робяць памылкі з-за нуды, зніжэння канцэнтрацыі і паслядоўнасці і тэндэнцыі скарачаць куты.
    • Ручное тэсціраванне паўтаральнае, складанае і стомнае. Камандзе тэсціравання лепш займацца больш пошукавай працай.
  • Выканаць кожную галіну логікі кода - Пры выкарыстанні ўмоўнай логікі (калі вы ўключылі троечныя аператары), кожная галіна логікі кода павінна быць выканана.
  • Выкарыстоўваць несапраўдныя і дапушчальныя ўходы для выклікаў метадаў - Званкі да метадаў павінны здзяйсняцца як з несапраўднымі, так і з сапраўднымі ўваходамі.
  • Поўныя тэсты - Пераканайцеся, што тэсты прайшлі паспяхова - яны не павінны рабіць выключэнняў, калі толькі не чакаюцца памылкі. Апрацоўвайце ўсе выняткі - злавіць іх недастаткова добра.
  • Выкарыстоўвайце ЗАКАЗ па ключавых словах - Каб пераканацца, што вашы запісы вяртаюцца ў тым парадку, у якім вы іх чакаеце, выкарыстоўвайце ключавыя словы ORDER BY.
  • Не мяркуйце, што ідэнтыфікатары запісаў размешчаны паслядоўна - Пазбягайце распаўсюджанай памылкі, мяркуючы, што ідэнтыфікатары запісаў размешчаны ў паслядоўным парадку. Ідэнтыфікатары не ў парадку ўзрастання, калі вы не ўставілі некалькі запісаў з адным і тым жа запытам.
  • Выклічце Test.startTest () і Test.stopTest () - Калі вы запусціце модульны тэст Apex, вы атрымаеце больш за 75% ахопу кода, які з'яўляецца абавязковым у Salesforce. Перад сцвярджэннямі вам трэба патэлефанаваць stopTest, каб прымусіць асінхронныя коды, якія яшчэ могуць працаваць, скончыцца. Запускайце свежыя запыты для канчатковых вынікаў, бо іншы код можа змяніць дадзеныя. UsingTest.startTest () і Test.stopTest () гарантуе, што тэст у пясочнай праграме будзе знаходзіцца ў межах яго рэгулятара. Такім чынам, выкарыстаны вамі код налады не будзе перашкаджаць і выдаваць вам ілжывыя адмоўныя і станоўчыя моманты, якія тычацца абмежаванняў губернатара. Test.stopTest () таксама гарантуе, што выклікі @future завершацца для тэставання.
  • Чытальнасць - Чытальнасць вельмі важная ў модульных тэстах. Назвы тэстаў павінны ўключаць канкрэтныя дзеянні, якія трэба зрабіць, і чаканы вынік. Метад павінен быць апісальным і кароткім. Метад павінен быць такім, каб яго можна было паўторна выкарыстоўваць у розных тэстах.
  • Стварыце вялікія наборы тэставых дадзеных перад startTest - Паколькі вашы тэсты будуць працаваць у розных пясочніцах і вытворчых умовах, перад выклікам startTest пабудуйце вялікія наборы тэставых дадзеных, каб пераканацца, што тэст мае поўныя межы выканання. Па змаўчанні, Salesforce Github запускае тэсты, ізаляваныя ад дадзеных вытворчасці. Калі вам патрэбныя дадзеныя сістэмы, такія як профіль, запытайцеся, каб знайсці патрэбную рэч для гэтага канкрэтнага асяроддзя.
  • Стварыце ўласныя дадзеныя тэсту - Дадзеныя тэсту, якія вы выкарыстоўваеце, павінны стварацца ў тэсце. Вы можаце генераваць гэтыя дадзеныя, выкарыстоўваючы анатацыю @testSetup і клас TestUtils, каб не толькі пераканацца, што ў вас ёсць патрэбныя дадзеныя, але і забяспечыць выкананне ўсіх тэстаў у пясочніцы распрацоўніка без патрабаванняў да дадзеных.
  • Пазбягайце нулявых аперацый AKA нулявых аперацый - Шматлікія тэстары выкарыстоўваюць нулявыя аперацыі AKA нулявыя аперацыі. Гэта бескарысныя коды, якія нічога не робяць. Паколькі яны ўжо ёсць у вашай кодавай базе, яны павялічаць ваш працэнт пакрыцця.
  • Паралельнае выкананне тэсту - Калі вы запускаеце тэсты з карыстацкага інтэрфейсу Salesforce альбо з Developer Console, тэсты будуць працаваць паралельна. Гэта важная асаблівасць, бо яна паскарае тэставы час працы. Аднак вы павінны адзначыць, што гэта можа прывесці да праблем са звесткамі, і калі вы падазраяце, што гэта можа адбыцца, адключыце паралельнае выкананне. Самыя распаўсюджаныя прычыны праблем са спрэчкай дадзеных, якія часта прыводзяць да памылак UNABLE_TO_LOCK_ROW:
    • Калі тэсты прызначаны для абнаўлення тых самых запісаў адначасова. Абнаўленне адных і тых жа запісаў звычайна адбываецца, калі тэсты не ствараюць уласных дадзеных.
    • Калі ў тэстах, якія працуюць паралельна, ёсць тупік і яны спрабуюць стварыць запісы, якія маюць адпаведныя значэнні палёў індэкса. Тупік адбудзецца, калі 2 запушчаныя тэсты апынуліся ў чарзе на адкат дадзеных (гэта адбываецца, калі ўваходныя запісы 2 тэстаў маюць аднолькавыя значэнні палёў індэкса ў розных парадках).
    • Каб адключыць паралельнае выкананне тэсту, перайдзіце ў наладу, увядзіце Apex Test, перайдзіце ў дыялогавае акно Apex Test Execution Options, абярыце Адключыць паралельнае тэсціраванне Apex, націсніце OK.

Адключыць паралельнае тэсціраванне Apex

Найміце прафесіянала на працу, бо ён будзе мець вопыт і навучанне, неабходныя для добрай праверкі, якая таксама дае вам спакой. Найм прафесіянала дазваляе засяродзіцца на сваёй асноўнай дзейнасці. Гэта таксама эканоміць вашы грошы, бо вам не спатрэбіцца ўласная каманда.

Што вы думаеце?

Гэты сайт выкарыстоўвае Akismet для барацьбы са спамам. Даведайцеся, як дадзеныя апрацоўваюцца каментар.