I am trying to test a web service.
My first try was using unit tests which got really complicated because of the need to mock things like HttpContext (that actually was the main reason).
So now I'm trying a different angle - I know I can send a httpRequest using a c# application, but can this application for example maintain the cookies I'll receive from the web service?
Is it a possible and reasonable way to test a web service?
Thank you.
The logic 'hidden' behind the web service should be testable as unit-tests. The fact the results are returned across the wire is more of an integration test. Maintaining cookies across calls seems like an integration test to me.
BTW, designing stateless web service calls is desireable where possible.
Yes, That's possible for every practical use. As for the cookies example, see here.
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 looking at converting an existing web service into a Web API. I've only worked with a WS a little bit and it was a long time ago. What I do remember is that in my project I would make reference to a service location and then use that reference to call whatever method I needed.
EX: I would reference http://mydomain/webservicename/mobile.asmx and then would call objWS.MethodName() what was coded within the mobile.asmx file.
If I convert over to using a Web API I would basically call the HTTP by going to something like http://mydomain/controllername/myMethod.
As of right now I don't have access to the client code to be able to change the way that it calls the service. That being said am I stuck with using a traditional web service vs web api?
This is an app on a handheld scanner that I believe is running Windows CE. We are having some connectivity issues/database deadlocks and I was asked to look at it and see if I can help out. The current WS code is overly complicated IMO since it's only doing either an insert or an update to a database. I would also think that going with a Web API would make it a faster app since it's depending on cellular access for it's communication. JSON should be a smaller payload than XML.
So, I would like to just re-write it using Web API 2 and Entity Framework. However, I'm afraid I'm stuck to using WS since I don't have access to the client code.
Any suggestions?
It's a fairly broad architectural suggestion, but what you're proposing certainly sounds possible and even quite reasonable.
If I understand correctly, you currently have this:
Client -> ASMX Service
And you can't change the Client, only the ASMX Service. The first thing you're going to want to do this ensure that server-side business logic is de-coupled from the platform technology:
Client -> ASMX Service -> Business Logic
The idea here is that any application host should be able to reasonably invoke the same business logic, even if that logic is nothing more than direct database access. The application host itself should be little more than a pass-through set of operations to be invoked.
At that point, you can create a second application host alongside the first one:
Client -> ASMX Service ----|
|-> Business Logic
WebAPI Service --|
So now you have two different services which expose the same business logic, using two different web service technologies. Each of them should be very thin, as application host technologies should always be easily replaceable.
At this point, assuming there are no significant gaps in the operations available between the two services, you can publish the new service's specifications to clients and begin plans to deprecate the old service. When you can deprecate it is more of a contractual issue than a technical issue. However long you've committed to maintaining it, that's how long clients will have a reasonable expectation to still use it.
If you really want to, you can even have the ASMX Service be a pass-through to the WebAPI Service, but in my personal experience that adds unnecessary layering to the whole setup and artificially complicates the abstraction of the business logic. Either way, the interface exposed by the ASMX Service wouldn't change.
The main thing here is the logical abstraction of the operations being exposed and the analysis of any gaps between what the ASMX Service can do and what the WebAPI Service can do. If that gets complex, then that's an indication that the business logic (and indeed the whole solution domain) is tightly coupled to the application technology being used, namely ASMX web services. That is the problem to be solved. Once solved, creating different application hosts and exposing different services which invoke the same underlying business operations becomes almost trivial.
You are right; you are stuck if you can't change the client and you want to change service protocols. Your client currently has a specific .asmx endpoint it is configured to point to and until you can update that endpoint and have the client stop using the proxy generated from the service, you can't change to Web API.
I'd still rewrite the service to use EF, though.
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.
can any one please advice me, is there any possibilities to access .Net modules using php
One thing that i can suggest is
step 1 : create web service in .net which is client script enable
or create one aspx page
setp 2 : call the web service method or web page using jquery ajax or javascript ajax
by this way you can achieve things you want
Ditto pranay. .NET makes it extremely easy to create WSDL-based web services that PHP can easily communicate with. In my experience you should shy away from using DLLs if you can - doing so locks you into running your application on IIS, bit of a nasty surprise and rewrite if you ever need to switch your PHP application to a *nix based server setup.
However, depending on your needs you may not want/need to call it using jQuery. PHP has more than adequate SOAP functionality built into the core.
What is the best way to test web service using NUnit.
I want it to be automated, i.e, I don't want to have a separate process to host the web service for the testing code to consume.
The web service is just a plain-old-.net class. You can instantiate it directly and call its methods in a unit test.
That won't allow you to test http specific aspects of web services like authentication at the protocol level, but I would say that there's no getting around using a web server for that.
It depends on what you want to test. It's possible to do full integration tests and there is some value in that (checking serialization, for instance). One simple way to get good test coverage with minimal work is as follows:
Write one or more plain old classes that do the real work (use TDD if desired)
Test these classes in isolation
Have your WebMethods delegate to these classes.
Depends. If it's an asmx, you can use HostableWebCore on Vista and higher. If it's WCF, just self-host by creating an instance of ServiceHost in your process. You could directly instantiate the service impl, but if you have any HTTP-isms (HttpContext, Request/Reponse access, cookies, etc), you'll have to mock them.