Test du programme C++ avec des classes de test sur des classes normalement utilisées

Ce sera probablement un bot d'une question dérangeante, mais je ferai de mon mieux. J'ai un simple programme C++ dont j'ai besoin de construire des tests. J'ai 2 Classes que j'utilise en plus de celles que j'utilise, elles s'appellent WebServer et BusinessLogicLayer.Test du programme C++ avec des classes de test sur des classes normalement utilisées

Pour tester mon propre code, j'ai créé mes propres versions de ces classes qui alimentent les données factices de ma classe pour tester sa fonctionnalité.

J'ai besoin de savoir d'une manière ou d'une autre, via un makefile par exemple, comment dire au code source d'utiliser les classes de test sur les classes normalement utilisées. Les classes de test se trouvent dans un fichier C++ "testeur" différent, et le fichier C++ du testeur a également son propre fichier d'en-tête.

Cordialement

Paul

post-scriptum C'est probablement une question mal formulée, mais je ne sais pas de meilleure façon de poser ma question.

Source

2010-04-07 paultop6

Vous pouvez définir des classes de base abstraites qui déclarent les interfaces publiques pour vos composants, puis connecter les objets au moment de l'exécution (en main() ou autre chose assez haut dans la chaîne alimentaire). Lors des tests, vous devez simplement câbler différents objets.

Source

2010-04-07 12:01:36

objets "Câblage" différents à l'exécution n'est pas trivial. Il faudra recoder partout où WebServer ou BusinessLogicLayer sont construits sur la pile (ce que je reconnais ne devrait pas être beaucoup d'endroits pour ces classes). Si vous prenez la décision à un niveau élevé (par exemple dans main()), vous devez le transmettre aux classes qui en ont besoin. WebServer et BusinessLogicLayer peuvent être des choses que vous ne voulez pas avoir en même temps avec des versions réelles et bidon, ce qui signifie que vous "câlinez" des classes, pas des objets. Et si elles doivent être construites avant que main() ne s'exécute (par exemple des objets statiques) ... pas trivial. – Beta

Vous pouvez déclarer, par exemple, le serveur Web à l'aide d'une interface singleton. 'main()' est responsable de la création de l'instance de classe dérivée appropriée et de l'assignation en tant que singleton à renvoyer. Le code qui veut interagir avec le WebServer accède simplement à l'API singleton. C'est l'une des rares utilisations valables des singletons. –

Si WebServer et BusinessLogicLayer peuvent être des singletons, vous pouvez vous en sortir. Mais alors vous ne devez avoir aucun membre statique initialisé pour pointer ou se référer à eux (ce qui serait une chose naturelle à faire) * maintenant ou dans les futures révisions du code *. Aussi, toute personne qui veut construire une version de travail doit avoir le code de test aussi, sinon la liaison échouera.Et cette méthode n'est pas extensible à vos autres classes non-singleton. – Beta

Pour construire le débogage et publier des versions d'un programme avec le code source dans les répertoires $ {SRC_DIR_1} et {SRC_DIR_2} $:

CXX  := g++ 
CPPFLAGS = ... 
CXXFLAGS = ... 

SRC_DIR_1 := ... 
SRC_DIR_2 := ... 

ifeq (${debug},1) 
    BIN_DIR := ./obj_debug 
    CXXFLAGS += -g 
else 
    BIN_DIR := ./obj_release 
    CXXFLAGS += -DNDEBUG 
endif 

# Make sure that the directory exists. 
TEMP := ${shell test -d ${BIN_DIR} || mkdir ${BIN_DIR}} 

# Tell make to search each directory 
VPATH := ${SRC_DIR_1}:${SRC_DIR_2} 

# You can modify this to use a suffix other than .cc 
${BIN_DIR}/%.o : %.cc 
    ${CXX} ${CPPFLAGS} ${CXXFLAGS} -c $< -o [email protected] 

# Build the requested version of the program. 
ifeq (${debug},1) 
    default: program_name_debug 
else 
    default: program_name 
endif 

tidy:: 
    @${RM} -r ./obj_*

Dans la boîte de dialogue de configuration du projet, indiquez le nom de la cible sous « program_name, program_name_debug ". (Remplacer program_name avec le nom de votre programme.)

Pour construire le programme, appelez "faire debug = X" avec X remplacé par 0 ou 1.

Reference

Source

2010-04-07 14:01:13 anijhaw

Pourquoi votre code testeur avoir un fichier d'en-tête de son propre chef? Votre code de test devrait avoir la même interface que le code qu'il émule, et l'utilisation du même fichier d'en-tête évite beaucoup de maux de tête.

Quoi qu'il en soit, cela fonctionne:

real_program: WebServer.o BusinessLogicLayer.o 

test_program: tester.o 

real_program test_program: MyClass.o OtherThings.o 
    $(LINK) $^ -o [email protected]

Source

2010-04-07 14:31:19 Beta

Test du programme C++ avec des classes de test sur des classes normalement utilisées

Répondre

Questions connexes