Symfony parimad tavad (ametlik soovitus)
Veebiagentuur » Digitaalsed uudised » Symfony parimad tavad (ametlik soovitus)

Symfony parimad tavad (ametlik soovitus)

Mõni päev tagasi avalikustas Fabien Potencieri Sensio kaudu e-raamatu, mis koondab Symfony projekti arendamise parimad tavad ja soovitused. Selle kogukonna postitatud soovituste põhjal koostatud dokumendi eesmärk on anda nõuannete kogum seoses telefonigailoSophia Symfonyst. Püüan siin postituses lühidalt kokku võtta 31 inglise keeles kirjeldatud nippi.

Sissejuhatus

See dokument algab mõne nõuande ja mõne lausega, mille eesmärk on meid dokumendiga inspireerida.

"See dokument ei ole õpetus"

See dokument on kirjutatud eesmärgiga, et kõik Symfony arendajad seda loeksid. Nii eksperdid kui ka uusfüüdid.

"Ära muutke oma rakendusi ümber"

Dokumendi algusest peale on konkreetselt selgitatud, et pärast seda lugemist ei tohiks me oma rakendusi värskendada ega ümber kujundada, et see sobiks ideaalselt Sensio mitmete soovitustega. Seetõttu saame kohe luua lingi dokumendis välja töötatud esimeste ideedega: need head tavad peaksid võimaldama meil oma elu lihtsustada, aga ka koodide läbivaatamist. Minu märkuste toetuseks toon välja kolm põhjust:

  • Teie olemasolevad rakendused ei ole valed, need lihtsalt järgivad teisi juhiseid;
  • Täielik koodibaasi ümberkujundamine põhjustab teie rakendustes vigu;
  • Sellele kulutatud töömaht võiks olla paremini pühendatud teie testide täiustamisele või lõppkasutajatele tõelist väärtust pakkuvate funktsioonide lisamisele.

Looge projekt

Peatükis 2, mis käsitleb Symfony projekti deklareerimist ja loomist, on antud esimene “Parim tava”.

_Kasutage alati Composerit. _Composer tutvustas kaasaegse PHP põhitõdesid selle sõltuvuslahutuse kaudu. Tänu temale on sõltuvused failis registreeritud comper.json lahendatakse ja saadetakse teie projektis tagasi kodumaale, et see oleks kasutatav. Lisaks saab teha lihtsaid uuendusi.

Nii saate austada Symfony projekti struktuurilist korraldust. (vt lk 8).

Näited:

  • rakendus/vahemälu salvestab vahemälu;
  • rakendus/logid kaupluse logid;
  • rakendus/ressursid salvestab teie rakenduse mallid ja globaalsed tõlked;
  • src / salvestage oma rakenduste paketid;
  • müüja / salvestada oma projekti sõltuvused;
  • võrk/ salvestab varad (css, js, pildid jne) ja ka esifaili (app.php), mis võimaldab teil hiljem oma päringud oma kontrolleritele ümber suunata.
    Selle tulemusena uus soovitus kimpude kohta. Ilma oma analüüsi tegemata, mis võiks ph kahtluse alla seadailosophie Symfonyst (mida ma ei taha), siin on soovitus:

Looge rakenduse jaoks üks AppBundle'i pakett. See on tingitud Symfony disainist. Iga pakett peab olema _eraldi. _Seepärast peaksid nad saama elada iseseisvalt ja iseseisvalt.

Jätan teil selle soovituse üle mõtisklema…

konfiguratsioon

Kolmas peatükk annab meile nõuandeid selle rakenduse konfigureerimiseks. Mõned konfiguratsioonielemendid võivad arendussüsteemist tootmissüsteemini erineda.

Nagu soovitus näitab, peate seetõttu määrake oma infrastruktuuriga seotud konfiguratsioon failis app/config/parameters.yml.

Vastupidi, teie projektile omane konfiguratsioon, mis on staatiline, deklareeritakse app/config/config.yml.

Lisaks fail parameetrid.yml ei tohiks versioonida. See on fail parameetrid.yml.dist kes peaks olema. Just see fail annab teile rakenduse konfigureerimise põhivalikud. (soovitus lk 12).

Selle tulemusena fail _app/config/config.yml _ise on soovituslik.

Määrake oma rakendusega seotud konfiguratsioon saidil app/config/config.yml
Seda soovitust järgides on siiski soovitatav fail genereerida config.yml, config_dev.yml ja fail config_prod.yml. Need failid on mõeldud arenduskeskkonnale ja tootmiskeskkonnale omaste konstantide salvestamiseks.
Peame väärtust pidama konstantseks, kui selle väärtus muutub väga vähe.

Sõltuvussüst

Siin me oleme ! Kolmandas peatükis kirjeldatakse üksikasjalikult soovitust sõltuvuste kasutamise kohta. Soovitan teil see soovitus läbi lugeda, kui mu selgitus tundub teile ebamäärane.

See soovitus puudutab teenuste lisamist teenustesse. Sensio soovitab need failis deklareerida src/AppBundle/Resources/config/services.yml.

Kutsun teid lugema ka minu artiklit sõltuvussüstist ja sellest, kuidas piirata superteenuse konteineri kasutamist.

Deklareerige sisemist loogikat

4. peatükk käsitleb teie taotluse korraldamist. Sõltuvalt teie vajadustest on organisatsioon erinev. Globaalsete ja mitteäriliste funktsioonide puhul soovitab Sensio need kausta paigutada Utilid või lihtsalt võtke need oma komplektist välja ja pange see eraldi kausta. Pärast seda on tungivalt soovitatav kuulutada oma klass teenuseks. Nende deklareerimiseks antakse uus soovitus.

Teie teenuse nimi peaks olema võimalikult lühike, ideaaljuhul ühest sõnast.

Failivormingu valimine

Olles eriti kiindunud Symfony Yaml-vormingusse, kujutan ette, et see punkt tõstab lahkarvamusi. Sensio soovitab kompromissitult kasutada rakendustes Yaml-vormingut. Välja töötatud komplekte jagatakse kahes vormingus: XML ja Yaml.

Sensio otsustas viimast soovitada lihtsalt seetõttu, et see on rohkem " kasutajasõbralik ". Muu vormingu kasutamine ei muuda teie rakenduse toimimist.

Ärge määrake oma teenuste deklaratsiooni jaoks muutujat

See on tava, mida näete teatud kimpudes palju, kuid Sensio hoiatab teid. Siin on dokumendis toodud näide kokaraamat :

1
2
3
4
5
6
7
8
#app/config/services.yml
# teenus definition, mille parameetriks on klassi nimeruum
parameetrid:
slugger.class: AppBundleUtilsSlugger
teenused:
slugger:
klass:
"%slugger.class%"

Siin on näide kasutu koodist. Teenuse jaoks kasutatava klassi deklareerimine on viga, kuna seda muutujat võidakse kasutada koodis mujal. Lisaks kaalub see Sensio põhjendusel ka teenuse loomist.

ORM-i valik

Sensio soovitab kasutada Symfonys Doctrine ORM-i. Doctrine'i kasutajana on selle integreerimine Symfonysse väga arenenud. Selle tulemuseks on soovitus, mis taaskäivitab meie projektide loogilise korralduse. Olemi deklaratsioon peab hoidma loogikat kimbus. Vaata näidet lk 18.

Kaardistamise deklaratsioon

Doctrine kaardistamise deklareerimine tuleks eelistatavalt läbi viia tänu märkustele, mida soovitatakse Doctrine'i raames, aga ka muude rakenduste jaoks.

Kasutage olemi vastendamise deklareerimiseks märkusi.
Näide on toodud leheküljel 19.

Armatuuride paigaldamine

Sensio soovitab ilma ette panemata seada paika inventar. Asjatundmatute jaoks on need andmestikud, mida kasutatakse vaikimisi rakenduse käivitamiseks enne selle tootmisse panemist.

Kodeerimisstandardid (4. peatüki lõpp)

See on osa, mille Sensio on kummalisel kombel peaaegu varjutanud. Ütlen imelikult, kuna see on minu jaoks oluline osa.

Symfony on kodeeritud vastavalt PSR1 ja PSR2 standarditele. Neid standardeid tuleb propageerida Symfony arendajate kogukonnas, aga ka PHP arendajate seas. Symfony on postitanud artikli, et koguda ja tõsta esile " Kodeerimisstandardid ". Sensio juht Fabien Potencier on GitHubisse pannud ka tööriista standardite järgimise kontrollimiseks.

Kontrollerid

Kui rääkida kontrolleritest, siis Symfony telilosophie "õhukesed kontrollerid ja paksud mudelid". See tähendab, et kontrollerid peaksid jääma kergeks. Iga marsruudi kaudu ligipääsetav meetod (toiming) tähistab toimingut. Kõigi nende meetodite kood peab olema "kerge" ning kutsuma ja koordineerima toiminguid. Need aktsiad peavad olema teenustes.

See mudel kujutab kontrollerit rakenduskoode/osi kasutavana.

Kontroller peab järgima mõnda reeglit

  • Kontrolleril peab olema maksimaalselt 5 muutujat.
  • Kontrolleril on maksimaalselt 10 toimingut.
  • Iga toiming peab sisaldama maksimaalselt 20 rida.
    • Meetod võib sisaldada rohkem kui 20 rida eeldusel, et kasutatavat koodi ei saa faktoriseerida.

      Kontroller peaks pärima Sensio FrameworkBundle'i baaskontrolleri ja kasutama marsruutide, vahemällu salvestamise ja turvalisuse haldamiseks märkusi.

      Soovitatav on kasutada annotatsioone, kuid kehtib ka XML, YAML või PHP kasutamine. Rakendus peaks kasutama ainult ühte vormingut.

Ärge kasutage @Template

See on soovitus vähem ootamatutele, kuid seletus on eriti võimas.

Ärge kasutage @Template() annotatsiooni kontrolleri kasutatava malli konfigureerimiseks
Seletus on lihtne, @Mall kasutab TemplateListenerit, mis kutsutakse välja sündmuse ajal kernel.view visatakse.
Selle dokumendi koostamise ajal viidi läbi test. @Template kasutamine võtab 26 ms enne genereerimise käivitamist, samas kui sama lehe puhul, mis oleks loodud kasutades " $this->render (…) », ooteaeg 5 millisekundit.

Kasutage ParamConverteri annotatsiooni

Selle märkuse kasutamine võimaldab automatiseerida olemi hüdratatsiooni.

ParamConverteri nipi kasutamine on hea, kui see on lihtne ja mugav.

Mallid

6. peatükis kirjeldatakse malli genereerimist. See on ilma _kärata, mida dokument meile mitmete soovituste põhjal annab.

  • Kasutage Twig mallimootorit
    Sensio soovitab Twigi mitmel põhjusel. Peale selle, et on a mootor laialdaselt kasutatav PHP kogukonnas, nii PHP arendajate poolt algusest, ainult Symfony arendajate ja muude raamistike poolt. Rõhutatakse lihtsust ja nende toote reklaamimine on selgelt nähtav. Lõpuks garanteerib Sensio toe Symfonyle kuni selle versioonini 3. Samuti võite leida esimesed üleminekud, mis tuleb teha koodi ettevalmistamiseks versioonile 3 üleminekuks.
  • Salvestage rakenduse mallid rakendus/Ressursid/vaated.
    Vaikimisi on arendajad harjunud salvestama oma malle kausta Vahendid igast kimbust. See pole halb, kuid Fabien Potencieri soovitab salvestada oma rakenduse globaalsed mallid ülalmainitud kausta.
  • Määratlege oma Twigi laiendused AppBundle/Twig ja seadistage teenuseid sisse app/config/services.yml.
    Oksapikendused kannatavad halva nähtavuse all. Neid laiendusi, kuigi kasulikud, kasutatakse mõnikord liiga süstemaatiliselt. Sensio esitleb seda osa, mis minu arvates on oluline, et sisestada oma mallidesse ärikood. Soovitan lugeda, kuidas Twigi laiendit deklareerida.

Blanketid

Peatükk 7 annab meile juhised vormide kasutamiseks.

  • Määrake oma vormid PHP klassides.
    Symfony annab võimaluse genereerida PHP klasse, mis võimaldavad antud olemite jaoks vorme automaatselt genereerida. THE Blanketid nagu neid nimetatakse, pakub täielikku integratsiooni. Abistatakse olemite muutmist. Lisaks võimaldab vormide kasutamine mallidelt vormide haldamist deporteerida.
  • Ärge deklareerige nuppu selle vormi saatmiseks.
    See on üllatav punkt, kuna see funktsioon võeti kasutusele Symfony 2.5-s. Nende ridade kirjutamise ajal on Symfony 2.6 vastuvõtmisel ja seetõttu pole seda veel ametlikult välja antud. Seetõttu võime tõstatada mõned küsimused selle funktsiooni kasulikkuse kohta, seda ei tohiks kasutada!Miks lisada nuppe mallidesse, mitte vormidesse?
    Sensio meeskond selgitab oma selgituses, et kuigi see funktsioon jääb alles "kasutajasõbralik" ja et see lihtsustab vormide rakendamist, jäävad teatud funktsioonid piiratuks.
    Näiteks kui lisate tüübinupu esitama sildiga "Loo", ei saa seda vormi redigeerimislehe jaoks uuesti kasutada. Seejärel peate oma vormi deklareerima pärimise teostamiseks teenusena, mis ei ole soovitatav veidi allpool.
  • Ärge kasutage Twig funktsioone vorm () ja _vormstart ().
    Mallide renderdamisele pühendatud osa on loodud. Ta õpetab meile, et Twig funktsioonid on kasutusel vorm () Ja _ form_start()_ on aegunud. Taaskord on see minu jaoks viga, kuna need funktsioonid olid saadaval alles hiljuti.
    Symfonys on vormi renderdamiseks mitu võimalust. Erinevatest renderdamisviisidest on parim viis, mis pakub maksimaalset paindlikkust.
    Eespool loetletud Twig funktsioonide kasutamine toob vähe kasu. Sensio räägib paremast loetavusest natiivsete HTML-märgendite kasutamisel. Sellest argumendist hoolimata on see väike kasu… Väga väike!

Deklareerige oma vormid teenustena

Vormid on PHP klassid, mis tähendab, et neid saab deklareerida teenusena. Seda meetodit näete kimpudes FriendsOfSymfony. Sensio seda meetodit ei soovita, välja arvatud teatud juhtudel, mida tsiteerin allpool:

  • Kui soovite olemasolevaid vorme uuesti kasutada. Kahe vormi vahelise pärandi seadistamine võimaldab piirata kõigi atribuutide ümberkirjutamist.
  • Kui tahame manustada olemikogusid.
    Vormide kasutamine teenustena vormi lisamise või muutmise korral ei ole soovitatav, kuna teenuse kasutamine laadib @konteiner. Lisaks on raske mõista, et seda teenust kasutab kontroller.

Kinnitage (köitke) selle vormid

Hiljuti alustas Sensio Symfony2 koodi pidevat migreerimist tulevasele Symfony3 koodile. Muudatuste loendi hulgas, mida saab teha (need kõik leiate failist UPGRADE-3.md), on uus lahendus sideaine päring, mis saadeti koos vormiga vorm mis loodi. Uus metoodika on üksikasjalikult kirjeldatud leheküljel 21 Best Practices.

Kuulake esitatud väljavõtet:

1
2
3
4
5
6
7
8
9
10
11
12
13
avalik funktsioon uusAction(Taotlus $taotlus)
{
// koostage oma vorm
$vorm->handleRequest($request);
if ($vorm->isSubmitted() && $form->isValid()) {
$em = $ see->konteiner->hangi("doctrine.orm.default_entity_manager");
$em->persist($post);
$em->flush();
tagasipöördumine $ see->redirect($ see->generateUrl("admin_post_show"), massiivi("id" => $post->getId()));
}
}

Rahvusvahelistumine

Rahvusvahelistumise mooduli eesmärk on tõlkida sisu ühest keelest teise, olenevalt piirkonnast või kasutaja keelest. See peatükk on rohkem kui soovituste andmed kirjutatud selleks, et näidata võimalusi selles osas, mis jääb alati tundlikuks.

Peatükis 8 kirjeldavad toimetajad üksikasjalikult, kuidas aktiveerida tõlkimine.

kuidas on formaadiga

Symfony pakub paljusid tõlkevorminguid:

  • PHP
  • Qt
  • .po
  • .mo
  • JSON
  • CSV
  • START
  • ja paljud teised

    Kasutage oma tõlkefailide jaoks XLIFF-vormingut.
    See tsitaat on ilmselgelt Sensio soovitus. Jah aga miks? Meile antakse lühike ja täpne vastus.
    Kõigist toetatud vormingutest toetavad professionaalsed tõlketööriistad ainult XLIFF-vormingut ja gettexti vormingut. Kuna XLIFF põhineb XML-il, on see kasulik sisu valideerimisest.
    Symfony 2.6 toob kaasa uue funktsiooni, mis võimaldab teil XLIFF-failidesse "kommenteerida" (märkmeid lisada). See on suur uudsus, sest tõlkefailide genereerimine võib tõlkijatel tekitada probleeme lause tähenduse või selle kasutamise konteksti mõistmisel. Ühesõnaga, XLIFF on hea!

Kus meie tõlkefaile säilitada?

See küsimus tutvustab a Parim harjutus. Sensio soovitab meie failid salvestada rakendus/Ressursid/tõlked.

Tavaliselt salvestasime oma tõlked igasse kimpu. See ei olnud halb, kuid tõlkeid peetakse üldiselt meie rakenduste globaalseteks osadeks, nagu ka globaalseid malle, mistõttu Sensio soovitab meil need salvestada app.

Kuidas meie rakendusi tõlkida?

Kasutage sisu tõlkimiseks alati klahve.
Niisiis parim, ma ei avalda oma arvamust, kuna mul on vähe võimalusi rakendusi tõlkida. Sensio soovitab sellise sõna nagu "Kasutajanimi" tõlkimiseks kasutada võtit nagu silt.kasutajanimi.

Näide on toodud leheküljel 35.

Turvalisus

Raamatu 9. peatükk käsitleb Symfony keskset osa; Turvalisus !

Symfony eesmärk on hõlpsasti konfigureerida ja autentida kasutajaid, kes soovivad meie rakendustega ühendust luua. See osa on väga keeruline ja täis detaile, seega on see konarlik ülevaade. Lisateavet leiate spetsiaalselt lehelt.

Deklareerige oma tulemüürid

Konfiguratsioonivalikud tuleb faili sisestada turvalisus.yml mis on sees rakendus/konfiguratsioon.

Kui teil pole rakendusega (süsteemi ja kasutajatega) kahte erinevat ühendust, soovitame kasutada ainult ühte sisenemise tulemüüri, mille anonüümne valik on aktiveeritud.
Vau vau vau! Oota, ma jõuan Symfonyle, ma ei saanud midagi aru!

Mis on tulemüür?

Leiate Wanadevis tehtud artikli selle kohta, kuidas Symfony algset autentimist deklareerida ja seadistada. Selles artiklis kirjeldatakse üksikasjalikult, mis on tulemüür.

Üks tulemüür? Miks a?

Kui lugesite just ülaltoodud artiklit, võisite märgata, et deklareeritud on mitu tulemüüri.

Antud artiklis olid kolm nime Dev, põhiline et Logi sisse. Sellele vaatamata järgitakse antud reeglit, lüüsiks saab lugeda ainult tulemüüri.

  • Dev : see tulemüür võimaldab silumisriba kuvada.
  • põhiline : see tulemüür on meie SISENEMISPUNKT. Anonüümsed kasutajad saavad sisse logida justkui reeglist kinni pidades. Kõik / algavad marsruudid kasutavad seda kirjet.
  • Logi sisse : see on tulemüür. See on meie värav ühel juhul: kui tahame ühendust luua. See on sisselogimisvormile juurdepääsu saamiseks hädavajalik.
    Seetõttu peetakse reeglist kinni.

Määratlege kodeering

Paroolide kodeerimine on oluline otsus. Algoritme on mitu, nt sha (sha1, sha256, sha512, md5...).

Kodeeringu deklareerimisel (vt. kuidas kodeeringut deklareerida) saab anda kolm parameetrit.

  • Krüpteerimisalgoritm (vaikimisi: sha512);
  • iteratsioonide arv (vaikimisi: 5000);
  • Kodeering on kodeeritud parooli base64 (vaikimisi: true).
    Vaatamata nendele vaikeväärtustele, mida ma kutsun teid muutma, et neid oma rakenduste jaoks muuta. Sensio soovitab kasutada ka algoritmi bcrypt.

    Kasutage kasutajate paroolide krüptimiseks bcrypt-kodeeringut.
    Sensio selgitab, kuidas kasutada bcrypt. See hõlmab a soolamine väärtus. See piirab rünnakuid ja on vastupidavam toore jõu tüüpi rünnakutele. Lisateavet leiate ülaltoodud Vikipeedia artiklist.

Määra õigused

Ühenduse ajal tuvastab Symfony, millist tulemüüri tuleks kasutada. Seejärel ja isegi enne kontrollerile juurdepääsu kontrollitakse juurdepääsu. Need on failis määratletud turvalisus.yml,

Sensio soovitab:

  1. kaitsta meie "serva URL-i mustreid", mõista meie globaalseid mustreid (näide: /admin);
  2. Kasutage märkusi @Turvalisus nii palju kui võimalik ;
  3. Kontrollige teenuse kaudu kasutaja õigusi turvalisus.kontekst (alates Symfony 2.6-st on teenus arenenud, vt siit);
  4. Määrake valijad liiklusohutuse hõlpsaks juhtimiseks;
  5. Kasuta ACL objekti- ja kasutajaõiguste haldamiseks.

Kasutage @Turvamärkusi

Sensio soovitab kasutada @Security annotatsiooni.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
kasutama SensioKimpFrameworkExtraBundlekonfiguratsioonMarsruut;
kasutama SensioKimpFrameworkExtraBundlekonfiguratsioonTURVALISUS;
// …
/ **
* Kuvab vormi uue postituse olemi loomiseks.
* @Tee(“/uus”, nimi=”admin_post_uus”)
* @Turvalisus("has_role('ROLE_ADMIN')")
*/
avalik funktsioon uusAction()
{
// …
}

Piirangute keerukamaks muutmiseks kasutage väljendeid

Sensio selgitab meile, et see annotatsioon võimaldab luua ka keerukamaid tingimusi, näiteks kahe objekti kahe atribuudi võrdlemist. See märkus võib nõuda kasutamist ParamConverter.

Lisateavet leiate dokumendist:

  • Looge väljendeid
  • Teisenda atribuudid objektideks

Juurdepääsu turvalisus Twigis

Kui soovite võrrelda ühendatud kasutajat objekti kasutajaga, pääsete juurde Twig the kasutaja Pooleli.

1
2
3
{% if app.user … %}
...
{% endif %}

Hallake oma turvalisust lihtsalt

Turvalisuse haldamine on sageli tundlik osa ja meie koodi korraldamine on meie rakenduse eduka turvalisuse oluline osa. Kasutamine valijad on väga soovitatav. Koodi korraldamiseks võib kaaluda muid viise. Näiteks saame otsuse üle kanda oma olemi meetodile.

Sensio näidet saate vaadata lk 40.

See osa on Symfony pakutavate võimalustega võrreldes väga vähe üksikasjalik. Kui teil on turvaülesanne, soovitan teil lugeda selle osa kohta veidi rohkem dokumentatsiooni.

Veebivarad

Varad võimaldavad meil hallata ressursse, nagu Javascript, CSS, fos-fondid, pildid jne, et need oleksid teie lehtedelt juurdepääsetavad.

Teie varad tuleb salvestada veebi/kausta
Nii saate oma ressursse oma mallidesse laadida järgmiselt.

1
2
<link rel="stiilileht" href=« {{ asset(‘css/bootstrap.min.css’) }}«  />
<käsikiri src=« {{ asset(‘js/jquery.min.js’) }}« ></käsikiri>

Hoidke avalikku veebikausta ja kõike, mis sinna salvestatakse.

Kasutage Asseticut

Asseticul on mitu huvi, näiteks failide koostamine. Näiteks Less, Sass, TypeScript failid... Sel põhjusel kaust web ei tohi sisaldada selliseid faile nagu failid .vähem.

Kasutage Asseticut oma varade koostamiseks, kombineerimiseks ja minimeerimiseks, välja arvatud juhul, kui kasutate GruntJS-i.

Lisateave Asseticu kohta

Assetic on täielik tööriist vaatamata mõningatele puudustele. Selle mooduli dokumentatsiooni leiate allolevate linkide kaudu:

  • Kasutage Asseticut
  • Minimeerige CSS ja JS
  • Piltide tihendamine
  • Vaadake ametlikku dokumentatsiooni

Seadistage testid

Enamik arendajaid peab testimist hädavajalikuks. Kuid ainult vähemus rakendab neid.

Vaatame, kuidas Sensio soovitab meil testid läbi viia.

Tehke ühikutestid

Ühikteste kasutatakse funktsionaalsete testide tegemiseks, mis omakorda testivad teie rakenduse loogikat. Symfony ei ole teie testide testimiseks määranud ühtegi konkreetset tööriista. Tööriistad PHPUnit et PhpSpec on tsiteeritud.

Tehke funktsionaalsed testid

Funktsionaalsete testide jaoks heade stsenaariumide loomine on hädavajalik, kuid arendajatel tekib nende rakendamisel kiiresti probleeme.

Määratlege funktsionaalne test, et kontrollida, kas teie leht on õigesti laaditud.

Proovige kasutada kõvakodeeritud URL-e, selle asemel, et neid generaatori kaudu genereerida.

Testige JavaScripti funktsionaalsust

Selliseid tööriistu on palju Naarits (PHPUniti teek) ja CasperJS.

Andmekogude genereerimine

See on sageli probleem arendajatele, kes loovad andmekogumeid.

Sensio soovitab kasutada raamatukogusid Faker et Alice.

järeldus

See artikkel on pärit Parimad tavad eest Symfony. Kuigi see artikkel jääb lihtsaks, on selle artikli eesmärk jagada 50 lehekülge nõuandeid, et juhendada uusi Symfony arendajaid.

★ ★ ★ ★ ★