Discussion :

[vdaanen]

Bonjour,

j'ai un petit souci de comprehension des fixtures de tests unitaires.
D'apres ce que je comprends, quand on déclare une testsuite avec une fixture, la fixture est partagée par tous les tests-cases.

ce qui m'etonne c'est que si je fais ce qui est ci-dessous, le test échoue. On dirait que la fixture est recréée a chaque fois !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
typedef struct SFixture
{
	SFixture()
	{	m_i=0;};
 
	virtual ~SFixture()
	{	};
 
	int m_i;
}
 
BOOST_FIXTURE_TEST_SUITE (TestSuite_1, SFixture)
 
BOOST_AUTO_TEST_CASE( TestCase_1_1 )
{
	BOOST_CHECK(m_i==0);
	m_i=1;
}
 
BOOST_AUTO_TEST_CASE( TestCase_1_2 )
{
	BOOST_CHECK(m_i==1);
}
BOOST_AUTO_TEST_SUITE_END()

Comment peut-on faire pour modifier une fixture et garder les modifs tout au long d'une test suite ?

Concretement, je veux faire ceci:
- testcase_1 : demander la création d'un composant
- testcase_2...n : tester les differents accesseurs Set/Get (un test case par Set/Get)
- testcase_n+1 : sauvegarder (avec toutes les modifs donc )
- testcase_n+2 : relire et comparer aux valeurs que j'ai donné via les Set

Comment dois-je m'y prendre ?

V

[vdaanen]

Slt,

personne n'a d'idée
bon, voila comment j'ai resolu mon pb. Sans doute pas la meilleure facon mais ca marche

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
BOOST_FIXTURE_TEST_SUITE (TestSuite_2, CFixture2)  // fixture test suite. fixture is not really useful here
 
//static variable -> scope seems to be the testsuite...
static CPbpPatientData s_PatientData_TestSuite2;
static std::vector<CString> s_IDsForTest_Guidance;
static std::vector<CString> s_IDsForTest_Biopsy;
 
// add test case here
BOOST_AUTO_TEST_CASE(TestCase_2_1)
{  //  
}
BOOST_AUTO_TEST_SUITE_END()

Si ca peut aider quelqu'un un jour .....

Et si c'est pas comme ca qu'il faut faire et que quelqu'un a une meilleure facon a proposer, qu'il ne se gene pas, je suis preneur ...

V

[Mat007]

Salut,

Comme tu t'en es aperçu BOOST_FIXTURE_TEST_SUITE permet simplement de positionner une même fixture pour une série de tests, c'est complément équivalent à lister la fixture pour chaque test avec un BOOST_FIXTURE_TEST_CASE.
Et donc ça ne permet pas de partager des données.

A mon avis dans ton cas tu ferais aussi bien de séparer tes tests et de ne pas réutiliser le même contexte d'exécution pour tous, c'est un des principes des tests unitaires : isoler chaque test des autres.
C'est tout de même beaucoup plus sûr et plus facile pour analyser les problèmes potentiels.

MAT.

[vdaanen]

Slt

Salut,
Comme tu t'en es aperçu BOOST_FIXTURE_TEST_SUITE permet simplement de positionner une même fixture pour une série de tests, c'est complément équivalent à lister la fixture pour chaque test avec un BOOST_FIXTURE_TEST_CASE.
Et donc ça ne permet pas de partager des données.

Dans ce cas, le terme 'shared' de la doc est trompeur ..

A mon avis dans ton cas tu ferais aussi bien de séparer tes tests et de ne pas réutiliser le même contexte d'exécution pour tous, c'est un des principes des tests unitaires : isoler chaque test des autres.
C'est tout de même beaucoup plus sûr et plus facile pour analyser les problèmes potentiels.

tu as raison mais d'un autre coté, le fait de partager ce composant me permet de faire les Set qu'une seule fois. La classe en question ayant un nombre de variable de classe assez important, ça me fait gagner du code (et donc du temps) de manière non négligeable.

Le besoin de composant partagé entre plusieurs tests est rare mais quand il est la, le contourner est vraiment tres galère...

V

[Mat007]

Dans ce cas, le terme 'shared' de la doc est trompeur ..

Un peu il est vrai... Il faut le voir comme permettant un partage de fixtures et non de données..

tu as raison mais d'un autre coté, le fait de partager ce composant me permet de faire les Set qu'une seule fois. La classe en question ayant un nombre de variable de classe assez important, ça me fait gagner du code (et donc du temps) de manière non négligeable.

Je suppose que ce ne sont pas juste des modificateurs/accesseurs basiques ?
Parce que tester que getTruc() renvoit bien ce qui a été passé au setTruc() ne serait pas très utile dans ce cas...

MAT.

[vdaanen]

Je suppose que ce ne sont pas juste des modificateurs/accesseurs basiques ?
Parce que tester que getTruc() renvoit bien ce qui a été passé au setTruc() ne serait pas très utile dans ce cas...
MAT.

Il m'est arrivé de mixer des technos et de ne pas avoir les resultats escomptés. Depuis qd il faut faire des Set pour tester la sauvegarde/lecture, je testes les Set/Get... Ca mange pas de pain, dans 99% des cas il n'y a pas de surprise et quand il y en a une ca evite un arrachage de cheveux

V