I'm implementing a WCF web service based on WF. This web service consumes other web services which I'm not in charge of. So basically my service workflow contains several Send activities.
I'm following the TDD approach, so the service implementation is to be covered by unit tests. I want to test proper invocation of 3rd party services.
In a non-workflow case I would mock the external services via NMock. But in my case I cannot control the instantiation the workflow instance and I have no idea on how to trick the Send activities to use the mock objects instead of real services endpoints.
Although Unit Testing Workflows And Activities article on MSDN mentions mocks I couldn't find any complete example of mocking the remote end of Send activity.
Any idea on how to do that?
please try Moles framework. http://research.microsoft.com/en-us/projects/pex/
There are samples about how to mock the sharepoint service. I believe the same trick should apply to WF workflow.
I have tried to mock the sqlconnection, Entity framework, web service call, it works very neat. Basically, it can mock almost any .net objects.
Using ServiceAgents wrappers for your web services would be one possible way of doing it.
This is a pattern i have followed in previous projects of mine.
Since they are interface based, you can easily mock out the services.
There are other advantages to this pattern (besides unit testing) including being able to abstract your application from external dependencies to a certain extent. However it does add the overhead of creating another class layer on top of the services.
Related
I have a project for Master's Degree: design and implementation of web services for an elearning platform.
Now, I know that there are two main architectures for web services: SOAP, and REST
Now, I wanted to use REST architecture, so normally I would have something called "RESTful web services", so I started development with Django and Django Rest Framework
Now, this is the part where I get confused, Is this an API or Web Services
If it is an API, then how can I develop RESTful Web Services?
If it is both, please explain more if you could.
I'm very confused about this, and each time I try to understand, I get more confused, Please can someone clarify this to me?
An application programming interface (API) allows you to interact with a component, system, or resource. It's a very broad concept. To understand it, the emphasis should be placed on the word interface:
In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans, and combinations of these.
When you need something from a component or you want it to do something for you, you don't just go in it and do it yourself, you "ask it" for that something or for that action by interfacing with it. The interface of the component says what it can do for you or what you can invoke from the component.
In regards to web services, you have to understand that a web service is in fact an API, because it's an interface with some component (in this case whatever is behind the web service itself: it can be a database, an application, a system, etc).
Like I said, an API is a very broad term. When you say web service, you are adding some restrictions to that term. For example, a web service is invoked over the network. Not all APIs are like this. Some API's can be exposed as libraries, or frameworks that you call directly from your code as methods or functions. So all web services are APIs, but not all APIs are web services.
If you want to build a web service, you can implement it with REST or with SOAP. There is a difference between the two (REST is an architectural style, while SOAP is a protocol), but as concepts they work the same: they provide an interface with which to interact over the network, i.e. an API. But since you are using Django, thus Python, I suggest you go the REST way, not SOAP (support for SOAP in Python isn't all that great).
We have to implement a number of integrations with VSO from different applications using BizTalk Server 2013 R2.
Can someone help me decide which will be the best approach among the below three options:
WCF Service:
We can create a WCF service which will have reference of library provided by VSO and have common methods to interact with VSO. We will use extensible client library for dot net provided by VSO.
Utility Class:
This class will have same methods as in WCF service above, but I guess this will be faster as it will be added inside the BizTalk Solution and will be called from orchestration.
Common BizTalk Orchestration using Web-Http Adapter for calling REST APIs provided by VSO.
Please help me decide among these approaches.
It really depends on your scenario and the need of reuse of VSO functionality within BizTalk or outside BizTalk.
If BizTalk if the only consumer of VSO functionality, then you can directly use .NET library provided by VSO. From design perspective, its a good practice to wrap a third party library within your own .net library with your specific functionality, which will allow you to reuse the functionality across different applications if required.
WCF Service you would only want in case you want to expose this functionality outside BizTalk environment or if you have multiple BizTalk environment in which you want to share the same implementation.
My issue it regarding creating a dummy WCF service which can be used at development side, when the REAL WCF service is not available or is down.
In my current assignment, the issue is that the web hosted WCF service from client is not always available for developer side. This hampers the development work as we are not able to verify/unit test the client side code.
Any solutions in sight? I have been searching /reading about mocking wcf with different available mocking frameworks, but still not clear about the right way.
Thanks in advance !
Without talking about frameworks - to call your srevice, you create client (proxy) instance, right?
You can move its generation to separate method, which will return your mock (injected by DI, injected by setter property in Unit test,. . .).
I have noticed that when "Add Service Reference" is used in VS2010 then a ton of files are created. One of the files is Reference.cs which creates a ClientBase for the service contract.
Thus, I was wondering is there any advantage to the slew of extra files VS creates or can I just use a ClientBase myself and skip the "Add Service Reference" option.
I should note that in my case by sides are under my control.
Here's an overview of the pros and cons with the different approaches from my point of view:
Using the Visual Studio generated service proxies
Pros
Minimal effort required to get started
Ability to quickly update the proxy whenever the service contract changes
No custom code to maintain
Cons
Makes consumers difficult to unit test with any of the popular isolation frameworks for .NET, such as Rhino Mocks or Moq, due to high coupling with the WCF infrastructure through the ClientBase<TChannel> class
Unnecessary extra files are created
Using the WCF Channels API
Pros
High testability with any isolation framework thanks to the decoupling provided by the IChannelFactory<TChannel> interface
More control over how services are invoked
Cons
Takes some initial effort in order to get started
Some custom code to maintain
To summarize using proxies provides less friction when consuming WCF services while giving up some control and testability. Using the Channel API requires more code in exchange for a higher degree of flexibility, which comes in handy especially if you want to unit test components separately from the WCF services they communicate with.
Related resources:
How to programmatically connect a client to a WCF service
Using Channel Factory Vs Proxies in WCF
I have to integrate with a third-party web-service (behind firewall), and I do have their WSDL and proxy class.
I want to develop the client stuff outside the firewall.
What is the best approach to mock the web-service to ease integration with them?
Do I create a web-service project on my side? Somehow use their proxy classes ad mock the methods? This would create the service references so I can just change the target URL when the time comes.
Or do I create a service layer that returns mock classes in my dev. environment but would use real web-services at run-time?
The former approach would take a lot of work, I would think.
Any ideas?
With just the WSDL, you could host a mock service using soapUI.
I've used the latter approach to good effect in our projects. I've usually found that my apps use a subset of the functionality exposed by a given web service's API, to it's usually made good sense to expose a simpler API to my client code that's more streamlined and that reflects the workflow of my client better. So, since the way I typically use web services already involves writing an abstraction layer, replacing the endpoint on the other side of my adapter classes with a mock service is a very low-friction way to test interaction with the service.