key successful unit testing how developers test their own code
Provadors de Black Box no us preocupeu per les proves unitàries. El seu objectiu principal és validar l'aplicació en funció dels requisits sense entrar en els detalls de la implementació.
Però com a curiositat o Pensant fora de caixa , us heu preguntat mai com proven els desenvolupadors el seu codi? Quin mètode utilitzen per provar abans de publicar codi per provar-los? Com és important la prova de desenvolupadors en un procés àgil? La resposta a tot això és la prova unitària. Vull informar-vos sobre la importància de les proves unitàries perquè els equips de desenvolupament i proves puguin treballar més col·laborativament per dissenyar, provar i llançar una aplicació excel·lent.
Qui sap que en el futur alguns de vosaltres fins i tot podreu canviar a la prova de caixes blanques i utilitzar aquestes tècniques de validació i millora de codi!
Què aprendreu:
Què és la prova unitària?
La prova unitària no és un concepte nou. Hi ha estat des dels primers dies de programació. Normalment, desenvolupadors i, de vegades Provadors de caixes blanques escriviu Proves unitàries per millorar la qualitat del codi verificant totes les unitats del codi que s’utilitzen per implementar requisits funcionals (també conegut com TDD Development Drove Development o Test-First Development).
La majoria de nosaltres podríem conèixer la definició clàssica:
'La prova unitària és el mètode de verificació de la peça més petita de codi que es pot provar en funció del seu propòsit'. Si el propòsit o el requisit ha fallat, la prova unitària ha fallat.
En paraules simples, significa escriure un fragment de codi (prova unitària) per verificar el codi (unitat) escrit per complir els requisits d’implementació.
Proves d’unitats en SDLC
A les proves d’unitats, els desenvolupadors utilitzen proves manuals o automàtiques per assegurar-se que cada unitat del programari compleix els requisits del client. Aquesta unitat pot ser una funció, objecte, mètode, procediment o mòdul individual del programari que es prova.
Escriure proves d’unitats per provar les unitats individuals facilita l’escriptura de proves exhaustives a mesura que es combinen totes les unitats. Durant el desenvolupament de programari, es fa com a primer nivell de proves.
Importància de les proves de la unitat d’escriptura
La prova unitària s’utilitza per dissenyar components de programari robusts que ajuden a mantenir el codi i eliminar els problemes de les unitats de codi. Tots sabem la importància de trobar i corregir defectes en la fase inicial del cicle de desenvolupament de programari. Aquestes proves tenen el mateix propòsit.
És una part integral del procés àgil de desenvolupament de programari. Quan s'ha d'executar un conjunt de proves d'unitat d'execució nocturna i s'ha de generar un informe. Si alguna de les proves unitàries ha fallat, l'equip de control de qualitat no hauria d'acceptar aquesta compilació per verificar-la.
Si ho establim com un procés estàndard, es detectarien molts defectes en el cicle inicial de desenvolupament, cosa que estalvia molt de temps de proves.
Sé que a molts desenvolupadors els agrada escriure proves unitàries. Ignoren o escriuen casos de proves unitàries errònies a causa de la manca de serietat programada o programada (sí, escriuen proves unitàries buides, de manera que el 100% d’ells passen amb èxit ;-)). És important escriure bones proves unitàries o no escriure-les en absolut. És encara més important proporcionar-lo temps suficient i un entorn de suport per obtenir beneficis reals.
Mètodes de prova unitària
Es pot realitzar de dues maneres:
- Proves manuals
- Proves automatitzades
En Proves manuals , el provador executa manualment casos de prova sense utilitzar cap eina d'automatització. Aquí, cada etapa de la prova s’executa manualment. Les proves manuals són tedioses, especialment per a proves repetitives i que requereixen més esforç per crear i executar casos de prova. Les proves manuals no requereixen coneixement de cap eina de prova.
És cert que el 100% de l’automatització no és possible i, per tant, sempre hi haurà algun nivell de proves manuals.
En Proves automatitzades, s’utilitzen eines d’automatització de proves de programari per automatitzar les proves / casos de proves. L'eina d'automatització pot enregistrar i desar la prova i es pot reproduir tantes vegades com calgui sense cap intervenció humana.
Aquestes eines poden fins i tot introduir dades de prova al sistema que s’està provant, així com comparar els resultats esperats amb els resultats reals i generar automàticament els informes. Tot i això, el cost inicial de configurar eines d’automatització de proves és elevat.
Tècniques dins de la prova unitària
# 1) Prova de caixa blanca:
quins són els fonaments de la programació d’ordinadors
En les proves de caixa blanca, el provador coneix l'estructura interna del programari, inclòs el codi, i el pot provar en funció del disseny i dels requisits. Per tant, també es coneix com a proves de caixes blanques proves transparents .
# 2) Prova de caixa negra:
En les proves de caixa negra, el provador no coneix les estructures internes ni el codi del programari.
# 3) Prova de caixa grisa:
Això també es coneix com proves de tècniques semitransparents que significa, els provadors només en són conscients parcialment de l’estructura interna, les funcions i els dissenys juntament amb els requisits. La depuració es fa mitjançant l'entrada real del frontal per obtenir dades exactes al fons. Per tant, es considera la caixa grisa com una combinació de tècniques de prova de caixa negra i caixa blanca.
Les proves de caixes grises cobreixen els tipus de proves següents:
- Proves de matriu.
- Proves de patrons.
- Proves de patrons ortogonals.
- Proves de regressió.
Avantatges de les proves unitàries
- El procés es torna àgil: Per afegir funcions o funcions noves al programari existent, hem de fer canvis al codi antic. Però canviar les coses pel codi ja provat pot ser arriscat i costós.
- La qualitat del codi millora: La qualitat del codi es millora automàticament quan es realitzen les proves d’unitats. Els errors identificats durant aquesta prova s’arreglen abans d’enviar-los a la fase de proves d’integració. Resulteu en un disseny i desenvolupament robustos, ja que els desenvolupadors escriuen casos de prova comprenent primer les especificacions.
- Detecta els errors abans d'hora: A mesura que els desenvolupadors realitzen proves unitàries, detecten errors al principi del cicle de vida del desenvolupament de programari i els resolen. Això inclou defectes o parts que falten a l'especificació, així com errors en la implementació del programador.
- Canvis més senzills i integracions simplificades: La realització de proves unitàries facilita que el desenvolupador reestructuri el codi, faci canvis i mantingui el codi. També facilita molt la prova del codi després de la integració. Solucionar un problema a la prova unitària pot solucionar molts altres problemes que es produeixen en fases posteriors de desenvolupament i prova
- Disponibilitat de documentació: Els desenvolupadors que estiguin estudiant la funcionalitat en una etapa posterior poden consultar la documentació de la prova d’unitat i poden trobar fàcilment la interfície de prova unitària i corregir-la o treballar-la de forma ràpida i senzilla.
- Procés de depuració fàcil: Ajuda a simplificar el procés de depuració. Si la prova falla en qualsevol etapa, s'ha de depurar el codi o bé es pot continuar el procés sense cap obstacle.
- Cost més baix: Quan es detecten i es resolen errors durant la prova unitària, es redueixen els costos i el temps de desenvolupament. Sense aquesta prova, si es detecten els mateixos errors en una fase posterior després de la integració del codi, es fa més difícil de rastrejar i resoldre, cosa que fa que sigui més costós i augmenti el temps de desenvolupament.
- La exhaustivitat del codi es pot demostrar mitjançant proves unitàries: Això és més útil en el procés àgil. Els provadors no aconsegueixen provar les versions funcionals fins que no s’acabi la integració. El compliment del codi no es pot justificar demostrant que heu escrit i comprovat el codi. Però l'execució de proves d'unitat pot demostrar que el codi és complet.
- Estalvia temps de desenvolupament: La finalització del codi pot trigar més temps, però a causa de menys errors a les proves del sistema i de l'acceptació, es pot estalviar temps de desenvolupament general.
- Cobertura del codi es pot mesurar
Cicle de proves unitàries
[imatge font ]
Què fa una bona prova unitària?
Bé, no sóc la persona adequada per dir què fa que sigui una bona prova unitària, però, basant-me en les meves observacions sobre diversos projectes, puc explicar les característiques d’una bona prova unitària. La prova unitària errònia no afegeix valor al projecte. En lloc d'això, el cost del projecte augmenta significativament escrivint i gestionant proves d'unitat incorrectes.
Com escriure bones proves d’unitat?
- S'ha d'escriure una prova d'unitat per verificar una sola unitat de codi i no la integració.
- Les proves d’unitats petites i aïllades amb noms clars facilitarien l’escriptura i el manteniment.
- Canviar una altra part del programari no hauria d’afectar la prova de la unitat si s’aïllen i s’escriuen per a una unitat de codi específica.
- Hauria d’executar-se ràpidament
- Una prova unitària hauria de ser reutilitzable
Marcs de proves unitàries
Els marcs de proves unitàries s’utilitzen principalment per ajudar a escriure proves unitàries de forma ràpida i senzilla. La majoria dels llenguatges de programació no admeten proves d’unitats amb el compilador incorporat. Es poden utilitzar eines comercials de codi obert i de tercers per fer les proves d’unitats encara més divertides.
Llista de populars Eines de proves unitàries per a diferents llenguatges de programació:
- Framework Java: JUnit
- Framework PHP - PHPUnit
- Estructures C ++: UnitTest ++ i Google C ++
- .NET Framework - NUnit
- Marc Python: py.test
Equívocs i veritats
- Es necessita més temps per escriure codi amb casos de prova d’unitat i no en tenim temps. En realitat, a la llarga estalviaria el temps de desenvolupament.
- La prova d’unitat trobarà tots els errors: no ho farà, ja que la intenció de la prova unitària no és trobar errors, sinó desenvolupar components de programari robusts que tinguin menys defectes en les etapes posteriors de SDLC.
- La cobertura del 100% del codi significa una cobertura del 100% de la prova: això no garanteix que el codi estigui lliure d’errors.
Com s'accepta la prova unitària?
Es poden realitzar bones proves d’unitats en 3 parts bàsiques.
- Escriviu el codi de la prova unitària
- Executeu el codi de prova unitària per comprovar si compleix els requisits del sistema
- Executeu el codi del programari per comprovar si hi ha defectes i si el codi compleix els requisits del sistema.
Després de realitzar els 3 passos anteriors, si sembla que el codi és correcte, es diu que s'ha aprovat la prova unitària. I si no compleix els requisits del sistema, la prova falla. En aquest cas, el desenvolupador ha de tornar a comprovar i corregir el codi.
En alguns casos, és necessari separar el codi per realitzar aquesta prova amb més precisió.
Millors pràctiques
Per crear el millor codi durant aquesta prova, tingueu en compte els punts següents:
- El codi ha de ser fort: Hi ha casos en què la prova falla o, en el pitjor dels casos, no s’executa en absolut si es trenca el codi.
- Comprensible i raonable: El codi ha de ser fàcil d’entendre. Això fa que el desenvolupador pugui escriure el codi fàcilment i fins i tot a la resta de desenvolupadors que treballin posteriorment en el codi serà més fàcil depurar-lo.
- Hauria de ser el cas únic: Les proves que defineixen diversos casos en un sol són complexes de treballar. Per tant, escriure un codi de cas únic és la millor pràctica, cosa que facilita la comprensió i la depuració del codi.
- Permet proves automàtiques: Els desenvolupadors s’han d’assegurar que la prova s’executa de forma automatitzada. Ha d’estar en un procés d’entrega o integració continu.
Altres punts a tenir en compte són els següents:
- En lloc de crear casos de prova per a totes les condicions, centreu-vos en la prova que afecta el comportament del sistema.
- Hi ha possibilitats que es repeteixi l’error a causa de la memòria cau del navegador.
- Els casos de prova no haurien de ser interdependents.
- Presteu atenció a la condició del bucle també.
- Planifiqueu els casos de prova amb més freqüència.
Conclusió
Les proves d’unitats apareixen quan s’exigeix provar cada funció per separat. És molt raonable detectar i corregir errors durant aquesta prova i estalviar temps i costos, en lloc de trobar-los en la fase posterior del desenvolupament de programari.
Tot i que ofereix molts avantatges, també hi ha limitacions a l’hora d’utilitzar-lo. Es requereix una rigorosa disciplina i coherència durant tot el procés de desenvolupament de programari per superar les limitacions i obtenir els beneficis previstos.
Els vostres comentaris són molt benvinguts.
Com a provador de caixes negres, quines observacions teniu sobre la prova unitària al vostre equip? Algú té una millor idea per a la prova unitària amb èxit?
Lectura recomanada
- Les diferències entre la prova unitària, la prova d’integració i la prova funcional
- 20 eines de prova d’unitat més populars el 2021
- Proves d’unitat d’escriptura amb Spock Framework
- Les millors eines de prova de programari 2021 [Eines d'automatització de proves de control de qualitat]
- Diferències clau entre la prova de caixa negra i la prova de caixa blanca
- Prova de càrrega amb tutorials HP LoadRunner
- Diferència entre la prova d'escriptori, el servidor de clients i la prova web
- Què és la prova de gamma? Fase de proves finals