Baze de date embedded – exercitiu practic (pentru programatori mid-level)

jegmihai, on 07 octombrie 2018 - 08:43, said:

Scopul unei suite de teste nu e test coverage de 100%.

Unul dintre scopuri este identificarea părții din cod care crează probleme.

Exemplu, pentru feature "adăugare contact" ai o serie de teste:

1. Unul sau câteva acceptance tests. Acestea testează toată aplicația prin exersarea UI, simularea de clicuri și de apăsări de taste.
Când aceste teste trec, îi spui lui PO că e gata feature. Te ajută să păstrezi direcția generală atunci când dezvolți.

2. Teste de integrare a diferitelor layere/plugins, în diferite combinații. Un test ar fi faptul că apelarea lui addContact într-adevăr crează o intrare în baza de date. Ușor de făcut in-memory cu sqlite.

3. Unit tests. Acestea testează metodele publice.


Dacă testul din 1 eșuează, el îți spune ceea ce ți-ar spune utilizatorul că nu e în ordine, dar nu îți spune tehnic ce e greșit : clicul nu a funcționat, datele nu au fost validate de domeniu, baza de date nu are o intrare, etc - știi doar la nivel abstract ce feature nu funcționează.

Dar testele 2 și 3 te ajută să identifici exact partea de cod vinovată. Deduci asta din constelația de teste roșii.


Problema e următoare : integrările dintre componente tind să fie testate cu mocks. Însă dacă ai un pod clar în arhitectură clar, îl poți folosi pe el în loc de mock, adică într-adevăr testezi punctul de integrare, fără a te baza pe "inside knowledge" prea mult.

"mai testabil" în acest context înseamnă "suită de teste mai robustă, mai de încredere".

Observer pattern descrisă anterior ar fi un astfel de pod în arhitectură.

Nu e ca și cum asta ar fi marea salvare, e unul dintre pașii mici pe care îi poți face. Există numeroase abordări, unele în alte direcții, toate bune.

Ceea ce vrei e o direcție coerentă, consistentă cu sine însăși, nu să umbli în zigzag.

E abstract ce zic, dar cel mai eficient e dacă mă exprim în metafore.

Cât de abstractă trebuie să fie interfața IObserver?

Eu am gândit-o așa, dar nu mă ajută foarte mult.

class IObserver
{
public:
	virtual ~IObserver() = default;
	virtual void update() = 0;
};

Nu mă ajută în sensul că pot exista 3 moduri diferite prin care state-ul poate fi schimbat, și nu doar una.

Din păcate timpul nu îmi mai permite să lucrez atât de des la proiect.