Do I have to rewrite my code to do this into an interface? Or is there an easier way? I am using Moq
相关问题
- Sorting 3 numbers without branching [closed]
- Graphics.DrawImage() - Throws out of memory except
- Generic Generics in Managed C++
- Why am I getting UnauthorizedAccessException on th
- 求获取指定qq 资料的方法
I blogged about this a long time ago. Basically using partial classes and a bit of effort (either automated or manual, depending on how often you're going to change the web service) you can make the web service proxy class implement an interface. You can then mock it as normal.
there is an easy way. for example if we have WebService class with the name DbService, first create an interface for it (ex. IService), and use this interface for mocking, then add a class to your project and put this:
leave class empty, because of web services are partial class we use this implementation. (previously
What I usually do is build a wrapper or an adapter around my web service and just mock that.
for instance:
Then I just stub the service adapter.
been writing a couple of responses about unit testing and mocking lately. I wrote elsewhere that it's important to ask yourself what exactly are you testing. Regarding your particular situation, I would hope the answer is "I am testing the business logic my WebService is exposing", and not "I am testing my WebService" - there's a difference.
If your concerns are server-side
You do not need to test WebServices in general. MS has already done that. Millions of people have done that. Testing the transport layer, the protocol, the definition of WebServices is a waste of time.
You need to target your business logic. The best way to do this is to separate your business logic from your WebService. Consider the following
there is no way to test that logic without invoking the WebService directly. What you really want is
in prod
in test
managing dependencies [like the AuthenticationService member] is a separate issue. However, making your WebMethods simple passthroughs to proper underlying business classes and removing logic from them completely, allows you to target "real" user code as opposed to the plumbing of your typical WebService implementation.
If your concerns are client-side
You have a business component calling a webservice, and I agree that you don't want to create a client for unit testing.
Here, you have dependency issues, namely you cannot test MyClient.CallService without instantiating and hosting your WebService. Especially disconcerting if you do not own or host said remote service. In this case, yes, you should write against an interface - once again to separate and isolate business logic.
in test
In general, if a class's dependencies are in-proc services, the decision to apply a pattern like Dependency Injection [DI] or Inversion of Control [IoC] is up to you - and your desire to isolate and unit test these services will inform your design. However, if a class's dependencies cross a process boundary, eg Database or WebService, I highly recommend applying these patterns as we did above.
Really, it's just plain old interface development. You probably already see how it pays off.
:)