I have an assembly which wraps the functionality of an external live web service.
How do I go about testing this web service effectively. Should I create a stub of the web service or should I write tests that send and receive live data to the web service?
The problem I have with the second approach is that if I send and expect real data from the web service then I can't assert the results each time as they might change!
If the wrapper only forwards the calls to the web services with no conditional logic at all, there’s no point in creating tests against it that don’t go through the real web service. In this case you should create one test for each operation which should only test the ability to reach the web service and come back without unexpected errors. The data returned really don’t matter. This is an integration test between your wrapper and the web service.
If your wrapper includes conditional logic, then it may be a good idea to create tests that exercise all the paths. It’ll be easier to test these cases if you do not depend on the real web service.
For testing the client code (the code that calls the wrapper), you should stub the wrapper or stub the web service. This will give you the control you need to guarantee the client always receives the same output given the same input.
Related
I'm writing a program that interacts from with a SOAP web service. I have a wsdl file for the interface but I have no access to a server to test my program.
Is there some tool where I can load in the wsdl and it simulates the service? I just need to return valid looking data.
I can test the majority of my code my mocking the service interface, but I need to test the actual interface code as I've just had to change that with an updated wsdl file.
SoapUI can do it. It will run a local mock server.
Pretty easy to set up, just give it your WSDL, a bit of configuration, and away you go.
I am creating windows service, which must be able to receive commands from client located on other computer.
So far it seemed like using WCF for comunication is a good idea. However I am unable to pass any argument to my service on server side. All tutorials on WCF show only basic methods, which do not interact witch windows service.
Is there any way how to communicate with windows service? - Be able to call methods, that return some data. Using WCF it feels like I am only a step away. I can call methods on server and getting data back. I am however not able to access parameters of the service to modify them.
Basicaly what I want is to have a thread running in the windows service doing periodiccaly some actions, and to be able to remotely interact with it (it is not enough to pass only number code, I need to be able to pass at least string (preferably custom type) and get answer (string or custom type))
Thanks
If you can pass the number you can modify the service contract to use a (custom) data contract including strings and also more complex types. You need to check [DataContract] for more those complex types.
This link covers the basics: http://www.codeproject.com/Articles/653493/WCF-Hosting-with-Windows-Service
It starts with creating the service and creating an installer for the windows service.
Starting with the Fourth module there it is explained how to complete coding on the client side.
You need to expose the service metadata for service reference to complete programming the client.
If you have the metadata exchange, you can also check if you can find the hosted WCF service with tools like the WCFtestclient.
I call a web service that returns a json string to me.
I would like to test this call by creating a text file with the content of the service call and test against this rather than the actual web service call.
This type of test, is it an integration test or unit test?
Well, Integration testing can be thought as testing an aggregation of modules while unit testing is testing the smallest testable part of an application.
And in your case you are not using actual web service as input data but some static data, I am assuming you are doing so just to test if all is going well, this can be thought as Static Testing or Unit testing of the code that utilizes the web service response. Also refer: types of software testing.
Its unit testing, your intention is to test the functionality "call a web service that returns a json string" only.
To make it integration test, you have to do every single aspects related to that process a real one OR result of actual process. So here you are just testing this with a sample of web service call, to ensure the call.
Look I'm concerning about what is faster/best about consuming a WebService who is within the same WebSite/WebApplication.
Imagine I have a 20 pages and 1 WebService in the same WebSite..
In each page I have to consume everything from the WebService...
But my concern is how it should be consumed? I should add the webreference of my WebService who is in the same website and use everything with the proxy generation of that Webservice.. or I should instantiate directly the WebService like a normal Class and consume the methods?
I know (or I think) that the best practice is to consume it like a webService for the SOA especifications and have the WebService in another website in my solution.
But my reasoning says that consuming a WebService needs http protocols who makes a request through this protocol, and a webservice serialize the response...
An important thing to remark I guess, is that the webmethods of My WebService can return several records /information /data, so the serialization step could be a problem or a performance issue.
I'm looking for the best way of doing this.
Should I move the WebService to another Site and consume it in my pages? even though the performance will be affected? or I should not? if yes, how much? it will cost ? or the impact is not significant?
If I should move the WebService does it affect if I consume it like http:// localhost .. instead of ... 192.168.1.1, or a web domain than localhost? is it the same or does it affect in something?
Thanks in advance for your help.
But my reasoning says that consuming a WebService needs http protocols
who makes a request through this protocol, and a webservice serialize
the response...
Your reasoning is absolutely correct. If you are inside the same project there's no need to waste CPU cycles in useless HTTP requests. You could directly invoke the same repository layer that your web service methods already uses. You could still expose the web service using an interoperable format (such as SOAP) if you need non .NET clients to consume it, otherwise I don't think it's really necessary. Actually why did you develop a web service on the first place? I guess you had some expectations about future consumers? The rule of thumb is to always encapsulate a reusable service domain logic into a service layer and then depending on who needs to consume it, either directly use the assembly in which you implemented this functionality (if we are talking about .NET clients) or if you need interoperability, it's pretty trivial to use WCF to expose this service layer using interoprable protocols.
But if you are interested in the exact figures, don't hesitate to perform some load tests and compare the response times between a direct .NET method call directly from within your cinsuming web application and an HTTP request using an interoperable protocol.
Remark: WebReference clients are deprecated now. You should use a ServiceReference instead if you decide to invoke your service throughout a network connection.
I am on a project where I will be creating a Web service that will act as a "facade" to several stand alone systems (via APIs) and databases. The web service will be the sole method that a separate web application will use to communicate with these external resources.
I know for a fact that the communication methodology of one of the APIs that the web service must communicate with will change at some undetermined point in the future.
I expect the web service itself to abstract the details of the change in communication methodology between the Web application and the external API. My main concern is how to design the internals of the web service. What are some prescribed ways of using OO design to create an appropriate level of abstraction such that the change in communication method can be handled cleanly? Is there a recommended design pattern?
As you described, it sounds like you are already using the facade pattern here. The web service is in fact the facade to the other services. If an API between the web service and one of the external resources changes, the key is to not let this affect the API of the web service itself. Users of the web services should not need to know the internals of how the web service communicates with the external resources.
If the web service has methods doX and doY for example, none of the callers of doX and doY should care what is going on under the hood. So as long as you maintain the API between the clients of the web service and the web service, you should be set.
I've frequently faced a similar problem, where I would have a new facade (typically a Java class), and then some new "middleware" that would eventually communicate to services located somewhere else.
I would have to support multiple mediums of communication, including in-process, and via the net (often with encryption).
My usual solution is define a notion of a data packet, with its subtypes containing specific forms of data (e.g., specific responses, specific requests), etc. The important thing is that all the packets must be Serializable in some form (Java has a notion for this, I'm not sure about C++).
I then have an agent and a provider. The agent takes program-domain requests, creates packats. It moves them to a stub-skeleton that is responsible only for communicating. The remote stub takes the packet and gives it to a provider. The provider translates it back to a domain object which it then provides to the actual services. It takes the response, sends it back to the agent via the skeleton-stub, etc.
The advantage of this approach is that I create several layers of abstraction. The agent/provider are focused on domain level and its translation into packets and back. The skeleton-stub pair is responsible for marhsalling and sending packets back and forth. By swapping my skeleton-stub pair with subtypes, I can have the same program communicate in different ways (e.g., embedded in the same JVM, via something like JMS, directly via sockets, etc.)
This shouldn't affect the service you create at all (from the user's perspective). Services are about contracts - your service will provide a contract with its users - they send you a specific request and you send back a specific response. You also have a contract with this other API. If they change how they want to communicate, you can handle that internally, but as long as your contract with your users does not change they wont notice a thing.
One way to accomplish this is to not simply pass through the exact object that you get from the "real" API. You can create your own object that you send back in response. You then translate their object into your object. That way if the "real" API changes things on their end you can choose how to send that back on your end.
As the middle man you should be set up so that your end users need to know nothing about the originating API.