2

I have a first projet "MyProject.Core", I have the EDMX with :

The repo class :

class MyProjectRepo : IMyProjects
{
    public int NumberOfUser()
    {
        return new context().User.Count();
    }

    public string HelloWorld()
    {
        return "Hello World!";
    }
}

The interface :

public interface IMyProjects
{
    int NumberOfUser();
    string HelloWorld();
}

The factory :

public static class MyProjectFactory
{
    private static IMyProjects _returnedObject;

    public static IMyProjects GetObject()
    {
        lock (typeof(MyProjectFactory))
        {
            _returnedObject = new MyProjectRepo();
        }
        return _returnedObject;
    }
}

A test project ""MyProject.Core.Tests" (tests passed) :

[Test]
public void NumberOfUser_Test()
{
    var number = MyProjectFactory.GetObject().NumberOfUser();
    Assert.AreEqual(1, number);
}

[Test]
public void HelloWorld_Test()
{
    var hello = MyProjectFactory.GetObject().HelloWorld();
    Assert.AreEqual("Hello World!", hello);
}

I created a "Cloud" project and a WCFServiceWebRole.

In the WCFServiceWebRole, I have this :

public class Service1 : IService1
{
    public int NumberOfUser()
    {
        return MyProjectFactory.GetObject().NumberOfUser();
    }

    public string Hello()
    {
        return MyProjectFactory.GetObject().HelloWorld(); 
    }
}

[ServiceContract]
public interface IService1
{
    [OperationContract]
    int NumberOfUser(string login, string password);

    [OperationContract]
    string Hello();
}

A project to test the WCF, the methode "Hello" return the right value. It's with the other method I have thr problem. In the app.config, I have this :

<bindings>
    <basicHttpBinding>
        <binding name="BasicHttpBinding_IService1" />
    </basicHttpBinding>
</bindings>

<client>
    <endpoint address="http://myproject.azurewebsites.net/Service1.svc"
        binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IService1"
        contract="myprojectServiceAzure.IService1" name="BasicHttpBinding_IService1" />
</client>

Error :

System.TimeoutException : The request channel timed out while waiting for a reply after 00:00:59.7138476. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ----> System.TimeoutException : The HTTP request to 'http://MyProject.azurewebsites.net/Service1.svc' has exceeded the allotted timeout of 00:00:59.9270000. The time allotted to this operation may have been a portion of a longer timeout. ----> System.Net.WebException : The operation has timed out MyProject.Azure.Tests\Service References\MyProjectServiceAzure\Reference.cs(487, 0) : MyProject.Azure.Tests.PointageServiceAzure.Service1Client.MyMethod(String login, String password) MyProject.Azure.Tests\AzureTests.cs(18, 0) : MyProject.Azure.Tests.AzureTests.Test()

TheBoubou
  • 19,487
  • 54
  • 148
  • 236

3 Answers3

0

Have you checked the Azure firewall rules? You need to 'allow' the WCF service access to the SQL Azure database. From memory, there's a checkbox that you need to check, which allows the hosted application access to the database, as this is not checked by default.

Paul Fleming
  • 24,238
  • 8
  • 76
  • 113
Brett Rigby
  • 6,101
  • 10
  • 46
  • 76
0

Did you try to set your MaxReceivedMessageSize etc in your web.config ?

See Here

Community
  • 1
  • 1
SUN Jiangong
  • 5,242
  • 16
  • 57
  • 76
0

It's not an answer to your question. It's a solution of the real problem you're facing :)

You're not really writing a unit test, but an integration test.

You must ask yourself what do you really want to test. As far as I can see, you're testing connection to your WCF service, and that's not what unit tests are designed for.

What I suggest is a separation of concerns. WCF is the only proxy that allows remote communication. Therefore it's not part of core business logic. Your business logic should be as pure as possible. No unnecessary dependencies which might be hard to get rid of. Should you have to replace WCF with carrier pigeons ( ;) ), with logic unaware of WCF you don't have to touch logic code at all.

Here's an example of my idea:

interface IService //pure business logic, no knowledge of WCF
{
    double Add(double a, double b);
}

class NonWcfService : IService //pure business logic
{
    public double Add(double a, double b)
    {
        return a + b;
    }
}

[ServiceContract]
interface IServiceContract //wcf-bound (because of the attributes)
{
    [OperationContract]
    double Add(double a, double b);
}

class WcfService : IServiceContract //wcf-bound delegates calls to pure business logic
{
    IService sourceService;

    public WcfService(IService sourceService)
    {
        this.sourceService = sourceService; 
    }

    public double Add(double a, double b)
    {
        return sourceService.Add(a,b);
    }
}

Now you can write unit tests for NonWcfService without having to connect to any service. It implies that your unit tests would run much faster.

You may also write unit tests for WcfService that would check if this wrapper behaves well as a proxy.

dzendras
  • 4,721
  • 1
  • 25
  • 20
  • I know this, that's work with a method returning just a string. The problem is when a method need to access database. – TheBoubou Dec 29 '12 at 21:52
  • Which method? Be more precise, please. – dzendras Dec 30 '12 at 01:29
  • Whatever... Your business logic MUSTN'T be aware of exact data source! BL should operate on providers (interfaces to be clear). Your "production" implementation reads DB records, while in unit tests you mock such an interface. – dzendras Dec 30 '12 at 01:34
  • 1. What do you need this factory for? It gives no value. Moreover locking on this/GetType() is completely unsecure and should be prohibited. 2. In your unit tests for MyProjectRepo you shouldn't use this factory. Instead create repo using constructor. Putting factory there causes the test to test actually 2 things: repo itself & the factory. 3. With the code provided you still can't get rid of DB connection assuming that Context uses DB. 4. Avoid static classes for factories. Both them and singletons are pure evil - in your unit tests, you cannot switch dependencies - e.g. to get rid of DB. – dzendras Dec 30 '12 at 16:43