====== Integration Continue (Jenkins) ======

Jenkins est un lanceur de tache.\\
Il permet notamment de lancer une build C++ ou java.\\

===== Installation de Jenkins =====
  * Telecharger le sur [[https://jenkins-ci.org/]] et cliquer sur le native packages (windows par exemple)
  * Ceci télécharge un installeur, il vous faut l'installer
  * Jenkins sera disponible par défaut sur localhost:8080
  * {{:san.integration:jenkins.jpg?200|}}
  * Vous pouvez (devez) installer des plugins dans "Administrer Jenkins" puis "Gestion des plugins", onglet Disponibles
  * Ajoutez le "safeRestart Plugin" pour redémarrer facilement
  * Ajoutez le "xUnit Plugin" pour afficher les rapports de cppUnit
  * Ajoutez le "Git Plugin" pour gérer git
  * http://localhost:8080/safeRestart pour redémarrer
  * http://localhost:8080/safeExit pour arréter

===== cppUnit like =====

  * [[https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B|Wikipédia liste des frameworks de tests]]
  * [[http://stackoverflow.com/questions/242926/comparison-of-c-unit-test-frameworks]]
  * [[http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle]] cppunit like tests -> boost.test CppUnitLite
  * [[http://accu.org/index.php/journals/1326]] There are many Unit Testing frameworks for C++, but which one to use? 
  * Test Driven Development Book
  * UnitTest++  [[https://github.com/unittest-cpp/unittest-cpp]]
  * xUnit++ [[https://bitbucket.org/moswald/xunit/wiki/Home]]
  * [[https://en.wikipedia.org/wiki/XUnit|xUnit format]]
  * [[https://en.wikipedia.org/wiki/Google_Test|Google Test]] [[https://blog.jetbrains.com/rscpp/unit-testing-google-test/]]
  * [[http://www.jmdoudoux.fr/java/dej/chap-frameworks-test.htm]]

===== google test =====
  * Télécharger le zip sur [[https://github.com/google/googletest]]
  * Dans le repertoire msvc, cliquer sur le gtest.sln pour générer les librairies gtest.lib et gtestd.lib en Release et Debug ( convertir le projet avant comme demandé par visual )


===== Qt test lib =====
  * [[http://doc.qt.io/qt-5/qtest-tutorial.html]]

<cmd>
#include <QtTest/QtTest>

class TestQString: public QObject
{
    Q_OBJECT
private slots:
    void toUpper();
    
    void myFirstBenchmark()
    {
        QString string1;
        QString string2;
        QBENCHMARK {   --> utilisation de QBENCHMARK
            string1.localeAwareCompare(string2);
        }
    }
};


void TestQString::toUpper()
{
    QString str = "Hello";
    QVERIFY(str.toUpper() == "HELLO");
    --> ou plus verbeux: QCOMPARE(str.toUpper(), QString("HELLO"));
}

QTEST_MAIN(TestQString)
#include "testqstring.moc" 

</cmd>

  * execution du programme de tests:  TitanUnitTest -xml > resultat.qt.xml
  * Plusieurs fois le meme tests avec des jeux de données différents _data
<cmd>
class TestQString: public QObject
{
    Q_OBJECT

private slots:
    void toUpper_data();
    void toUpper();
};

void TestQString::toUpper_data()
{
    QTest::addColumn<QString>("string");
    QTest::addColumn<QString>("result");

    QTest::newRow("all lower") << "hello" << "HELLO";
    QTest::newRow("mixed")     << "Hello" << "HELLO";
    QTest::newRow("all upper") << "HELLO" << "HELLO";
}

void TestQString::toUpper()
{
    QFETCH(QString, string);
    QFETCH(QString, result);

    QCOMPARE(string.toUpper(), result);
}

index	name	string	result
0	all lower	"hello"	HELLO
1	mixed	        "Hello"	HELLO
2	all upper	"HELLO"	HELLO
</cmd>

[[http://doc.qt.io/qt-5/qttestlib-tutorial3-example.html]]
<cmd>
#include <QtWidgets>
#include <QtTest/QtTest>

class TestGui: public QObject
{
    Q_OBJECT

private slots:
    void testGui();

};

void TestGui::testGui()
{
    QLineEdit lineEdit;

    QTest::keyClicks(&lineEdit, "hello world");

    QCOMPARE(lineEdit.text(), QString("hello world"));
}
</cmd>

QTestLib gére les evenements graphiques

Trucs pour écrire des tests qt: QCOMPARE, QVERIFY2, QTRY_COMPARE, etc...\\
[[https://wiki.qt.io/Writing_Unit_Tests]]
===== Les types de tests =====

Selon google:
  * Small Tests (Unit Tests)\\
Small tests are mostly (but not always) automated and exercise the code within a single function or module. The focus is on typical functional issues, data corruption, error conditions, and off-by-one mistakes. Small tests are of short duration, usually running in seconds or less. They are most likely written by a Software Engineer (SWE), less often by an Software Engineer in Test (SET), and hardly ever by a Test Engineer (TE). [8] Small tests generally require sample environments to run and be tested in. Software developers rarely write small tests but might run them when they are trying to diagnose a particular failure. The question a small test attempts to answer is, “Does this code do what it is supposed to do?” [9]

  * Medium Tests (Integration Tests)\\
Medium tests are usually automated and involve two or more interacting features. The focus is on testing the interaction between features that call each other or interact directly. [10] Software engineers drive the development of these tests early in the product cycle as individual features are completed and developers are heavily involved in writing, debugging, and maintaining the actual tests. If a medium test fails or breaks, the developer takes care of it autonomously. The question a medium test attempts to answer is, “Does a set of near adjacent functions operate with each other the way they are supposed to?” [11]

  * Large Tests (Acceptance Tests)\\
 Large tests cover three or more features and represent real user scenarios with real user data sources. There is some concern with overall integration of the features, but large tests tend to be more results-driven, checking that the software satisfies user needs. All three roles are involved in writing large tests and everything from automation to exploratory testing can be the vehicle to accomplish them. The question a large test attempts to answer is, “Does the product operate the way a user would expect and produce the desired results?”
===== Que choisir? =====

  * Pas trop unix -> on fait du windows (compilation cmake, ...)
  * Gérer les exceptions -> pour ne pas planter tous les tests
  * Doit produire du format xUnit -> C'est la seule chose à peu près commune et cela permet d'afficher les résultats dans Jenkins
  * Ecriture simple des tests (pas trop verbeux) -> défaut de cppunit
  * On parle de jungle des cpp units -> Pas de grand vainqueur
  * Faire attention aux projets morts -> Peu survive avec le temps
  * Doit fonctionner avec Visual Studio 2010 et pas seulement 2012 ou 2015...
  * Avoir de la doc et des exemples si possible
  * Capacité de jouer tous les tests ou que certains
  * Possibilité d'avoir des tests avec ou sans arrêt définitif
  * Des noms reviennent plus souvent: cppUnit ( le 1er), Boost.test, Google Test 
  * Probleme potentiels: les rapports avec des dates