Unit Testing Advice - how to unit test your .asmx

I'm just about done creating a web service that will be consumed by a non .NET internal custom system. I would like some advice on the best way to setup test classes and methods over an .asmx (best practices, how to test the calls, what not to do, etc.) specifically in a .NET 3.5 environment.

I will be using NUnit to do this testing. Is it as simple as creating a test project, adding the service to it and then create a test class and instance of that service..then start creating your test methods?

I need to test both the .asmx and .asmx.cs methods (unit test the methods) so that I know if I pass this to a teammate that it's going to work.

Maybe it's not possible to test an .asmx.cs开发者_JS百科 directly and I'll just have to test via integration tests. I guess what I really would need is to mock my .asmx. Probably not possible.

The best practice of a Unit test is not to test the asmx file, but the parts (units) behind the asmx file. If you can split up your code in small and separate pieces, then you can unit test those pieces.

If you want to test the asmx file itself, you're talking about an integration test. You can use NUnit for that in the way you described, but that's not really unit testing.

You might be missing the point of what other people are saying. The .asmx file should have no logic worth testing. If it truly is just a wrapper around business layer calls, then it adds nothing and doesn't need to be tested. If it does add something, extract that until the .asmx contains nothing but a pass-through call.

What does your .asmx file contain that cannot be extracted into separate, testable classes?

Unfortunately this is a problem with .asmx web services, they are dependent on ASP.net, you're best approach would be to keep the .asmx web service as a stub and extract your web service logic into a clean dependency-free class and unit test that instead. The other alternative is to run Integration tests as well.

In the long run, if unit testing is important to you, you may be better off developing using a web service framework that was designed with unit testing from the start.

Like Lodewijk stated, it is best practice to not unit test the asmx file. Instead, extract the logic from that file into class files which handle the behavior you are after. That way you can then unit test those classes in isolation from the UI. You may find that the real problem you have is that there is too much business logic in your UI layer.

If you want to test the asmx file itself you'll either want to consider manual testing, integration testing, or acceptance testing...but if you can move your logic to the business layer you'll probably find it much easier to test.