J'écris une classe C ++ pour envelopper des prises (je sais qu'il y a de bonnes bibliothèques pour cela - je roule la mienne pour la pratique):
class LibcWrapper {
public:
static int socket(int domain, int type, int protocol);
static int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
static int listen(int sockfd, int backlog);
static int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
static ssize_t write(int fd, const void *buf, size_t count);
static int close(int fd);
};
3 Réponses :
Je voudrais probablement se moquer de cela en travaillant à travers une interface de socket (c.-à-d. Classe de base) et en implémentant une version de test de cette classe de base.
Vous pouvez le faire quelques façons, par exemple, la chose la plus simple consiste à spécifier l'ensemble de l'API de prise entière en termes d'interface C ++. puis fournir un béton Mise en œuvre qui a fonctionné via la bibliothèque de sockets BSD par codage par rapport à l'interface, vous pouvez créer votre version de test pour faire ce que vous voulez. Cependant, nous peut clairement voir que ce premier passage est plutôt étrange. Nous enveloppons une bibliothèque entière, ce n'est pas vraiment une classe dans le sens qu'il décrit des objets. Vous préférez penser en termes de prises et de façons de fabriquer des prises. Ce serait plus orienté objet. Sur ces lignes, je séparerais la fonctionnalité ci-dessus en deux classes. pour une utilisation en direct: pour tester : et séparer les appels de la bibliothèque BSD dans ces deux classes distinctes ayant leurs propres responsabilités.
J'aime bien cette approche. Merci!
J'ai aussi utilisé cette technique. Méfiez-vous que Google Mock ne supporte pas assez de fonctions statiques moqueuses. La FAQ explique que vous devriez utiliser une interface avec des méthodes virtuelles que vous pouvez remplacer dans le Way de Google Mock habituel.
Merci! J'ai accepté l'exemple de Doug T simplement à cause de tout le détail qu'il a fourni, mais le vôtre obtient certainement le haut-vote pour le lien FAQ GoogleMock. :)
googleMock Cookbook suggère quelque chose de similiaire en vous.
@ Beduin: Faites cela une réponse et je vais le voter. :)
Je trouve, dernièrement, qu'il est souvent plus significatif et à la fois pour vérifier ces classes avec des tests d'intégration (?). Par exemple, vous pouvez facilement vérifier que votre emballage gère une réinitialisation de connexion en faisant pression sur un processus qui 1) se connecte à des prises brutes à votre emballage, en cours d'exécution dans le processus principal, puis 2) immédiatement segfault, ce qui entraîne une réinitialisation de la connexion.
@Andres: Je fais en fait un test fonctionnel pour vérifier le code qui utilise mes sockets, mais ce que j'essaie de tester ici, c'est si une unité de code (c.-à-d.
Network :: init () ) appelssocket () ,réseau :: écoute () appelsbind () etécoute () , et Donc, donc je pense que les tests d'unités sont appelés en plus d'un test fonctionnel.@Josh Glover Dans ce cas, je suis d'accord à 100%. :)
Au cas où tout le monde veut plus de plaisir: Stackoverflow.com/questions/5780747/...