Qu'est-ce que DevTest dans un client Minecraft ?

Qu'est-ce que DevTest dans Minecraft ?

DevTest est un module que vous trouverez parfois dans la liste des modules d'un client, sans description de fonction claire. Ce n'est ni une variante de KillAura, ni un aimbot déguisé : c'est un crochet laissé par les développeurs pour tester du code en cours de développement pendant la construction du client. Écrit pour les personnes qui distribuent le logiciel plutôt que pour les joueurs, DevTest n'a pas de comportement cohérent. Ce qu'il fait sur une version donnée dépend entièrement de ce que les développeurs déboguaient lors de sa dernière modification, et cela peut changer entre les versions, voire entre deux versions de la même version.

La plupart du temps, DevTest se contente d'occuper une place dans la liste des modules, sans rien faire ou en faisant quelque chose que personne n'a pris la peine d'étiqueter. C'est l'équivalent en programmation d'un commentaire "À supprimer avant la publication" qui a échappé au contrôle qualité.

Comment fonctionne DevTest ?

DevTest n'a pas de fonction fixe visible pour le joueur, car ce n'était pas le but recherché. Les développeurs connectent le module à ce sur quoi ils travaillent actuellement : un nouveau chemin de rendu, un gestionnaire de paquets, du code de mouvement, ou simplement un espace de travail pour confirmer qu'un élément fonctionne sans planter le client.

C'est aussi pour cette raison qu'il a tendance à être livré avec un code obsolète. Pas de paramètres, de description vide, ou de texte de remplacement là où un module réel devrait s'expliquer. L'activer sur une version de publication ne fait rien du tout. Il peut également exécuter tout le code de test que les développeurs ont oublié de supprimer avant la livraison.

Les développeurs clients s'appuient sur un emplacement de module comme celui-ci, car une grande partie de ce qu'ils testent ne fonctionne correctement que contre un serveur réel, et non une sandbox. Un interrupteur rapide et facile à activer/désactiver dans le client en cours d'exécution est préférable à la création d'une version distincte pour chaque expérience. Lors de la livraison du client, l'emplacement reste parfois dans la liste simplement parce que le supprimer représente un travail supplémentaire, ou parce que l'équipe prévoit de le réutiliser lors du prochain cycle de développement.

Pourquoi cela existe-t-il ?

La plupart des travaux côté client se font contre des serveurs réels. Tester un nouveau module de mouvement ou un hook de rendu nécessite de voir comment il se comporte face à des vérifications anticheat réelles et à un comportement réel des joueurs, et non pas seulement de charger le code et d'espérer qu'il fonctionne. DevTest est l'emplacement prévu à cet effet. Les développeurs l'associent à ce qu'ils construisent activement, lancent le client et testent contre un serveur en direct.

Lors de la livraison de la version, DevTest est soit nettoyé, soit reste en place car il est plus rapide de le laisser en place pour le prochain cycle de test que de le supprimer, de le réajouter la semaine prochaine et de le reconfigurer à nouveau.

Est-il sûr de l'utiliser

Il n'y a pas de réponse unique ici, car DevTest n'est pas une fonctionnalité unique avec un seul comportement, c'est un espace réservé. S'il est inactif dans votre build, l'activer ne fait rien et comporte aucun risque de plus que tout autre paramètre inutilisé. S'il est connecté pour tester du code pour quelque chose comme la manipulation de paquets ou une triche de mouvement à moitié terminée, l'activer peut déclencher un comportement qui n'a jamais été testé contre l'anticheat d'un serveur réel, car il n'était jamais censé fonctionner dans un vrai match.

Considérez un module de développement non étiqueté comme imprévisible. Ne supposez pas qu'il s'agit d'un simple interrupteur inactif sans danger, et ne supposez pas non plus qu'il s'agit d'une fonctionnalité secrète. Ce n'est ni l'un ni l'autre, tant que vous ne savez pas à quoi le build le pointe.

Ce que font les clients en production

Un client finalisé expédie des modules avec des noms qui ont un sens, des descriptions qui correspondent à ce qu'ils font réellement, et des paramètres qui se comportent comme ils sont étiquetés. Si une fonctionnalité n'est pas prête, elle ne sort pas dans un build. Si elle est expédiée, c'est parce que les développeurs sont convaincus de ce qu'elle fait et prêts à la documenter.

FAQ