Discussion :

[Chasseur d'étoiles]

Bonsoir
Je développe actuellement un serveur de jeu en C#. J'essaie actuellement de le rendre le plus testable unitairement que possible.

Pour l'instant, le pattern que j'ai commencé ressemble à ceci :

Une classe Server est instanciée:
- Sert à démarrer et à stopper le serveur

Elle instancie une classe d'instance ConnectionsManager
- Contiens une instance de la classe ConnectionsPool (en gros une classe de gestion de liste)
- Sert à accepter de façon asynchrone les connexions (TCPListener.BeginAcceptSocket)
- Lorsque un socket est accepté une instance une instance de la classe ClientConnection est créée et ajouté à la liste de ConnectionsPool

La classe Clientconnection :
- Responsable de recevoir les donnés via Socket.BeginReceive
- Lorsque tout est reçu une instance de la classe SocketHandler est créée (sert en gros à traiter le packet selon son ID)

Donc le schéma ressemble à ça:

Server -> ConnectionManager -> ConnectionsPool -> ClientConnection -> SocketHandler

La problématique : lorsque je suis dans le SocketHandler, comment je fais pour pouvoir affecter un autre joueur ? (par exemple une autre instance de Clientconnection dans ConnectionsPool puisque ça semble le plus simple à faire ici), ou même affecter le serveur lui même (comme fermer le serveur par exemple).

J'assume avoir trois choix :
- Passer les classes importances (Serveur + ConnectionsPool) en classe statique et les utiliser comme tel
- Passer les classes importances en singleton
- Injecter dans les constructeur les instances des classes importantes

Le but ici est de rendre le tout testable unitairement de façon pas trop compliqué tout en gardant un code clair et fonctionnel utilisant les "best practices".

J'ai eu une suggestion d'injecter des delegates, mais je ne suis pas exactement certain du résultat de la méthode (entres autres pour les tests).

Quel serait le meilleur choix d'architecture ici selon vous ?

Merci

[Kagozuma]

Bonjour,

Personnellement si c'est dans le but de pouvoir tester au mieux ton code, j’opterais pour la 3ème solution (passe en paramètre de l'instance).

Pourquoi cela ? Pour pouvoir faire proprement du mocking de tes "classes importantes". Pour chacune de tes classes créer une interface qui liste les méthodes/propriétés que cette classe expose dans le but d'être utilisées par des instances de d’autres classes.

Par exemple dans ton SocketHandler tu auras une référence vers une instance qui implémente l'interface IConnectionsPool (Interface pour ta classe ConnectionsPool) et qui sera passée en paramètre via le constructeur.

Ensuite dans le cadre de tests au lieu de passer une instance de ConnectionsPool, tu pourras passer une instance d'une autre classe implémentant l'interface IConnectionsPool. On appelle ça un mock, une classe qui a pour but de remplacer une autre lors de test (si on veut tester juste le parsage des données venant d'un socket, sans vouloir devoir mettre en place un socket). Cette classe a un comportement scénarisé ou par exemple log tous les appels qu'on lui soumet.

A toi de voir comment tu feras, mais je pense que le mocking est le plus intéressant, car la classe statique ou le singleton ne permette pas de faire ce genre de chose.

J'espère t'avoir aidé.

Vincent.

[Edit : http://jmdoudoux.developpez.com/cour...bjets-mock.php même si c'est à propos de Java ça marche pour C# aussi]
[Edit2 : http://bruno-orsier.developpez.com/mocks-arent-stubs/ avec un lien pour avoir les exemples Java en C# http://bruno-orsier.developpez.com/m...tubs-exemples/]