I created a WCF project using the IIS model. I then created unit tests which reference services from that project. Now when I start the unit test, the service is not hosted and thus I get EndpointNotFoundExceptions. When I simply hit F5 everything works fine and the IIS Express comes up in tray.
I checked the option "Always start when debugging" in the property-pane of the service-project and it is set to true.
A Unit Test is a unit test. If you need another process for it (namely some IIS or other web server) it's no longer a closed unit. If you want to test your service when it's hosted, I'd suggest you host it in your test yourself. Check self-hosting services. Then you have control about what class is hosted when and where. For example, you may want a different URL for your unit test and you may want to inject a different data layer so your tests don't need anything outside your unit, like a database.
You are not doing unit testing, and you are actually doing integration testing, since your test suit has no direct knowledge/binding of the service codes and it is just a client program of the service.
Both unit testing and integration testing contribute to good QA. Generally you should create unit testing which directly test the service codes through in process binding interfaces, and make sure it has comprehensive code coverage.
Then create integration testing using MS Test, NUnit or xUnit as test harness, in order to test some run time behaviors of the service.
What puzzle you is that how to make the test suit in the same VS sln run while the service should be running in debug mode. There could be a few solutions:
Build the test suit using Nunit or xUnit, then run the test suit outside VS IDE which is running the service in Debug mode. Actually MS Test could support as well, but only in command line mode.
Host the service in IIS, and you have a batch files to copy assemblies and web.config to there upon every update. Then attach the service codes with respective w3wp.exe instance.
If you just want to test rather than debug, there could be another solution: Use IIS Express. You use either C# codes or batch file to launch IIS Express with the service during tearing up, and close IIS Express when tearing down.
Related
Currently I am using the following to run my OpenCover on my service layer,
net stop w3svc /y
OpenCover\OpenCover.Console.exe -target:C:\Windows\System32\inetsrv\w3wp.exe -targetargs:-debug -targetdir:B2.4.9\Application\Sample.Web.WCF\bin -filter:+[] -register:user -output:opencoverSvcResult.xml
net start w3svc
Is it possible to run the OpenCover on a service layer, WITHOUT stopping the service, as I would like to run these tests on a server machine, which is shared by other applications.
Thanks,
Bobin Cheiran
Unfortunately the answer is no. :(
OpenCover needs to instrument your modules and this cannot be currently done by using the attach functionality that is available to profilers like OpenCover.
You could possibly use IISEXPRESS to host your web application or some other self-hosting mechanism and this would give you more control over stopping and starting your application without affecting other users.
I'm working on project with two applications: android app (client) and rest service (server). My android app consumes my rest service.
Both applications are tested separately to ensure they're doing their business as expected.
During server tests I prepare requests and check server responses.
During client tests I set up a simple http mock server and test client's requests against different mocked responses.
Now, this technique works pretty well. It gives me a flexibility I like. I can use different test frameworks and continuous integration environments. But there is one weak point. In both (client and server) test cases I specify the same api. I assume that e.g.
GET /foo-list.json
will return HTTP 200 with json
[{
id: 1,
name: foo1,
}, {
id: 2,
name: foo2
}]
So I repeat myself. If I change a response format my client tests won't fail.
My question is about good practices in testing this kind of scenario. How to make true integration tests without sacrificing flexibility of independent tests. Should I test client with mocked server or with a real instance of my rest service?
Please share your professional experience.
In your scenario you should continue to write unit tests to test individual classes, and integration tests to test the inter-operation between multiple application layers (e.g. business and database layers).
You ask:
"How to make true integration tests without sacrificing flexibility of independent tests"
All of your code should should use abstractions, so that you can use dependency injection to unit test classes in complete isolation using mock dependencies. The use of mocks will ensure that these tests will remain independent i.e. not coupled to any other classes. Hence taking this approach, the integration tests, which would use your final concrete classes, would not affect the unit tests which use the mocked classes.
Also:
"Should I test client with mocked server or with a real instance of my rest service?"
In addition to unit and integration tests you should also perform client-server integration testing; I use automated acceptance testing for doing this. Using a test framework such as Cucumber (also check out calabash-android, which is written specifically to test mobile applications) you can write tests which would test specific features and scenarios which would interact with both the client (your Android application) and server (your RESTful service). These client-server integration tests would start-up and stop concrete instances of the client and server.
Mocks are for unit testing. Your description of the tests with the mocks describes exactly that. You test the client and server as separate units.
Integration testing tests if the units work well together. Since the interface is a REST interface, mocking makes no sense then, you have to test the real thing over HTTP.
See also What is the difference between integration and unit tests?
If your service is based in Java, I'd strongly recommend looking into the Spock framework, for mocking any sort of calls that might be coming from the client. Since Spock is just an extension of jUnit, you might also be able to use it for Android (though, to be fair I've never done Android development)
I'd say you want to do two things. Integration testing and Unit testing. Integration testing would attempt to bring up the android application and cause it to make service calls, ensuring the contexts interact with each other kindly.
However, in your regular commits, I'd suggest unit testing that mocks away everything but the class under test. Spock makes this pretty easy to do, and since it's built on top of jUnit all it takes a jar.
There is no reason you can't run automated end to end tests with a real service instance. You can run a real service instance on the same test machine you are using to run the unit tests, perhaps in the same container. You can set up configuration to use a different URL for the server instance for running automated end to end testing.
Why would you want to do the extra work of creating the mock service if you can run them against the real service?
I would only create a mock service, if the service was an external service over which I had no control!
I want VS to deploy the latest version of the WCF every time I run my tests.
Currently I have to deploy manually, or run the WCF Service, for it to be deployed.
I'm looking for a functionality similar to starting multiple projects when debugging.
Maybe to specify the behaviour I am missing right now. I can not set breakpoints inside the webservice, as it's not run in debug-mode.
#codespike Using standard unit testing in VS2012
#codespike With Deploy I mean "copy latest version to local IIS, so it can be respond
to calls over the web.
#mayo Yes! that is a brilliant suggestion. Bypassing the Coding and Decoding (webtransport) phase, and go straight to the classes that manipulate the data.
We have a WCF web service and I would like to perform a load test. Could anyone please confirm if this is possible via Visual Studio 2010 or any other free tools?
Thank you
I have done a decent amount of this over the last five years using mstest and jetbrains dottrace.
What you need to do is write an integration test (a unit test that makes a call to your service) and then reference that in a load test. I then get dottrace to profile IIS and then rune the load test.
A free tool is available from CodePlex to load test WCF. To quote the project description:
This tool takes a WCF trace file and a WCF client proxy, or a WCF interface contract, and generates a C# unit test that replays the same sequence of calls found in the trace file. The unit test can then be used to load-test the target
You can with VS as long as you own the ultimate edition.
I have a scenario where I have to setup a test environment where I want to be able to tell my NAnt or other build tool to make an new IIS web application, put the latest bins in the newly created IIS web application, and post me an email where the new address and port where the new application are addressed, is this possible and how? which tool?
There are several ways to approach this:
Set up a continuous integration (CI) server on the test environment. This is a viable option if your test environment machine doesn't change often and it's a single machine.
Push the installation from your development machine using tools like PsExec
Combination of the two: you have a build CI server which pushes the installation to (multiple) test environments.
Of course, you also need a good build script which will set up the IIS application (NAnt offers tasks for this). Emailing to you can be done by CI server (CruiseControl.NET Email Publisher, Hudson...).
I suggest taking some time to read this excellent article series: Automation for the people: Deployment-automation patterns
Our CruiseControl .Net build server does exactly this as part of it's NAnt build-script process...
Once the code is retrieved from source control, it's all built/compiled in turn. Web projects are then handled slightly differently to normal .dlls, as they are deployed to a particular folder (either on the current machine or otherwise) where IIS (also set-up by the script) to serve the pages.
Admittedly, we're using Virtual Directories instead of creating and disposing of new website instances on the server, as otherwise we'd have to manage the port numbers for each website.
NAnt has the capabilities of doing all of this IIS work, as well as all of the email work too - I'd certainly recommend looking at this avenue of enquiry to solve your problem. Plus, you also get the continous integration aspect as a side-benefit in your case!