Eenheidtoetse in 'n DBBS - hoe ons dit doen in Sportmaster, deel twee

Eerste deel - hier.

Stel jou 'n situasie voor. Jy staan ​​voor die taak om nuwe funksionaliteit te ontwikkel. Jy het ondervinding van jou voorgangers. As jy aanvaar dat jy geen morele verpligtinge het nie, wat sou jy doen?

Meestal word al die ou verwikkelinge vergeet en alles begin weer van voor af. Niemand hou daarvan om in iemand anders se kode te delf nie, en as jy tyd het, waarom nie jou eie stelsel begin skep nie? Dit is 'n tipiese benadering, en in baie opsigte is dit korrek. Maar in ons projek het ons anders opgetree. Ons het die toekomstige outomatiese toetsstelsel gebaseer op die ontwikkelings in eenheidstoetse op utPLSQL vanaf ons voorgangers, en het toe in verskeie parallelle rigtings te werk gegaan.

1. Herstel van ou eenheidstoetse. Herstel beteken aanpassing van toetse by die bestaande toestand van die lojaliteitstelsel en aanpassing van toetse by utPLSQL-standaarde.
2. Om die probleem op te los met begrip, en wat presies, watter metodes en prosesse, het ons gedek met outotoetse. Jy moet óf hierdie inligting in jou kop hou, óf gevolgtrekkings maak wat direk op die kode van outotoetse gebaseer is. Daarom het ons besluit om 'n katalogus te skep. Ons het 'n unieke herinneringskode aan elke outotoets toegeken, 'n beskrywing geskep en die instellings reggestel (byvoorbeeld onder watter omstandighede dit uitgevoer moet word, of wat moet gebeur as die toetslopie misluk). In wese het ons die metadata oor die outotoetse ingevul en hierdie metadata in die standaardtabelle van die utPLSQL-skema geplaas.
3. Definisie van uitbreidingstrategie, m.a.w. keuse van funksionaliteit wat onderhewig is aan verifikasie deur outotoetse. Ons het besluit om aan drie dinge aandag te gee: nuwe verbeterings aan die stelsel, voorvalle van produksie en sleutelprosesse van die stelsel. Ons ontwikkel dus parallel met die vrystelling, wat die hoër gehalte daarvan verseker, terselfdertyd die omvang van die regressie uitbrei en die betroubaarheid van die stelsel op kritieke plekke verseker. Die eerste so 'n bottelnek was die proses om afslag en bonusse per tjek uit te deel.
4. Ons het natuurlik nuwe outotoetse begin ontwikkel. Een van die eerste vrystellingstake was om die prestasie van voorafbepaalde monsters van die lojaliteitstelsel te evalueer. Ons projek het 'n blok streng vaste sql-navrae wat kliënte volgens voorwaardes kies. Kry byvoorbeeld 'n lys van alle kliënte wie se laaste aankoop in 'n spesifieke stad was, of 'n lys van kliënte wie se gemiddelde aankoopbedrag bo 'n sekere waarde is. Nadat ons outotoetse geskryf het, het ons voorafbepaalde monsters, vaste maatstafprestasieparameters nagegaan, en ons het ook lastoetsing gekry.
5. Werk met outotoetse behoort gerieflik te wees. Die twee mees algemene aksies is om outotoetse uit te voer en toetsdata te genereer. Dit is hoe twee hulpmodules in ons stelsel verskyn het: die bekendstellingsmodule en die datagenereringsmodule.

   Die lanseerder word voorgestel as een generiese prosedure met een invoerteksparameter. As 'n parameter kan jy 'n outotoets-mnemoniese kode, pakketnaam, toetsnaam, outotoetsinstelling of 'n gereserveerde sleutelwoord deurgee. Die prosedure kies en voer alle outotoetse uit wat aan die voorwaardes voldoen.

   Die datagenereringsmodule word as 'n pakket aangebied, waarin vir elke objek van die stelsel wat getoets word ('n tabel in die databasis), 'n spesiale prosedure geskep is wat data daar invoeg. In hierdie prosedure word die verstekwaardes tot die maksimum gevul, wat verseker dat voorwerpe letterlik met die klik van 'n vinger geskep word. En vir gemak van gebruik is sjablone vir die gegenereerde data geskep. Skep byvoorbeeld 'n kliënt van 'n sekere ouderdom met 'n toetsfoon en 'n voltooide aankoop.

6. Outotoetse moet hardloop en hardloop binne 'n redelike tyd vir jou stelsel. Daarom is 'n daaglikse nagbekendstelling gereël, gebaseer op die resultate waarvan 'n verslag oor die resultate gegenereer word en per korporatiewe pos aan die hele ontwikkelingspan gestuur word. Nadat ou outotoetse herstel en nuwes geskep is, was die totale looptyd 30 minute. So 'n vertoning het almal gepas, aangesien die bekendstelling buite-ure plaasgevind het.

   Maar ons moes daaraan werk om die spoed van werk te optimaliseer. Die produksielojaliteitstelsel word snags opgedateer. As deel van een van die vrystellings moes ons snags dringend veranderinge aanbring. 'n Halfuur wag vir die uitslae van outotoetse om drieuur in die oggend, het die persoon verantwoordelik vir die vrylating nie gelukkig gemaak nie (vurige groete aan Alexei Vasyukov!), En die volgende oggend is baie warm woorde teenoor ons stelsel gesê. Maar as gevolg daarvan is 'n 5-minute standaard vir werk gestel.

   Om werkverrigting te bespoedig, het ons twee metodes gebruik: ons het outotoetse in drie parallelle drade begin uitvoer, aangesien dit baie gerieflik is as gevolg van die argitektuur van ons lojaliteitstelsel. En ons het die benadering laat vaar toe die outotoets nie toetsdata vir homself skep nie, maar probeer om iets geskiks in die stelsel te vind. Nadat veranderinge aangebring is, is die totale bedryfstyd tot 3-4 minute verminder.

7. 'n Projek met outotoetse behoort op verskeie staanplekke ontplooi te kan word. Aan die begin van die reis was daar pogings om ons eie bondellêers te skryf, maar dit het duidelik geword dat 'n selfgeskrewe outomatiese installasie 'n volledige gruwel is, en ons het na industriële oplossings gewend. As gevolg van die feit dat die projek baie kode direk het (in die eerste plek stoor ons die kode van outotoetse) en baie min data (die hoofdata is metadata oor outotoetse), blyk dit baie maklik te wees om in die Liquibase-projek.

   Dit is 'n oopbron databasis onafhanklike biblioteek vir die dop, bestuur en toepassing van databasis skema veranderinge. Bestuur via opdragreël of raamwerke soos Apache Maven. Die beginsel van werking van Liquibase is redelik eenvoudig. Ons het 'n projek wat op 'n sekere manier georganiseer is, wat bestaan ​​uit veranderinge of skrifte wat na die teikenbediener gerol moet word, en beheerlêers wat bepaal in watter volgorde en met watter parameters hierdie veranderinge geïnstalleer moet word.

   Op die DBMS-vlak word 'n spesiale tabel geskep waarin Liquibase die terugrollog stoor. Elke verandering het 'n berekende hash wat elke keer vergelyk word tussen die projek en die staat in die databasis. Danksy Liquibase kan ons maklik veranderinge aan ons stelsel na enige stroombaan uitrol. Outotoetse word nou uitgevoer op toets- en vrystellingkringe, sowel as op houers (persoonlike ontwikkelaarkringe).

Dus, kom ons praat oor die resultate van die toepassing van ons eenheidstoetsstelsel.

1. Natuurlik is ons eerstens oortuig dat ons beter sagteware begin ontwikkel het. Outotoetse loop daagliks en vind dosyne foute elke vrystelling. Boonop hou sommige van hierdie foute slegs indirek verband met die funksionaliteit wat ons regtig wou verander. Daar is sterk twyfel dat hierdie foute deur handtoetsing gevind is.
2. Die span het vertroue gekry dat spesifieke funksionaliteit reg werk... Eerstens gaan dit oor ons kritieke prosesse. Byvoorbeeld, oor die afgelope ses maande het ons geen probleme gehad met die verspreiding van afslag en bonusse per tjek nie, ten spyte van die veranderinge wat elke vrystelling aangebring is, alhoewel in vorige tydperke foute met 'n sekere frekwensie voorgekom het
3. Ons het daarin geslaag om die aantal toetsherhalings te verminder. Weens die feit dat outotoetse vir nuwe funksionaliteit geskryf word, kry ontleders en deeltydse toetsers 'n kode van hoër gehalte, want dit is reeds geverifieer.
4. Deel van die ontwikkelings van outomatiese toetsing word deur ontwikkelaars gebruik. Byvoorbeeld, toetsdata op houers word geskep met behulp van die objekgenereringsmodule.
5. Dit is belangrik dat ons 'n "aanvaarding" van die outomatiese toetsstelsel deur ontwikkelaars ontwikkel het. Daar is 'n begrip dat dit belangrik en nuttig is. En uit eie ervaring kan ek sê dat dit ver van die geval is. Outotoetse moet geskryf word, dit moet in stand gehou en ontwikkel word, die resultate ontleed word, en dikwels is hierdie tydskoste eenvoudig nie die moeite werd nie. Dit is baie makliker om na produksie te gaan en probleme daar te hanteer. In ons land staan ​​ontwikkelaars in tou en vra om hul funksionaliteit met outotoetse te dek.

Wat is volgende?

Kom ons praat oor die ontwikkelingsplanne van die outomatiese toetsprojek.

Natuurlik, solank die Sportmaster-lojaliteitstelsel lewendig is en aanhou ontwikkel, kan outotoetse ook byna eindeloos ontwikkel word. Daarom is die hoofrigting van ontwikkeling die uitbreiding van die dekkingsgebied.

Soos die aantal outotoetse toeneem, sal die totale tyd van hul werk geleidelik toeneem, en ons sal weer moet terugkeer na die kwessie van prestasie. Die oplossing sal waarskynlik wees om die aantal parallelle drade te verhoog.

Maar dit is ooglopende maniere van ontwikkeling. As ons oor iets meer nie-triviaal praat, beklemtoon ons die volgende:

1. Nou word outotoetse op die DBMS-vlak bestuur, m.a.w. kennis van PL/SQL word vereis vir suksesvolle werk. Indien nodig, kan stelselbestuur (byvoorbeeld die bekendstelling of skep van metadata) deur 'n soort administrasiepaneel met Jenkins of iets soortgelyks verwyder word.
2. Almal hou van kwantitatiewe en kwalitatiewe aanwysers. Vir outomatiese toetsing is so 'n universele aanwyser Kodedekking of kodedekkingsmetriek. Deur hierdie aanwyser te gebruik, kan ons bepaal watter persentasie van die kode van ons stelsel wat getoets word deur outotoetse gedek word. Vanaf weergawe 12.2 bied Oracle die vermoë om hierdie maatstaf te bereken en stel voor om die standaard DBMS_PLSQL_CODE_COVERAGE-pakket te gebruik.

   Ons outotoetsstelsel is net meer as 'n jaar oud en dit is dalk tyd om dekking te evalueer. In my laaste projek ('n projek nie deur Sportmaster nie), het dit gebeur. ’n Jaar nadat hulle aan outotoetse gewerk het, het die bestuur die taak gestel om te bepaal watter persentasie van die kode ons gedek het. Met meer as 1% dekking sal die bestuur gelukkig wees. Ons, die ontwikkelaars, het 'n resultaat van ongeveer 10% verwag. Ons het kodedekking opgeskroef, dit gemeet, 20% gekry. Om dit te vier, het ons vir die toekenning gegaan, maar hoe ons daarvoor gegaan het en waarheen ons later gegaan het, is 'n heel ander storie.

3. Outotoetse kan blootgestelde webdienste toets. Oracle laat jou toe om dit te doen, en ons sal nie meer 'n aantal probleme ondervind nie.
4. En natuurlik kan ons outomatiese toetsstelsel op 'n ander projek toegepas word. Die oplossing wat ons ontvang het, is universeel en vereis slegs die gebruik van Oracle. Ek het gehoor daar is 'n belangstelling in geoutomatiseerde toetsing op ander Sportmaster-projekte en miskien sal ons na hulle toe gaan.

Bevindinge

Kom ons hervat. Op die lojaliteitstelselprojek in Sportmaster het ons daarin geslaag om 'n outomatiese toetsstelsel te implementeer. Die basis daarvan is die utPLSQL-oplossing van Stephen Feuerstein. Rondom utPLSQL is die kode vir outotoetse en selfgeskrewe hulpmodules: 'n lanseerder, 'n datagenereringsmodule en ander. Outotoetse word daagliks uitgevoer en, die belangrikste, werk en voordeel. Ons is oortuig daarvan dat ons sagteware van hoër gehalte begin vrystel het. Terselfdertyd is die gevolglike oplossing universeel en kan dit vrylik toegepas word op enige projek waar dit nodig is om outomatiese toetsing op die Oracle DBMS te organiseer.

NS Hierdie artikel blyk nie baie spesifiek te wees nie: daar is baie teks en feitlik geen tegniese voorbeelde nie. As die onderwerp wêreldwyd interessant is, dan is ons gereed om dit voort te sit en terug te keer met 'n voortsetting, waar ons jou sal vertel wat die afgelope ses maande verander het en kodevoorbeelde sal gee.

Skryf opmerkings as daar punte is wat in die toekoms beklemtoon moet word, of vrae wat openbaarmaking vereis.

Slegs geregistreerde gebruikers kan aan die opname deelneem. Meld aan, asseblief.

Sal ons meer hieroor skryf?

• Ja natuurlik

• Nee dankie

12 gebruikers het gestem. 4 gebruikers het buite stemming gebly.

Bron: will.com