Tests unitaires - quelques problèmes liés à l'organisation du code dans les tests C++

Question

Je suis un programmeur C++ novice. J'ai utilisé JavaScript la plupart du temps. Maintenant, en raison de besoins de devoirs, j'écris un projet en C++. Je souhaite faire les tests moi-même, mais je ne connais rien aux tests. avant. Après avoir lu ceci, j'ai décidé d'utiliser le framework de test catch.

Lorsque j'écrivais un petit devoir C++ auparavant, soit j'ai cout<< directement dans la fonction principale, puis je l'ai supprimé avant la soumission, soit j'ai créé un nouveau fichier cpp, ajouté la fonction principale, puis renommé temporairement la fonction principale dans le projet. (En général, je change le nom de la fonction principale en main00 ou similaire), cliquez sur Exécuter dans XCode pour le tester temporairement, principalement pour tester l'incertitude à un certain endroit, puis le modifier une fois le test terminé. .

Mais je pense que les méthodes listées ci-dessus sont vraiment stupides et font rire tous les seniors.

Mon répertoire de projet ressemble maintenant à ceci (il s'agit d'un travail pour implémenter minisql en utilisant c++) :

Actuellement, chaque fichier n'a en réalité aucun contenu. Chaque dossier représente un module, et la relation entre chaque module est la suivante :

Je prévois d'écrire une partie et de tester une partie (par exemple, écrivez d'abord BufferManager). S'il n'y a aucun problème dans le test, continuez à écrire la partie suivante.

Je me pose donc désormais les questions suivantes concernant l'organisation des dossiers de tests :

Dois-je mettre les fichiers de test dans le répertoire de fichiers du module correspondant ? Ou existe-t-il un fichier de test séparé ?

Chaque module doit-il avoir un fichier de test distinct ?

De plus, j'ai découvert que si j'écris deux fichiers de test, même si je les commente #define CATCH_CONFIG_MAIN celui-ci ne peut toujours pas fonctionner normalement à moins que je commente tous les autres fichiers de test.

De plus, après avoir écrit le fichier d'entrée (il y a une fonction principale dans NewSQL.cpp), comment dois-je exécuter ces fichiers de test ? Est-ce que vous continuez à commenter et à décommenter....

J'ai l'impression que la question que j'ai posée est un peu trop stupide, mais je veux vraiment savoir comment rédiger et utiliser correctement le test. Je n'ai pas trouvé de réponse très ciblée sur Internet, alors je suis venu ici pour demander, merci~

(Si vous pensez que quelque chose n'est pas bien fait, veuillez le signaler et je le corrigerai sérieusement, mais s'il vous plaît, n'attaquez pas personnellement. Si votre réponse est très précieuse à titre de référence, je vous enverrai également un message privé pour vous demander si vous besoin d'un certain montant de rémunération enveloppe rouge, fête étudiante, Exprimez vos sentiments)

Portail de capture ci-joint : https://github.com/philsquare...

Answer 1

Dois-je mettre les fichiers de test dans le répertoire de fichiers du module correspondant ? Ou existe-t-il un fichier de test séparé ?

Chaque module doit-il avoir un fichier de test distinct ?

De plus, j'ai découvert que si j'écris deux fichiers de test, même si je commente #define
CATCH_CONFIG_MAIN, il ne peut toujours pas fonctionner normalement à moins que tous les autres fichiers de test ne soient commentés.

De plus, après avoir écrit le fichier d'entrée (il y a une fonction principale dans NewSQL.cpp), comment dois-je exécuter ces fichiers de test ? Est-ce que vous continuez à commenter et à décommenter....

Le code de test et le code de production sont séparés et liés dans la dénomination
Par exemple, la classe de test de la classe A s'appelle AUnitTest ou ATest ou AUT

Fichiers de test séparés pour chaque module

Le fichier de test possède son propre fichier d'entrée

La clé est la configuration du projet. Le projet de test dépend du code de production, et le code de production ne dépend pas du code de test.
Deux devraient être capables de produire deux programmes exécutables. Configurez le projet en fonction de ces objectifs