We need to test a web service which accepts JSON request. Server is implemented with WCF and REST API . Server response is asynchronous. I am thinking of below approach:
Approach 1: Use System.web and call UploadStringAsync
Approach 2: User asynchronous delegates in c#
I need to match response from server with request sent.
Is there any other better way to test REST API.
I need to develop test framework to test web service.
One part of testing a web service is testing what the web service does. You can do that with standard unit testing frameworks. This sort of testing has nothing to do with JSON or HTTP or REST, and that's a good thing. It will ensure that your service will work once you give it the correct JSON or HTTP or REST.
After you have tested the functionality of the service, you may want to write some other tests to make sure that the JSON, HTTP and REST part works. For that, you might use WebRequest or WebClient, or Visual Studio Web Tests.
Related
I am using WebApplicationFactory<TStartup> for integration testing of a .NET Core 3.0 web application.
It works when it need to test just one web application.
But what if web application need to send request to WebAPI application. I need somehow to instantiate both WebApplicationFactory<Web.Startup> and WebApplicationFactory<Api.Startup>.
I tried different alternatives with no luck.
Can anybody with experience of similar task point a right way to me.
P.S. Inside web application there is injected internal HttpClient that used internally in Controllers to send requests to API:
services.AddHttpClient<IInternalApiClient, InternalApiClient>();
You wouldn't. What you're talking about would be a "systems test", i.e. testing the whole system. Integration testing is about making sure the sub-components of a single application function together. As such, you'd mock the the service class that calls out to your API: InternalApiClient. In your test server's web host setup, you'd create a mock of IInternalApiClient and stub the appropriate methods to return dummy data instead of actually calling out to the API.
I'm learning ASP.Net MVC and I've read that it is easy to unit test as controllers can be instantiated and have their methods called without needing to deploy to a web server, and that it is easy to mock dependent objects etc. (see http://msdn.microsoft.com/en-us/library/gg416511(VS.98).aspx and multiple other references).
It's also possible to run acceptance level tests on the MVC App through the browser using Selenium or Waitin using your own favourite framework to author and control the tests.
What I'd like to know is if it's possible to run ATDD tests at an acceptance test level by calling the controller methods in a deployed, running MVC application, e.g. from Specflow, rather than having to test through the UI?
Or more generally, is it possible to programatically call the API of the ASP.Net MVC application from a test?
It seems like there is a gap in what it is possible to test between unit testing and browser based UI testing. Has anyone been able to bridge that gap?
Your question isn't clear but if you are asking what I think you are:
MVC controllers (generally) obey REST.
You can call any action on a controller (via a web server like IIS) by sending it a HTTP request. It will return a HTTP response containing the relevant data and data type(HTML, json, XML, etc.). So yes you can programatically call a controller like an API (if by API you mean something you send HTTP requests to and get HTTP responses from) therefore yes you can test the controller without using the UI.
I am having an Existing ASMX webservice in Production. I need to add RESTFul capabilities to the same for Rest Clients.
As per my understanding it must be as simple as adding a HTTPHandler (restversion.ashx) implementing IHTTPHandler and calling Business methods while serializing the return objects to XML or byte Stream. Which will be received and interpreted by REST Clients.
Though, while searching on the similar topics, it is not recommended and Can't be done.
Please suggest me..
I would recommend using WCF Web API. There are several tutorials at the end of this page. As you can see it is pretty easy to build simple RESTful service. There is also built in test client so you can test your REST service using your browser.
Assuming you want to continue your investment in the legacy ASMX technology, you can create a new WCF REST service, and have it call the existing ASMX service as a client, in order to perform its functions.
I am doing integration testing of my system with a 3rd party web service. They have provided the WSDL and the XML soap response packets but the web service hasn't been built yet. I am using WCF to call the web service.
Any suggestions on how to write the end-point to send back the response contained in the XML file?
I know I can generate the service side from the WSDL but I'd like to verify the integration using the supplied XML packets.
I'm sure there's a more technical way, maybe using an interceptor to replace the soap response form your mock service, but a quick hack might be to just create the Mock service with SvcUtil, and grab your own SOAP response off the wire with fiddler or wireshark and compare the responses.
I think SOAP UI serves your purpose. Using SOAP UI you can have a dynamic behavior to the service you want to mock. For example you might want to:
Read some data in a request and use its value to select which response to return
You can also virtualize the services multiple SOAP request and response very well using ITKO/CA LISA.
LISA will record live service requests and responses, and create a virtual test bed to remove the team's dependency on live, connected systems or fully replicated test beds
You can also mock using concrete WSDL of target system using LISA
I am creating a few basic web services using c#, and I am trying to have the web service return back just a normal name=value&name=value without any kind of xml or json format. The legacy system hitting these services is fairly old and doesn't support xml or json. Is doing this possible?
If the legacy service that's targeting this web service is that old, how exactly are you calling the web service from it? It may be easier to create an .aspx page (or even better, .ashx) that parses the request and makes the response simply using Response.Write.
If you update your question/add a comment with the detail about how you're calling the service, I'll update my answer accordingly =)