J'essaye de refactoriser mon code afin de pouvoir effectuer un test unitaire à l'aide de fakexrmeasy.
Dans le cadre du refactor suggéré mentionné ici , j'ai tenté de transmettre IOrganizationService à toutes mes classes et méthodes. Cependant, certaines de mes classes utilisent des variables et des méthodes que IOrganizationService n'a pas, telles que Timeout. J'essaie de trouver un moyen de refactoriser pour utiliser IOrganizationService sans perdre de fonctionnalités.
Voici comment il existe avant le refactoring.
class testClass () {
public void testMethod(IOrganizationService service) {
var serviceProxy = (OrganizationServiceProxy) service; //This breaks when given a fake context
service.Timeout = new TimeSpan(0, 15, 0);
}
}
C'est après le refactor. J'ai essayé de convertir IOrganizationService en OrganizationServiceProxy, mais le faux contexte de service ne peut pas gérer ce cast. Une exception est levée.
class testClass () {
public void testMethod(OrganizationServiceProxy service) {
service.Timeout = new TimeSpan(0, 15, 0);
}
}
J'ai essayé d'utiliser une IOrganizationServiceFactory, comme suggéré dans ce message . Le problème est que factory.CreateOrganizationService () génère un IOrganizationService, pas un OrganizationSeriviceProxy.
Comment puis-je refactoriser pour utiliser IOrganizationService au lieu de OrganizationServiceProxy sans perdre de fonctionnalités? Je suppose que je devrais peut-être implémenter le IOrganizationService en tant que OrganizationServiceProxy d'une manière ou d'une autre.
4 Réponses :
Est-ce que quelque chose comme ça pourrait être viable?
private void testMethod(IOrganizationService someService)
{
if(someService is IServiceProxy)
{
IServiceProxy tempProxy = someService as IServiceProxy;
tempProxy.Timeout = new TimeSpan();
}
}
Puisque OrganizationServiceProxy implémente IServiceProxy (qui à son tour implémente IOrganizationService), vous pouvez vérifier si l'objet que vous avez passé implémente l'interface IServiceProxy et faire votre travail à l'intérieur du if.
public class OrganizationServiceProxy : IServiceProxy
{
public int SomeProp
{
get
{
return 1;
}
set
{
}
}
public TimeSpan Timeout
{
get
{
return new TimeSpan();
}
set
{
}
}
public void SomeMethod()
{
}
}
public interface IServiceProxy : IOrganizationService
{
TimeSpan Timeout { get; set; }
}
public interface IOrganizationService
{
void SomeMethod();
int SomeProp { get; set; }
}
Je ne sais pas si cela aiderait, mais c'est ce que j'ai utilisé
CrmServiceClient c = new CrmServiceClient(connectionstring); //various parameters available (OrganizationServiceProxy) service = c.OrganizationWebProxyClient ?? c.OrganizationServiceProxy;
Je pense qu'il existe une solution simple - si vous n'avez pas besoin de vous moquer des méthodes sur OrganizationServiceProxy - ignorez simplement celles dans le contexte des tests unitaires.
I.E. au lieu de
var serviceProxy = service as (OrganizationServiceProxy);
// The serviceProxy is null so it is ignored when given a fake context
if (serviceProxy != null)
{
serviceProxy.Timeout = new TimeSpan(0, 15, 0);
}
Faites
// This breaks when given a fake context var serviceProxy = (OrganizationServiceProxy) service; serviceProxy.Timeout = new TimeSpan(0, 15, 0);
Deux options:
1) Pour rester simple, refactorisez votre code afin qu'il référence uniquement IOrganizationService, et n'utilisez que ce code dans vos tests, et laissez le bit TimeOut non testé (en dehors de la portée des fonctions refactorisées)
2) Si le test unitaire de la propriété Timeout est vraiment nécessaire, simulez votre propre classe OrganizationServiceContext et passez le service fictif généré par FakeXrmEasy (IOrganizationService) au constructeur de OrganizationServiceProxy. Voici une liste de tous les constructeurs disponibles: