Testarea Unităților¶

Crearea unui test de unitate¶

Crearea unui test de unitate este ușoară - de obicei, veți face acest lucru doar prin crearea un singur fișier .cpp (fișierul .h nu este utilizat), și implementând toate metodele de testare sub formă de metode publice care returnează valori vide. Pentru demonstrație, vom folosi o clasă de test simplă pentru QgsRasterLayer, de-a lungul secțiunii care urmează. Prin convenție vom numi testul nostru cu același nume ca și clasa de testare, dar prefixat cu ‘Test’. Așa că testul va fi stocat într-un fișier denumit testqgsrasterlayer.cpp iar clasa în sine va fi TestQgsRasterLayer. În primul rând vom adăuga informațiile privind drepturile de autor:

/***************************************************************************
 testqgsvectorfilewriter.cpp
 --------------------------------------
  Date : Friday, Jan 27, 2015
  Copyright: (C) 2015 by Tim Sutton
  Email: [email protected]
 ***************************************************************************
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 ***************************************************************************/

În continuare vom folosi declarațiile de includere, necesare testelor pe care ne propunem să le rulăm. Există una specială, care ar trebui să existe pentru toate testele:

#include <QtTest/QtTest>

Mai departe, continuați implementarea normală a clasei, incluzând antetele de care aveți nevoie:

//Qt includes...
#include <QObject>
#include <QString>
#include <QObject>
#include <QApplication>
#include <QFileInfo>
#include <QDir>

//qgis includes...
#include <qgsrasterlayer.h>
#include <qgsrasterbandstats.h>
#include <qgsapplication.h>

Din moment ce combinăm atât declarația clasei cât și implementarea într-un singur fișier, urmează declarația clasei. Vom începe cu documentația doxygen. Fiecare caz de testare trebuie să fie documentat în mod corespunzător. Folosim directiva doxygen ingroup, astfel încât toate Unitățile de Testare apar ca module în documentația Doxygen generată. Urmează apoi o scurtă descriere a unității de testare, clasa trebuind să moștenească QObject și să includă macrocomanda Q_OBJECT.

/** \ingroup UnitTests
 * This is a unit test for the QgsRasterLayer class.
 */

class TestQgsRasterLayer: public QObject
{
    Q_OBJECT

Toate metodele noastre de testare sunt implementate ca sloturi private. Cadrul de lucru QtTest va apela succesiv fiecare metodă slot privată din clasa de test. Există patru metode ‘speciale’ care, dacă sunt implementate, vor fi apelate la începutul testului de unitate (initTestCase), și la sfârșitul testului unitate (cleanupTestCase). Înainte de apelarea fiecărei metode de testare va fi apelată metoda init(), iar după fiecare metodă de testare este apelată metoda cleanup(). Aceste metode sunt foarte utile întrucât vă permit alocarea și curățarea resurselor înainte de rularea fiecărui test, și a unității de testare în ansamblul său.

private slots:
  // will be called before the first testfunction is executed.
  void initTestCase();
  // will be called after the last testfunction was executed.
  void cleanupTestCase(){};
  // will be called before each testfunction is executed.
  void init(){};
  // will be called after every testfunction.
  void cleanup();

Apoi urmează metodele de testare, care nu ar trebui să preia parametri, dar ar trebui să se întoarcă valoarea vidă. Metodele vor fi apelate în ordinea declarației. Vom implementa două metode aici, care ilustrează două tipuri de teste. În primul caz, pentru a testa, în general, dacă diferitele părți ale clasei lucrează, vom folosi o abordare de testare funcțională. Încă o dată, programatorii extremi pledează pentru scrierea acestor teste înainte de implementarea clasei. Apoi, pe măsură ce lucrați la implementarea clasei dvs. rulați iterativ testele de unitate. Cât mai multe funcții de testare ar trebui să se finalizeze cu succes în timp ce implementarea clasei progresează, iar după ce întregul test de unitate se încheie corect, noua dvs. clasă este gata, dispunând de un mod repetabil de validare.

În mod normal, testele dumneavoastră de unitare vor acoperi doar API-ul public al clasei, nefiind necesară scrierea testelor pentru accesori şi mutatori. Dacă s-ar întâmpla ca un acccesor sau un mutator să nu funcționeze conform așteptărilor, veți implementa un test de regresie, pentru a verifica acest lucru (așa cum se poate vedea mai departe).

//
// Functional Testing
//

/** Check if a raster is valid. */
void isValid();

// more functional tests here ...

În continuare, vom implementa testele noastre de regresie. Implementarea acestora ar trebui să fie făcută în așa fel, încât să poată reproduce condițiile particulare ale oricărei erori. De exemplu, am primit recent un raport prin e-mail, în care se preciza că numărul de celule din rastere este întotdeauna mai mic cu 1, lucru care denatura toate statisticile pentru benzile raster. Am înregistrat eroarea (prin tichetul #832) și apoi am creat un test de regresie care replica defecțiunea, cu ajutorul unui set de date de test restrâns (un raster 10x10). Apoi am rulat testul, certificând veridicitatea informației (faptul că numărul de celule a fost de 99 în loc de 100). Am corectat eroarea, am rulat iarăși testul de unitate și trecând cu succes de testul de regresie. Am urcat în baza de cod testul de regresie, alături de codul corect. Ulterior, dacă cineva se va bloca la acest pas, vom putea identifica imediat porțiunea de cod care a regresat. În plus, pe viitor, chiar înainte de a înregistra modificările în baza codului principal, rulând aceste teste, ne vom asigura că schimbările aduse nu au efecte adverse neașteptate - cum ar fi întreruperea funcționalității existente.

Mai există un beneficiu al prezenței testelor de regresie - acestea pot aduce economie de timp. Dacă ați depanat vreodată o eroare care a implicat efectuarea de modificări în codul sursă, urmată de rularea aplicației și efectuarea unei serii de pași extrem de complicați pentru a reproduce problema, va fi imediat evident că simpla implementare a testului de regresie înainte de corectarea erorii permite automatizarea testării, ceea ce reprezintă o eliminare eficientă a defectelor.

Pentru a implementa testul de regresie, ar trebui să urmați convenția de denumire a regresiei<TicketID> pentru funcțiile de testare. În cazul în care nu există deja un tichet Redmine pentru regresie, ar trebui să creați mai întâi unul. Această abordare facilitează persoanei care rulează un test de regresie nereușit, obținerea de informații suplimentare.

//
// Regression Testing
//

/** This is our second test case...to check if a raster
 *  reports its dimensions properly. It is a regression test
 *  for ticket #832 which was fixed with change r7650.
 */
void regression832();

// more regression tests go here ...

În cele din urmă, în declarația clasei test puteți declara, în mod privat, datele membru și metodele ajutătoare de care ați putea avea nevoie în testele de unitate. În cazul nostru, vom declara un QgsRasterLayer * care poate fi folosit de către oricare dintre metodele noastre de testare. Stratul raster va fi creat în funcția initTestCase(), care este rulat înainte de oricare alte teste, iar apoi va fi distrus de către cleanupTestCase(), care se execută după toate testele. Prin declararea metodelor ajutătoare (care pot fi apelate prin diverse funcții de testare) în mod privat, vă veți asigura că nu vor fi apelate în mod automat de către executabilul QTest, care este creat în urma compilării testului nostru.

  private:
    // Here we have any data structures that may need to
    // be used in many test cases.
    QgsRasterLayer * mpLayer;
};

Astfel se termină declarația clasei noastre. Implementarea are loc pur și simplu, în partea de jos a fișierului. Mai întâi are loc inițializarea și curățarea funcțiilor:

void TestQgsRasterLayer::initTestCase()
{
  // init QGIS's paths - true means that all path will be inited from prefix
  QString qgisPath = QCoreApplication::applicationDirPath ();
  QgsApplication::setPrefixPath(qgisPath, TRUE);
#ifdef Q_OS_LINUX
  QgsApplication::setPkgDataPath(qgisPath + "/../share/qgis");
#endif
  //create some objects that will be used in all tests...

  std::cout << "PrefixPATH: " << QgsApplication::prefixPath().toLocal8Bit().data() << std::endl;
  std::cout << "PluginPATH: " << QgsApplication::pluginPath().toLocal8Bit().data() << std::endl;
  std::cout << "PkgData PATH: " << QgsApplication::pkgDataPath().toLocal8Bit().data() << std::endl;
  std::cout << "User DB PATH: " << QgsApplication::qgisUserDbFilePath().toLocal8Bit().data() << std::endl;

  //create a raster layer that will be used in all tests...
  QString myFileName (TEST_DATA_DIR); //defined in CmakeLists.txt
  myFileName = myFileName + QDir::separator() + "tenbytenraster.asc";
  QFileInfo myRasterFileInfo ( myFileName );
  mpLayer = new QgsRasterLayer ( myRasterFileInfo.filePath(),
  myRasterFileInfo.completeBaseName() );
}

void TestQgsRasterLayer::cleanupTestCase()
{
  delete mpLayer;
}

Funcția de inițializare de mai sus ilustrează câteva lucruri interesante.

1. Trebuie să setăm manual calea către datele aplicației QGIS, astfel încât resursele, cum ar fi srs.db, să poată fi găsite în mod corect.

2. În al doilea rând, acesta este un test dirijat cu ajutorul datelor, astfel încât trebuie să oferim o modalitate de a localiza, în mod generic, fișierul tenbytenraster.asc. Acest lucru a fost realizat prin utilizarea definiția de compilator TEST_DATA_PATH. Definiția este creată în fișierul de configurare CMakeLists.txt din <QGIS Source Root>/tests/CMakeLists.txt, fiind disponibilă pentru toate testele de unitate QGIS. Dacă aveți nevoie de date pentru testul dumneavoastră, urcați-le în <QGIS Source Root>/tests/testdata. Ar trebui să urcați aici doar seturi de date foarte mici. În cazul în care testul trebuie să modifice datele, ar trebui să faceți mai întâi o copie a acestora.

Qt oferă, de asemenea, alte câteva mecanisme interesante pentru testarea dirijată cu ajutorul datelor, așa că, dacă vă interesează să aflați mai multe despre acest subiect, consultați documentația Qt.

În continuare, haideți să ne uităm la testul nostru funcțional. Testul isValid() verifică dacă stratul raster a fost încărcat corect în initTestCase. QVERIFY este o macrocomandă Qt pe care o puteți utiliza pentru a evalua o condiție de testare. Qt prevede alte câteva macro-uri care se pot utiliza în testele dumneavoastră, printre care:

• QCOMPARE ( actual, expected )
• QEXPECT_FAIL ( dataIndex, comment, mode )
• QFAIL ( message )
• QFETCH ( type, name )
• QSKIP ( description, mode )
• QTEST ( actual, testElement )
• QTEST_APPLESS_MAIN ( TestClass )
• QTEST_MAIN ( TestClass )
• QTEST_NOOP_MAIN ()
• QVERIFY2 ( condition, message )
• QVERIFY ( condition )
• QWARN ( message )

Unele dintre aceste macro-uri sunt utile numai atunci când se utilizează cadrul de lucru Qt, pentru testarea cu ajutorul datelor (a se vedea documentația Qt, pentru mai multe detalii).

void TestQgsRasterLayer::isValid()
{
  QVERIFY ( mpLayer->isValid() );
}

În mod normal, testele funcționale ar putea acoperi toată gama de funcționalități a claselor dvs. API publice, acolo unde este fezabil. Testele funcționale fiind gata, ne putem uita la exemplul nostru de test de regresie.

Având în vedere că problema #832 raportează un număr eronat de celule, scrierea testului nostru constă pur și simplu în folosirea macrocomenzii QVERIFY, pentru a verifica dacă numărul de celule corespunde valorii așteptate:

void TestQgsRasterLayer::regression832()
{
  QVERIFY ( mpLayer->getRasterXDim() == 10 );
  QVERIFY ( mpLayer->getRasterYDim() == 10 );
  // regression check for ticket #832
  // note getRasterBandStats call is base 1
  QVERIFY ( mpLayer->getRasterBandStats(1).elementCountInt == 100 );
}

Având toate funcțiile de testare a unităților implementate, rămâne să adăugăm un ultim lucru clasei noastre de testare:

QTEST_MAIN(TestQgsRasterLayer)
#include "testqgsrasterlayer.moc"

Scopul acestor două linii este de a semnala compilatorului moc Qt că are de-a face cu un QtTest (acesta va genera o metodă principală, care, la rândul ei, va apela fiecare test funcțional. Ultima linie reprezintă definiția de includere pentru sursele generate de MOC. Ar trebui să înlocuiți ‘testqgsrasterlayer’ cu numele, scris cu litere mici, al clasei dvs.