Integrating Web Services Testing with a Test Database

Question

I am currently creating a .net web application that uses WCF web services to allow the external end of Flex to access a database.

I'm going to set up unit / integration style testing in web services and am trying to develop a better way to allow tests to access and modify data in a separate test database.

Currently, the connection string in my unit test project points to my test database, and the connection string in my web services project points to my development database. However, since I use Linq, it seems that when I call web service methods from my test class, it uses the development database connection string.

I was looking for creating mock objects or a database in memory, but I believe the same problem will arise.

Is there a way to make this work, or is it my idea of ​​what I want wrong, and in which case is there a better way to fix this? I am still quite early in my project that I do not deny a significant change in the architecture of the solution.

Answer 1

Make sure the code in the web service is minimal and not much more than a simple call to your service level. When you do this, you can skip the web service call directly and create a test integration package, which also calls your service level. In this case, you are making a call in the process instead of a network call. In this situation, it will be much easier to provide access to the correct database, and you can easily wrap these calls with database transactions that will be rolled back. You definitely want to undo any actions in the database, because it will be very difficult to support RTM tests . One way to do this is to use TransactionScope inside the tests.

Good luck.

Answer 2

Stephen's suggestion is to end WCF plumbing for testing. This will certainly work and validate much of the business logic, but I would like my automatic integration tests to also verify WCF interactions.

I have successfully achieved this in automatic tests for my project.

Note that the WCF client and WCF host can share the same process. In this case, it still makes calls through the WCF structure with all the limitations and difficulties. And your WCF services will pick up the connection string from the configuration file of the test project.

To illustrate this, here is what the configuration file looks like if the client and the service are in the same process.

<configuration> <connectionStrings> <add name="ContractsManager" providerName="System.Data.SqlClient" connectionString="Data Source=localhost;Initial Catalog=ContractsManager_AutoTest;Integrated Security=True;Pooling=False;Asynchronous Processing=true;Application Name=CmAutoTests" /> </connectionStrings> <system.serviceModel> <client> <endpoint name="LoggingService" address="net.tcp://localhost:9612/loggingService" binding="netTcpBinding" contract="ContractsManager.ILoginService" /> </client> <services> <service name="ContractsManager.LoginServiceImpl"> <endpoint address="net.tcp://localhost:9612/loggingService" binding="netTcpBinding" contract="ContractsManager.ILoginService"> </endpoint> </service> </services> </system.serviceModel> </configuration> 

Thus, your automated tests will find errors specific to WCF (for example, an exception not specified in the fault contract). I was saved by this today: my code had an error that meant that the channels were closed properly. My tests continued to hang because the throttle limit was reached. It took some time to understand, but I am grateful that the error did not find it in production.

Your test suite should configure service hosts before starting the first test. (I tried setting up and tearing down the service hosts with each test, but it runs too slowly).

Good luck.

Answer 3

Since the WCF web service class is not tied to the ASP.Net infrastructure (you do not need to inherit from Syste.Web.Services.WebService), you can easily enter a link to the repository or object context in the provision of services. Then you can test any logic in the web service itself, using unit tests that will use some mock repositories in memory and launch them very quickly. On the other hand, integration tests will use some real database, and you can catch errors related to the retention level. Therefore, I would not agree with Stephen that web service methods should only be single-line, which call some level of service, if the logic is not so heavy that it deserves its own class.