chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
Welcome to Typemock Community! Here you can ask and receive answers from other community members. If you liked or disliked an answer or thread: react with an up- or downvote.
0 votes
We’re currently using Typemock Isolator under the evaluation license.

I appreciate the following scenario is an unorthodox approach to unit testing and sits more in-line with integration testing. However, for various reasons, we view this approach as having the greatest value to our business needs.

This scenario involves calling asmx web services which in turn call databases. Consider the following:
WS1 updates DB1 then calls WS2 which updates DB2.

Traditionally, we’ve created a test project within Visual Studio and added a web reference to WS1. Then, our unit test code calls a Web Method. Our aim is to continue the above convention, but not allow any DB updates to be committed. In other words, wrap everything up in a transaction from the source (from the test entry point).

Our solution to the problem of including asmx web service calls in a transaction is to get each asmx web service to host a WCF end point which supports transactions. Internally this WCF end point calls the original asmx implementation of the request (by instantiating the WebService derived class and calling the web method directly i.e. not via http). This is fine if that WS only makes database calls, but if it makes a call to another asmx web service the transaction flow will be broken.

Our solution to that problem is to use TypeMock to mock the web service proxy class in WS1 and instead call the WCF endpoint of WS2, thus keeping the transaction alive. Essentially, we want Isolator to be functional outside the context of a unit test and from searching around, I get the feeling this is possible (sources: and ... lator.aspx)

I’ve added the following entries to my user and system environment variables:

I added the [Isolated] attribute to the WCF operation contract. The first time a test was ran, it would pass without error – essentially doing exactly what we wanted it to do. On the 2nd run of the same test, the following exception kept occurring:
*** Can not call Swap.AllInstances() more than once on a type.
I removed the [Isolated] attribute and used Isolate.CleanUp(); in the method body, which resolved the problem.

I’m still observing strange behaviour though and have had difficulty in tracking down various problems.

Example: Sometimes tests were failing, sometimes passing. The only way I could reproduce this was to perform an iisreset operation, and then run a test against WS1 calling the WCF end point - the test passes. All other legacy tests which call the asmx end point directly also pass. However, if I perform an iisreset operation and run a legacy test which calls the asmx end point directly – it passes…but all tests calling the WCF end point fail. No exceptions are generated and the mocking in the WCF endpoint is not active.

So this leads me to ask; Are we trying to do too much with Isolator?

Further Info
All development and tests are being performed on localhost (Ultimate aim is to deploy web services to a development server and have tests run as part of a TFS Build)
Web Services 1 and 2 are in separate solutions
Windows 7
IIS 7.5
Visual Studio 2010
Test Project .Net 4
Web and WCF Services .Net 3.5

asked by garethmonk (1.1k points)

1 Answer

0 votes
Hi Gareth,

This is quite interesting and thought provoking. Indeed, you can enable the Isolator profiler on processes other than the test runner process, using said environment variables - we actually provide the mocking_on.bat and mocking_off.bat to set and unset these environment variables.

I can, however, think of a few snags you may encounter along the way. As a starting point, try adding the name of the process running your WCF operations to the namespaces.dat file included in the Isolator installation directory. This should enable proper faking in the context of this process.

If you encounter further issues or instabilities, it would be of tremendous help if you could recreate a minimal solution with the deployment items you mentioned, and send it over to our support email. I'd like to throw some ideas around the office, and would like to know we are working on the correct thing.
answered by doron (17.2k points)