Differences
This shows you the differences between two versions of the page.
|
tsc:laboratoare:laborator-10 [2024/02/29 14:40] 127.0.0.1 external edit |
tsc:laboratoare:laborator-10 [2025/05/17 13:33] (current) andrei.napruiu [2. Exercises ] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Laborator 10 - Static Checking ===== | + | ===== Laborator 10 - Static & Dynamic Checking ===== |
| Line 37: | Line 37: | ||
| Static checkerele reprezintă, pe scurt, următorul pas al verificării codului de către developer, înainte de rulare și de publicarea efectivă a codului. | Static checkerele reprezintă, pe scurt, următorul pas al verificării codului de către developer, înainte de rulare și de publicarea efectivă a codului. | ||
| + | |||
| + | === 1.3 Dynamic Checking === | ||
| + | |||
| + | Diferentța majoră între acest checking și cel anterior este timpul în care se fac verificările. Pentru Static Checking, uneltele principale de verificare sunt rulate înainte de a rula codul sursă. În cazul Dynamic Checking, sunt rulate odată cu codul sursă. De aceea, și din laboratoarele trecute, putem identifica câteva forme de Dynamic Checking, precum: Testarea Unitară, Testarea de Integrare, Fuzz Testing, etc.. | ||
| + | |||
| + | Verificările dinamice rulează efectiv codul și observă comportamentul la execuție. Ele surprind erori de logică, condiții de margine și probleme de integrare care scapă analizei statice. | ||
| + | |||
| + | === 1.4 Static vs Dynamic === | ||
| + | |||
| + | ^ Caracteristică ^ Static Checking ^ Dynamic Testing ^ | ||
| + | | Momentul analizei | Înainte de execuție | În timpul rulării testelor sau în mediul de dev | | ||
| + | | Detectează | Erori de stil, tipuri, vulnerabilități de securitate| Erori de logică, edge cases, probleme de integrare | | ||
| + | | Exemplu de problemă | String concatenat cu int, importuri inutile| Funcție care aruncă excepție pentru input neprevăzut | | ||
| + | | Viteză | Rapid (nu rulează codul) | Mai lent (rulează efectiv cod) | | ||
| + | | Acoperire | Nu poate evalua toate căile de execuție | Poate acoperi doar căile pentru care există teste | | ||
| + | | Cost de scriere dat de | Configurare inițială și tunare a regulilor | Scriere de teste și date de testare | | ||
| ==== 2. Exercises ==== | ==== 2. Exercises ==== | ||
| În exercițiile din laborator vom explora cinci unelte de linting și static checking. | În exercițiile din laborator vom explora cinci unelte de linting și static checking. | ||
| - | Pentru fiecare va trebui să o rulați, să rezolvați (pe cât se poate) problemele semnalate, și să realizați un commit descriptiv în legătură cu schimbările. | + | Pentru fiecare va trebui să o rulați și să rezolvați (pe cât se poate) problemele semnalate. |
| - | Vom folosi un [[https://github.com/Ingineria-Calculatoarelor-ACS-UPB/python-mini-project.git|repository]] open source pentru a rula exercițiile. | + | Vom folosi un [[https://github.com/cs-pub-ro/systems-testing/tree/lab10/laboratories/static%26dynamic%20checking/python-mini-projects|repository]] open source pentru a rula exercițiile. |
| - | Din acesta va trebui să alegeți 2-3 mini-proiecte pe care să rulați uneltele și să rezolvați problemele. | + | Din acesta va trebui să alegeți 1-2 mini-proiecte pe care să rulați uneltele și să rezolvați problemele. |
| Dacă proiectul ales nu mai are destule probleme pentru a fi util, sau ați rezolvat deja toate problemele, puteți încerca altul. | Dacă proiectul ales nu mai are destule probleme pentru a fi util, sau ați rezolvat deja toate problemele, puteți încerca altul. | ||
| Line 58: | Line 74: | ||
| <code teraterm> | <code teraterm> | ||
| $ pip3 install pylint ruff black bandit pytype | $ pip3 install pylint ruff black bandit pytype | ||
| + | </code> | ||
| + | |||
| + | <code teraterm> | ||
| + | $ pip3 install pytest typeguard coverage hypothesis atheris | ||
| </code> | </code> | ||
| Line 82: | Line 102: | ||
| 1. Rulați Pylint și observați problemele semnalate de acesta. | 1. Rulați Pylint și observați problemele semnalate de acesta. | ||
| 2. Rezolvați problemele semnalate pentru proiectul ales. | 2. Rezolvați problemele semnalate pentru proiectul ales. | ||
| - | 3. Realizați un commit prin care să salvați modificările aduse. | ||
| === 2.2 Ruff - Advanced Checks === | === 2.2 Ruff - Advanced Checks === | ||
| Line 95: | Line 114: | ||
| 1. Rulați Ruff și observați problemele semnalate de acesta. | 1. Rulați Ruff și observați problemele semnalate de acesta. | ||
| 2. Rezolvați problemele semnalate pentru proiectul ales. | 2. Rezolvați problemele semnalate pentru proiectul ales. | ||
| - | 3. Realizați un commit prin care să salvați modificările aduse. | ||
| === 2.3 Black - Automatic Checks === | === 2.3 Black - Automatic Checks === | ||
| Line 111: | Line 129: | ||
| 2. Rulați Black fără argumente adiționale pentru a aplica schimbările. | 2. Rulați Black fără argumente adiționale pentru a aplica schimbările. | ||
| 3. Rezolvați problemele rămase semnalate pentru proiectul ales (dacă mai există). | 3. Rezolvați problemele rămase semnalate pentru proiectul ales (dacă mai există). | ||
| - | 4. Realizați un commit prin care să salvați modificările aduse. | ||
| === 2.4 Bandit - Security Checks === | === 2.4 Bandit - Security Checks === | ||
| Line 126: | Line 143: | ||
| 1. Rulați Bandit și observați problemele. | 1. Rulați Bandit și observați problemele. | ||
| 2. Rezolvați problemele semnalate pentru proiectul ales. | 2. Rezolvați problemele semnalate pentru proiectul ales. | ||
| - | 3. Realizați un commit prin care să salvați modificările aduse. | ||
| === 2.5 Pytype - Type Checks === | === 2.5 Pytype - Type Checks === | ||
| Line 144: | Line 160: | ||
| 1. Rulați Pytype și observați problemele. | 1. Rulați Pytype și observați problemele. | ||
| 2. Rezolvați problemele semnalate pentru proiectul ales (dacă există). | 2. Rezolvați problemele semnalate pentru proiectul ales (dacă există). | ||
| - | 3. Realizați un commit prin care să salvați modificările aduse. | ||
| - | ==== 3. Bonus ==== | + | === 2.6 Coverage Reports === |
| - | Pentru a realiza bonusul va trebui să creăm și un fork în care să adăugăm pipeline-urile: | + | Coverage este un tool testare al acoperirii testelor unitare și de integrare în cadrul codului vostru. De aceea, pentru a rezolva acest exercițiu, recomandăm reamintirea conceptelor de Teste Unitare. |
| + | Printr-un raport ușor de descifrat, vă arată destul de clar unde sunt lipsuri și ce puteți îmbunătăți. | ||
| - | {{:tsc:laboratoare:ic_lab10_bonus_fork.png?400|}} | + | Rulând comanda: |
| + | |||
| + | <code teraterm> | ||
| + | $ coverage run -m pytest | ||
| + | $ coverage report | ||
| + | </code> | ||
| + | |||
| + | pe orice proiect în Pyhton care deține o suită de teste unitare sau de integrare, veți putea obține raportul care poate fi deschis și accesând fișierele noi generate. | ||
| + | |||
| + | {{:tsc:laboratoare:coverage-report-lab10.png?400|}} | ||
| + | |||
| + | {{:tsc:laboratoare:python-coverage-lab10.png?400|}} | ||
| + | |||
| + | |||
| + | 1. Rulați Coverage și observați problemele. | ||
| + | 2. Încercați să creșteți test coverage-ul prin mai multe teste unitare. | ||
| + | |||
| + | === 2.7 Typeguard Assertions === | ||
| + | |||
| + | Typeguard Assertions este un tip de verificare al tipurilor odată cu rularea codului sursă. Este un tip de dynamic checking ce ajută la observarea problemelor de tip ce nu pot fi identificate fără a interpreta codul. | ||
| + | |||
| + | În fișierul vostru Python, importați și aplicați decoratorul @typechecked pe funcțiile critice: | ||
| + | |||
| + | <code teraterm> | ||
| + | from typeguard import typechecked | ||
| + | |||
| + | @typechecked | ||
| + | def process_data(data: dict, limit: int) -> list: | ||
| + | assert limit > 0, "Limit trebuie să fie pozitiv" | ||
| + | # … restul implementării … | ||
| + | return result_list | ||
| + | </code> | ||
| + | |||
| + | Apoi rulați: | ||
| + | <code teraterm> | ||
| + | $ pytest --typeguard-packages=. | ||
| + | </code> | ||
| + | |||
| + | 1. Rulați Typeguard și observați problemele. | ||
| + | 2. Rezolvați problemele semnalate pentru proiectul ales (dacă există). | ||
| - | === 3.1 CI Pipeline === | + | === 3.0 CI Pipeline === |
| - | În fork-ul realizat în partea de setup, adăugați un fișier **python-checks.yaml** în calea **.github/workflows** și completați conform specificației următoare: | + | Creați un fișier **python-checks.yaml** în calea **.github/workflows** și completați conform specificației următoare: |
| * Verificarea trebuie să se realizeze pe tot codul. | * Verificarea trebuie să se realizeze pe tot codul. | ||
| * Verificarea trebuie sa pornească atunci când este deschis un nou Pull Request. | * Verificarea trebuie sa pornească atunci când este deschis un nou Pull Request. | ||
| Line 162: | Line 217: | ||
| Aveți grijă să rulați uneltele în mod neinteractiv (dacă este disponibil), și să verificați codurile de eroare întoarse de acestea. | Aveți grijă să rulați uneltele în mod neinteractiv (dacă este disponibil), și să verificați codurile de eroare întoarse de acestea. | ||
| + | |||
| + | === 3.1 Bonus === | ||
| + | |||
| + | Încercați să rulați workflow-ul pe un fork al proiectului actual. | ||
| + | |||
| + | {{:tsc:laboratoare:ic_lab10_bonus_fork.png?400|}} | ||
| ==== 4. Resources ==== | ==== 4. Resources ==== | ||
| Line 171: | Line 232: | ||
| * https://github.com/charliermarsh/ruff | * https://github.com/charliermarsh/ruff | ||
| * https://github.com/PyCQA/pylint | * https://github.com/PyCQA/pylint | ||
| - | * {{:tsc:laboratoare:ic_lab10_demo_everynoise.zip}} | ||
| - | |||
